Manju, > -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of G, Manjunath Kondaiah > Sent: Monday, October 18, 2010 9:31 PM > To: Kevin Hilman > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: RE: Issue observed with pm_runtime_put_sync > > > Kevin, > > > -----Original Message----- > > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > > Sent: Monday, October 18, 2010 9:01 PM > > To: G, Manjunath Kondaiah > > Cc: linux-omap@xxxxxxxxxxxxxxx > > Subject: Re: Issue observed with pm_runtime_put_sync > > > > Manjunath, > > > > "G, Manjunath Kondaiah" <manjugk@xxxxxx> writes: > > > > > [...] > > > > Is this a known issue or issue with pm runtime API usage in > > DMA driver? > > > > It's an issue in the runtime PM usage in DMA driver. > > > > Specifically, the _sync versions of the API cannot be used > > from interrupt context because they can sleep. > > > > Are the _sync versions really needed at that point? Without > > having the code, I cannot tell, but I susupect that the async > > versions could be used there instead. > > > > If not, then the code will need to be reworked so the ISR is > > not doing the actual work, but instead is scheduling work to > > be done later in process context. > > It looks to me this issue is related to DMA client driver since > DMA driver only invokes call back function registered during dma channel > setup. The control will be passed to DMA client driver. Now it is > responsibility of DMA client driver to invoke free_dma(free_dma will > invoke put_sync) from non interrupt context. > > Most of the times, callback will indicate end of data transfer, the > client driver will release all DMA resources from interrupt context > itself. > Why are you doing put_sync/get_sync per channel alloc/free. DMA has a single clock and not each for per channel. The driver should release DMA clocks when all channels are free and acquire it on the first channel request. We did discuss this sometime back on the LO, right ? This may not solve your problem but just wanted to understand this. Regards, Santosh -- 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
