2009/9/22 Tony Lindgren <t...@atomide.com>: > Looks good to me. Let's plan on queuing these early so we can test it > in the linux-omap tree to make sure the patches don't break anyting for > other omaps. Then let's get them to the mainline tree the next merge > window after this current one. > > To me it looks like we could queue "OMAP7XX] irq.c: Missed a cpu_is_omap850()" > and "OMAP7XX] PM: Add another ARCH_OMAP850 check" already during the -rc > cycle as fixes? > > Then assuming you're done with the 7xx patches, could you please > combine all the trivial 730 to 7xx rename patches into just one patch? > This will make it easier for people to read through the whole series ;)
Hi, I've done a cleaned up version of the series now, available in branch omap7xx-fortony (against 2.6.31) or omap7xx-fortony-rc1 (against linux-omap/master, 945044d1...) The end result is the same whichever you apply: the conflicting code in gpio.c just gets deleted anyway. The first 9 patches do the clean up. The next 2 create omap7xx.h and swap over the core files. Then the big rename is done in two parts. Finally, a separate patch for the uwire driver. After that comes misc fixes for omap850 and 7xx. That puts omap7xx into a state where it boots for us with only the addition of a board file. http://ali1234.homelinux.net/linwizard-kernel.git/ Thanks -- Alistair Buxton a.j.bux...@gmail.com -- 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
