On 02/24/2017 12:37 PM, Marek Szyprowski wrote:
> Hi Lars,
>
> On 2017-02-24 11:56, Lars-Peter Clausen wrote:
>> On 02/24/2017 01:13 AM, Vinod Koul wrote:
>>> There have been discussions on need for change of dmaengine API for
>>> a) allow sleepy invocation of the prepare descriptor so that drivers can
>>> do the runtime pm (maybe move into core as well)
>>> b) split the prepare operation to allocate and new prepare methods
>>>
>>> TBD: Should the new prepare be atomic or not
>>> TBD: Should we move the pm calls to core
>>> TBA: Documentation and wrappers for these calls
>> I'm not convinced by this approach. You only know how much memory you need
>> to allocate once you know what the content of the DMA descriptor is. E.g.
>> depending on the length of the transfer the transfer might need to be split
>> into multiple internal segments. So you'd still have to do a alloc operation
>> in the device_desc_prep_slave_sg() callback.
>>
>> For PM I'd much rather have explicit PM operations which signal intent to
>> use the DMA channel. E.g. dmaengine_channel_pm_{get,put}() or something
>> similar. For audio these could for example be called when the PCM device is
>> opened/closed.
>
> I also vote for this approach.
>
> The only question is how to handle the case of old client driver (which
> doesn't do new calls) and new dma engine driver (which requires new calls).
> Should we assume that the dmaengine channel is pm active after
> dma_request_chan() and has to be explicitly turned off first if not used by
> the client?
>
> The other possibility would be to add yet another function to request channel
> (like dma_request_channel_suspended()) and add dmaengine_channel_pm_get() to
> the current dma_request_chan() function in the dma engine core.
Yeah, I guess one of the two. Or some kind of opt-in function before the PM
functions can be used (dmaengine_channel_enable_pm()).
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
