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 Behmedirk.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