"G, Manjunath Kondaiah" <manj...@ti.com> writes: > On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote: >> On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote: >> > "G, Manjunath Kondaiah" <manj...@ti.com> writes: >> > >> > > This patch series is remaining part of dma hwmod to support pm runtime >> > > and for handling mstandby mode for all applicable DMA mstandby mode >> > > errata. >> > >> > This is still not runtime-suspending when I use my DMA test in linking >> > mode. >> > >> > If I put a large enough period between transfers, it should autosuspend >> > during transfers. It seems to do auto-suspend and resume once, but then >> > it never suspends again. >> > >> > I tested with my dmatest module[1], and loaded with: >> > >> > # insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 >> > >> > Not only does it not auto-suspend between transfers (which I expected), >> > it also doesn't suspend after removing the module which stops all active >> > channels. >> >> The normal chaining test cases are executed and which used to show the >> proper status. Let me reproduce this issue with your test procedure. > > ok. I am able to reproduce this issue and fixed _get_sync usage in > omap_start_dma if channel linking is used. Earlier it was handled for > the cases with chaining API's. If linking is done without chaining > API's, it will result in _get_sync and _put mismatch.
Great, glad you found it. My DMA test module predates the existence of a chaining API, so I guess that's part of the problem. Glad it helped though. > Thanks for the test case and I will be re posting the patches with the > above fix. Thanks, Kevin -- 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
