On Fri, Aug 01, 2014 at 10:57:07AM +0200, Maxime Ripard wrote: > On Fri, Aug 01, 2014 at 10:00:10AM +0200, Lars-Peter Clausen wrote: > > On 07/31/2014 07:37 PM, Maxime Ripard wrote: > > >On Thu, Jul 31, 2014 at 06:54:11PM +0200, Lars-Peter Clausen wrote: > > >>On 07/31/2014 06:13 PM, Maxime Ripard wrote: > > >>[...] > > >>> From what you're saying, and judging from the drivers that already > > >>>implement it, can't it be moved directly to the framework itself ? > > >>> > > >> > > >>What exactly do you mean by moving it directly to the framework? The > > >>slave_caps API is part of the DMAengine framework. > > > > > >Not its implementation, which is defined by each and every driver, > > >while the behaviour of device_slave_caps is rather generic. > > > > > > > Do you mean something like adding a dma_slave_caps struct field to > > the DMA channel that gets initialized when the channel is created > > and then remove the callback? That makes some sense. > > I was rather thinking into something like: > - Splitting device_control into independant functions I like this part :)
> - Then, knowing if you support pause/resume/terminate is trivial: > either you implement the callback, or you don't > - Putting the supported width and direction into fields of struct > dma_device, which can eventually be used by the framework to > filter out invalid configurations before calling the relevant > callbacks thats is a good idea > - That would then be trivial to get from the framework, without > calling any callback Yes please -- ~Vinod
signature.asc
Description: Digital signature
