> -----Original Message----- > From: Shilimkar, Santosh > Sent: Monday, October 18, 2010 9:42 PM > To: G, Manjunath Kondaiah; Kevin Hilman > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: RE: Issue observed with pm_runtime_put_sync > > 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 ? In this case, we might have to check all the 32 channels status(free or used) for every free_dma call. I was thinking to use dev->power.usage_count field for each get_sysnc and put_sync. We can have additional logic in free_dma if get_sync/put_sync is overhead. > > This may not solve your problem but just wanted to understand this. Yes. We need to align on this part. Waitning for kevin's comment on this issue. -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
