Re: Issue observed with pm_runtime_put_sync

[Kevin Hilman <khilman@deeprootsystems.com>]

"G, Manjunath Kondaiah" <manjugk@ti.com> writes:

>  
> Kevin,
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>> Sent: Monday, October 18, 2010 9:01 PM
>> To: G, Manjunath Kondaiah
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: Issue observed with pm_runtime_put_sync
>> 
>> Manjunath,
>> 
>> "G, Manjunath Kondaiah" <manjugk@ti.com> 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