Hi Tony, On Fri, Dec 3, 2010 at 10:13 PM, G, Manjunath Kondaiah <manjugk@xxxxxx> wrote: > Hi Tony, > > * Tony Lindgren <tony@xxxxxxxxxxx> [2010-12-02 12:52:19 -0800]: > >> * G, Manjunath Kondaiah <manjugk@xxxxxx> [101202 11:55]: >> > >> > > >> > > Note that even with these three fixes, 5912OSK still fails to >> > > boot to init. Maybe something wrong with the framebuffer DMA? >> > >> > Not sure. I don't have omap1 board for testing. Patch series is only >> > build tested for omap1. >> > >> > Can you pls confirm if OSK5912 boots successfully without this patch >> > series? >> >> Yeah boots just fine without these as always. >> >> Anybody care to donate a OSK5912 or similar for the TI guys >> for doing quick omap1 boot testing on? >> >> > If yes, I will cross verify omap1 changes again. >> >> Found the problem. INT_DMA_LCD is handled in mach-omap1/lcd_dma.c. >> In your omap_system_dma_probe we now exit everything if request_irq >> fails for one channel. So let's skip INT_DMA_LCD. >> >> Also, you should check the logic in omap_system_dma_probe as it's >> not very good handling right now. Note how platform_get_irq_byname >> does not free other dma_irqs like after request_irq we do. > > Fixed error handling cases. > >> >> With your patches applied up to patch "Convert DMA library into >> platform driver" + my three earlie fixes + the following fix >> I can now boot OSK5912 and see the penguin on the LCD too. > > Thanks a lot. I pulled in all these fixes into the patch series. > >> >> I suggest you break your series into two where the last patch >> in the first series is "Convert DMA library into platform driver". > > I am ok with this approach. > >> That way the init related changes are done, and we can merge >> those in for testing while you update the rest of the series. > > cool. > > I have done required changes to patch series and tested the same on > omap2+ boards. Can you pls test OSK5912 board boot from the below > git repo? If OSK5912 boots up(with LCD), I will post the 1st series to > LO ML. > > git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git > Branch: dma_testing > commit 3047de5b11cc3fef9ea18a7e8d64fec7a9ea7a89 > Author: G, Manjunath Kondaiah <manjugk@xxxxxx> > Date: Fri Dec 3 20:03:23 2010 +0530 > > OMAP: DMA: Convert DMA library into platform driver > > Convert DMA library into DMA platform driver and make use of > platform data provided by hwmod data base for OMAP2+ onwards. > > For OMAP1 processors, the DMA driver in mach-omap uses resource > structures for getting platform data. > > Thanks to Tony Lindgren <tony@xxxxxxxxxxx> for fixing various > omap1 issues and testing the same on OSK5912 board. > > Signed-off-by: G, Manjunath Kondaiah <manjugk@xxxxxx> > Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx> > Cc: Benoit Cousson <b-cousson@xxxxxx> > Cc: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> > Cc: Santosh Shilimkar <santosh.shilimkar@xxxxxx> > >> >> Also, eventually within next few merge cycles we should have: >> >> arch/arm/mach-omap1/dma.c omap1 specific platform init >> arch/arm/mach-omap2/dma.c omap2+ specific platform init > > This seems to be ok. > >> drivers/dma/omap-dma.c driver using dmaengine.c > > This might require more time. Since this will take more time, can we have run time pm changes on top of existing dma hwmod changes? If so, I can pull out run time pm patch from the dma hwmod series and resend it again. -Manjunath -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html