On Tue, May 25, 2010 at 05:44:18PM -0700, Tony Lindgren wrote: > > So, below is a patch to sanitize the code in arch/arm/plat-omap/fb.c. > > The logic in this file is rather convoluted, but essentially: > > I've tried the patch below with the patches from your lmb branch > up to this one and I can see tux on my osk5912 and n900: > > Acked-by: Tony Lindgren <t...@atomide.com>
Interesting patch name! > After applying the next patch in your lmb branch "ARM: OMAP: Convert > to use ->reserve method to reserve boot time memory" tux still works > on 5912osk, but not on n900. The difference is that osk5912 uses > the old omapfb code. I guess this is because I don't have board-n900.c in my tree. All OMAP boards need a ".reserve = omap_reserve," line added in their machine descriptor. I just noticed that board-n8x0.c contains more than one machine descriptor, which I've now fixed up. > Then, looks like reordering of the patches now causes patch > "ARM: initial LMB trial" to fail with: > > arch/arm/mm/init.c:301: error: conflicting types for 'bootmem_init' > arch/arm/mm/mm.h:32: error: previous declaration of 'bootmem_init' was here > arch/arm/mm/init.c: In function 'bootmem_init': > arch/arm/mm/init.c:312: error: 'mdesc' undeclared (first use in this function) > arch/arm/mm/init.c:312: error: (Each undeclared identifier is reported only > once > arch/arm/mm/init.c:312: error: for each function it appears in.) > make[1]: *** [arch/arm/mm/init.o] Error 1 Now fixed, thanks. > Also, the last patch in lmb branch "ARM: use LMB to allocate system > memory MMIO resource structures" causes both osk5912 and n900 > to hang very early. Maybe I'm missing some patch again.. Hmm, I'll take a look later today. > Anyways, I've picked the patches from lmb branch up to the one below > into omap-testing. Will add more of them once we get them working. You should now be able to pick all but the last patch. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html