Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()

[Vinod Koul <vinod.koul@intel.com>]

On Fri, 2012-03-16 at 15:11 +0100, Linus Walleij wrote:
> On Fri, Mar 16, 2012 at 12:09 PM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
> 
> > And the least important question: who and when will implement the core
> > support for this?
I will try to do the dmaengine work for 3.4. The code for each platform
needs to come from you guys :-)
> 
> I'm trying to call the kernel HR department to hire a consultant for me but they
> just put me on the phone queue all the time, I don't know what I might be
> doing wrong ... :-)
> 
> If the question is whether we need more people writing complicated core
> patches for the dmaengine I think the answer is "yes"?
> 
> > 1. the client issues a dma_request_channel() with _just_ a capability mask
> > and a filter and its argument as parameters - _nothing_ about channel
> > restrictions.
> >
> > 2. you propose to eliminate a filter - the core has no way to know, which
> > channel to pick up...
> 
> Nah, thinking about it...
> 
> Eliminate the external filter, make it internal. We already have the
> problem that these filter functions need to be passed around too much
> in platform data e.g. so we need to do away with it.
> 
> The filter functions seem to come from the DMA drivers
> themselves mostly. (Help me with the complete picture here...)
> For example:
> 
> amba-pl08x.c:bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
> coh901318.c:bool coh901318_filter_id(struct dma_chan *chan, void *chan_id)
> pl330.c:bool pl330_filter(struct dma_chan *chan, void *param)
> sirf-dma.c:bool sirfsoc_dma_filter_id(struct dma_chan *chan, void *chan_id)
> ste_dma40.c:bool stedma40_filter(struct dma_chan *chan, void *data)
> 
> So delete the typedef for dma_filter_fn remove these filters from
> external header files.
> 
> And stop that thing from being passed around and into
> struct dma_device so the dmaengine core can still filter or process
> channels, but nothing on the outside need to know about it. That way
> we can centralize it to drivers/dma and not spread it out throughout
> the kernel.
The _only_ reason why we issue with filters is due to simple reason of
having no way to map channels. So everyone decided to do it as they
deemed fit.
With platform giving you channel map, and dmaengine doing filtering, do
you need filter??
> 
> > 3. the wrapper, proposed by Russell, now calls dmaengine_slave_config(),
> > which fails, because that's a wrong channel (hope I get this right this
> > time - configuration has nothing to do with selection:-))
> 
> Oh I was not thinking of relying on config to sort out channels.
NO. That maybe true for sh-mobile or for you, but generically that is
not the case. Channel config and selection/mapping are orthogonal
concepts so lets keep them so.
> 
> I was thinking of internalizing the dma_filter_fn and make it an
> (optional, maybe?) part of dmaengine.
> 
> > 4. that's it, if you start again - the dmaengine core will enumerate the
> > same channels again and propose the same unsuitable channel to you -
> > there's no way to continue to the next channel / device.
> >
> > What am I missing? How is the mapping going to be used, if you eliminate
> > the filter function?
> 
> As above, I guess factoring away the filter functions would be
> the first real hard problem.
One we have good mapping solution, they would go away on its own, as
people just call dma_request_channel()

-- 
~Vinod