[U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler <holler@ahsoftware.de>]

Hello,

Am 19.12.2010 12:28, schrieb Albert ARIBAUD:
> Le 19/12/2010 11:22, Alexander Holler a ?crit :
>> Hello,
>>
>> On 19.12.2010 08:51, Dirk Behme wrote:
>>> On 18.12.2010 23:27, Alexander Holler wrote:
>>>> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
>>>> avoid that as done in the kernel.
>>>>
>>
>>> Acked-by: Dirk Behme<dirk.behme@googlemail.com>
>>
>> Thanks for the ack, but I have to say, that those barriers are having
>> side effects here. Reading NAND now fails on my BeagleBoard. Regardless
>> if I use gcc 4.3.5 or gcc 4.5.1, after applying that patch the wrong ID
>> of the NAND is read. In nand_get_flash_type()
>> (drivers/mtd/nand/nand_base.c) without that patch I will get the following:
>>
>> *maf_id: 44, dev_id: 186
>>
>> with the patch the following is read:
>>
>> *maf_id: 128, dev_id: 85
>>
>> Which just is wrong.
>>
>> I haven't looked further up to now, maybe thats just a side effect of
>> some wrong clock settings because of different timings through those
>> barrieres or whatever.
>
> IIUC, the patch is adding barriers to every HW register write and read,
> which makes the compiler stop reordering these, and keep them ordered as
> in the source code. Are you sure that the order as laid out in the
> source is the right one? Maybe you were just luck so far that the
> reordering masked a bug.

I don't know much about all the stuff the omap3-drivers are doing. E.g. 
I've already wondered why it's necessary to measure a clock frequency in 
the code which got (wrongly) optimized without that patch. I would think 
such isn't necessary because I would assume the drivers are actually 
there to set the clock settings, and not to measure them. ;)

Regards,

Alexander