On Thursday 02 Mar 2017 10:33:21 Vinod Koul wrote:
> 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
I was going to mention that. PM support is needed, but on top of that the
ability to reuse descriptors would be a good to have by itself.
--
Regards,
Laurent Pinchart
--
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
