On Thu, Mar 02, 2017 at 08:58:40PM +0200, Laurent Pinchart wrote:
> 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.
Descriptor reuse is already suppoeted in the current API.
--
~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
