"G, Manjunath Kondaiah" <manjugk@xxxxxx> writes: > > 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. IMO, that is an unnecessary restriction. There is no reason that I can think of that omap_free_dma() needs to do a _put_sync(). It should just do a normal (asynchronous) _put(), which is safe from either process or 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. That's fine, and is something the DMA API has supported in the past, and there's no reason it couldn't continue to support that. Kevin -- 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
