On Fri, Feb 24, 2017 at 11:56:54AM +0100, 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.
Yes a good point. One of the things I would like to see here is the split of
descriptors based on length supported by the device, so driver gets N
prepare operations.
> 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.
The PM is merely a trigger here, the aim is broader redesign of the DMAengine
API as we discussed in KS
--
~Vinod
--
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
