Some comments on Linux-OMAP tree by Russell King

Argh, omap sets up a mapping and then immediately tries to access IO space. If some of the cache lines for the page tables were already in the cache, or you are using a write-alloc cache, that's not going to work - the mappings will not be visible to the MMU. Note carefully the comment:

/*
* Finally flush the caches and tlb to ensure that we're in a
* consistent state wrt the writebuffer. This also ensures that
* any write-allocated cache lines in the vector page are written
* back. After this point, we can start to touch devices again. */

and omap is accessing devices _prior_ to that point. 8(

This is most likely the reason why you're seeing boot failures.

Hmm, I notice that omap folk are _still_ buggering up the MMC core in relation to mmc.c. It'd also be nice of omap folk could conform to the agreed usage of clk_use/unuse vs clk_enable/disable as documented in the header file. The clock framework *relies* on everyone following the rules. Frustrated sigh.

Hello guys,
I've had recently many problems on my Palm Tungsten E. In
particular, it was crashing when I ran "local_flush_tlb_all()", in arch/arm/mm/init.c. I asked for help on the ARM-Linux mailing list, and here is what Russell finally told me :

Quoted 13 lines

Argh, omap sets up a mapping and then immediately tries to access IO space. If some of the cache lines for the page tables were already in the cache, or you are using a write-alloc cache, that's not going to work - the mappings will not be visible to the MMU. Note carefully the comment:

/*
* Finally flush the caches and tlb to ensure that we're in a
* consistent state wrt the writebuffer. This also ensures that
* any write-allocated cache lines in the vector page are written
* back. After this point, we can start to touch devices again. */

Quoted 3 lines

and omap is accessing devices _prior_ to that point. 8(

This is most likely the reason why you're seeing boot failures.

What do you think about this ? In particular, I think he is talking about this :
in arch/arm/mach-omap1/io.c

/* We have to initialize the IO space mapping before we can run
* cpu_is_omapxxx() macros. */

This is true, but we have to wait _as well_ that mm/init.c:devicemaps_init() has terminated. I would have proposed a patch, but it looks like many functions, like omap_sram_init();
and
omap1_clk_init();
Use cpu_is_omapXXXX() functions.

Do you have any idea for a workaround ?

Thanks in advance

Romain Goyet.

By the way, Russell also added this :

Quoted 5 lines

Hmm, I notice that omap folk are _still_ buggering up the MMC core in relation to mmc.c. It'd also be nice of omap folk could conform to the agreed usage of clk_use/unuse vs clk_enable/disable as documented in the header file. The clock framework *relies* on everyone following the rules. Frustrated sigh.