[lkml]   [2012]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()
On Thu, 8 Mar 2012, Linus Walleij wrote:

> On Thu, Mar 8, 2012 at 11:16 AM, Guennadi Liakhovetski
> <> wrote:
> >(...) our case can be handled _very_ easily:
> >
> > 1. a client requests a channel of a specific type
> > 2. one of channels of that type, residing on one of compatible
> >   controllers, is allocated, configured and handed in to the client
> >
> > That's it. No filtering, no post-allocation configuration - at least so
> > far. And penalising such a simple case by forcing it to use virtual
> > channels and filter through some unnatural mappings doesn't seem very
> > productive to me.
> But you do realize that this increases the complexity of the
> dmaengine and means more maintenance burden for the
> subsystem maintainer that will after this have to think in two
> different sematic ways about channel retrieveal - yeah this one
> passes that as parameter and this one has a config struct
> provided, then this one use a filter function still - etc.

Yes, I do. This is why I've marked it an RFC - I'm open to a discussion,
what's the best solution to suit us all.

> That is, of course, unless you convert all the existing DMA
> engines to do it the same way, then it's redesigning proper.

No, don't think it would be reasonable or maybe even possible to
completely remove the filter. At least this wasn't an (immediate) goal of
this patch. However, if we decide, that in principle such an API extension
should make filters redundant, we can gradually over time look at various
drivers and get rid of the filters.

> In that case I am much more positive to the change, even
> if it doesn't take us all the way to the new channel mappings
> we want to have.
> You haven't stated whether you will go in and rewrite the other
> drivers to use this scheme or whether you will just add this one
> kludge to handle this one DMA controller, then just update
> all others to ignore the parameter. (You'd obviously have to
> do that to get this to even compile...)
> So the *proper* way to refactor to using this scheme would
> be to introduce this new scheme *and* remove the filter
> function from all the other drivers and DMA engine at large,
> so it's not needed anymore. Which means a bit of refactoring.
> Currently drivers have to pass a filter function from
> platform data to filter out relevant channels, and with
> the new style (this patch plus removing all filter functions)
> it will be passing something else instead. That's all
> fine, and actually an improvement, because passing around
> a filter function is not as good as passing some struct
> with data.

Agree in principle, but I don't think I can claim, that I'm sufficiently
certain, that all drivers can be reasonably converted. At least, thinking
again about Russell's approach to implementing filters in DMA device
drivers themselves, it seems to me, it should indeed be possible to quite
easily just pass the same argument, that's currently passed to the filter
function, to the allocation request instead and call the filter internally
in .device_alloc_chan_resources() in the very beginning instead.

> So does RFC patch mean you will fix this up for everyone
> or does it mean something else?

I currently count almost 40 calls to dma_request_channel() and around
20-25 DMA drivers in the kernel... So, I'm not sure whether it's
reasonable to try to pull such a change globally over one release cycle.


> If you're not also planning to get rid of the filter functions
> for all other drivers I don't see this going anywhere right
> now. It is not beneficial for dmaengine, the only benefit
> is one more kludgy driver to maintain.
> Yours,
> Linus Walleij

Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2012-03-08 13:39    [W:0.364 / U:4.732 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site