Some comments on Linux-OMAP tree by Russell King

[Romain Goyet <r.goyet@gmail.com>]

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 :

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

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 :

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