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.
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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
