Re: [PATCH 2.6.17-rc3] AT91: Remove unnecessary use of bitfields

David:

David Brownell wrote:

>With the CodeSourcery GCC, just five mask instructions total ... and
>that's on kernels that include programmable clock support; otherwise
>just one (init code).  There's only one multibit field, and all those
>fields in that "struct clk" are readonly.
>  
>

That's the way I would code it in asm, too.  ARM is pretty friendly to 
bit fields.

What version is the CodeSourcery GCC?  Is this just something that older 
gcc's did poorly?

b.g.

--

-- 
Bill Gatliff
bgat <at> billgatliff.com

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

[RFC][PATCH] Clear the HWCAP bits for the disabled kernel features

Catalin Marinas wrote:
> Glibc interprets the HWCAP bits and decides on what features to use.
> However, even if the features are present in the hardware, they are not
> always supported by the kernel and hence the corresponding bits have to be
> cleared from the elf_hwcap variable.
How does this affect iWMMXt?  Does the VFP hwcap get set on iWMMXt processors
or is it completely separate and perhaps a iwmmxt flag should be listed in
/proc/cpuinfo?

Signed-off-by: Catalin Marinas <catalin.marinas <at> xxxxxxx>
---

 arch/arm/kernel/setup.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 4375284..8cff73e 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
 <at>  <at>  -322,6 +322,12  <at>  <at>  #endif
        sprintf(system_utsname.machine, "%s%c", list->arch_name, ENDIANNESS);
        sprintf(elf_platform, "%s%c", list->elf_name, ENDIANNESS);
        elf_hwcap = list->elf_hwcap;
+#ifndef CONFIG_ARM_THUMB
+       elf_hwcap &= ~HWCAP_THUMB;
+#endif
+#ifndef CONFIG_VFP
+       elf_hwcap &= ~HWCAP_VFP;
+#endif

JFFS2 vs. YAFFS2

Hey Guys,

I'm in the middle of getting a new stable Kernel running on one of our ARM SBCs. 
    We have a large NAND device on our board.  Currently we have a 2Gb part 
populated, but we may go even larger in the future.  I'm just wondering what 
file systems people are using for large NAND support.  I have managed to get 
JFFS2 working on our part, but am still having some issues with YAFFS2.

I'm wondering what people's preferences are between YAFFS2 and JFFS2.  I'm 
looking for any information regard reliability.

Thanks
Andrew McKay
Iders inc.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: [PATCH 00/32] Convert ARM to generic irq subsystem

On Apr 26 2006, at 22:14, Deepak Saxena was caught saying:
> 
> I will test IXP4xx and IXP23xx and post results to the list.

48  hours network stress on ixp4xx and no problems.

~Deepak

--

-- 
Deepak Saxena - dsaxena <at> plexity.net - http://www.plexity.net

I am not a consumer. My existence on this planet is not defined by my
relationship to a producer of goods.  I was not put on this planet to
consume goods from a company for their profit. - Michael W.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: [PATCH 2.6.17-rc3] AT91: Remove unnecessary use of bitfields

On Monday 01 May 2006 6:34 am, Bill Gatliff wrote:

> What version is the CodeSourcery GCC? 

This one happened to be old (3.3.5); current is 3.4.4.

> Is this just something that older gcc's did poorly?

I don't know, but wouldn't think so.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: Handle low active GPIO pins (at91) ?

David Brownell wrote:
> On Friday 28 April 2006 1:49 am, Steven Scholz wrote:
> 
>> Now how could be handle that different boards might not just use different
>> pins but also different polarity? E.g. on our board "switching off vcc"
>> means writing a "1" to that pin instead of "0".
> 
> Do you have such a board to test with, or is this more of a
> precautionary question?

 I couldn't care less about this topic if I hadn't such a board and the
the need to hack around official sources ...

>> Opinions? How is that handled on other architectures with GPIO?
> 
> Some of the PXA code stores callbacks in the platform_data.

And these callbacks does set/unset pin? Or are they more specific?
In case of at91_cf use something like

static struct at91_cf_data __initdata multiIO_cf_data = {
	.irq_pin = AT91_PIN_PA23,	/* I/O IRQ */
	.det_pin = AT91_PIN_PC14,	/* Card detect */
	.enable_vcc = myboard_toggle_vcc,	/* power switching */
	.reset_cf   = myboard_pull_reset,	/* card reset */
...
}

???

Re: Handle low active GPIO pins (at91) ?

Dear Steven!

Steven Scholz schrieb:
> Now how could be handle that different boards might not just use different
> pins but also different polarity? E.g. on our board "switching off vcc"
> means writing a "1" to that pin instead of "0".
> 
> Two ideas:
> a) Use negative numbers:

If there has to be introduced a new method to handle polarity, it should
also handle open-collector/drain pins. Currently there have to be called
different functions (at91_set_gpio_output() and at91_set_gpio_input())
instead of at91_set_gpio_value().

With best regards
Andreas Schweigstill

--

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Kernel autobuilder

Greetings,

As you all know the ARM kernel autobuilder has been chugging along for
some time now [1] (The first entry in the database is dated August
2004). Almost 300 kernel versions have been attempted with an average
of 51 configurations each time (thats 15,000 individual kernel
builds!).

In this time the service has not stood still, the addition of several
new ways to examine the data [2] from the web interface including the
tracking of warnings. This has helped the maintainers to get to the
current heady heights of 79 supported machines from a mainline kernel
source.

A recent addition to kautobuild is the mailing list [3] feature where
those interested can be emailed the results rather than visit the
website.

I hope the autobuild service continues to be useful, please feel free
to send requests for feature enhancements to myself.

[1] Full list: http://armlinux.simtec.co.uk/kautobuild/full.html
[2] http://armlinux.simtec.co.uk/kautobuild/defconfig.html
[3] http://www.fluff.org/mailman/listinfo/kautobuild

--

-- 
Regards Vincent Sanders

i.MX: move uart resources to board files

Hi all and i.MX users,

The attached patch moves the i.MX uart resources and the gpio pin setup
to the board files. This allows the boards to decide how many internal
uarts are connected to the outside world and whether they use rts/cts or
not.

any comments?

Sascha

Index: arch/arm/mach-imx/generic.c
===================================================================
--- a/arch/arm/mach-imx/generic.c.orig
+++ b/arch/arm/mach-imx/generic.c
 <at>  <at>  -195,56 +195,6  <at>  <at>  void __init imx_set_mmc_info(struct imxm
 }
 EXPORT_SYMBOL(imx_set_mmc_info);

-static struct resource imx_uart1_resources[] = {
-	[0] = {
-		.start	= 0x00206000,
-		.end	= 0x002060FF,
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {
-		.start	= (UART1_MINT_RX),
-		.end	= (UART1_MINT_RX),

Re: Kernel autobuilder

On Tue, May 02, 2006 at 10:34:09AM +0100, Vincent Sanders wrote:
> I hope the autobuild service continues to be useful, please feel free
> to send requests for feature enhancements to myself.

Indeed it does, and thanks for creating this valuable community service.

I hope others check it from time to time (either by subscribing to the
mailing list or visiting the site) to ensure that their submitted code
continues to build.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php