lkml.org 
[lkml]   [2012]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()
(changed Russell's address to the one from MAINTAINERS)

On Wed, 7 Mar 2012, Vinod Koul wrote:

> On Tue, 2012-03-06 at 14:03 +0100, Guennadi Liakhovetski wrote:
> <adding few folks to thread, who i may be intrested in this discussion>
> > But the DMAC is certainly a better match for making channel-selection
> > decisions.
> I am not sure about that as well...
> >
> > > Bigger question is who knows about this mapping and how do we
> > > incorporate this mapping into channel allocation
> >
> > The platform does. And this knowledge has to be passed to the relevant
> > driver. But I think it's the DMAC driver, that is relevant, not the client
> > driver. The platform would supply information like
> >
> > DMAC #1
> > channel #1
> > (can be used for) device #1
> > device #2
> > ...
> > channel #2
> > ...
> > ...
> right :-)
> and we need to ensure that somehow this information is presented to
> dmaengine and dmaengine uses this information to filter the channel
> requests. In past we had good discussion [1], [2], [3] on this topic but
> unfortunately nothing came out of it.
>
> I like the approach outlined by Linus W [1], where we can get the
> information from platform (DT, FW,....) and its presented to dmaengine.

I still don't see an answer to the very same question, that we've been
discussing over multiple threads and mails now: how do we use that, if
it's not a 1-to-1 mapping? I.e., many channels on many controllers can be
run-time configured for use with different client devices. Also the above
idea from Linus W doesn't directly address this.

Following his clock / regulator analogy. There the correspondence is
clearly fixed: fixed clocks and power supplies are used with every
specific device. Whereas in our DMAC case it's not.

I'm trying to think of an analogy, where you have several pools of
resources, and each consumer can use any of the resources on some of those
pools, but nothing pops up. Interrupts, GPIOs, clocks, regulators - they
all are fixed to their consumers.

Also notice, this can become even worse, if we ever get controllers with
channels with different capabilities on them. So, I really would let the
DMAC driver do the mapping and not try to put it in the core.

Thanks
Guennadi

> I think we need to solve this _now_. There are two aspects
> a) to ensure dmaengine understand channel-client mapping. For this we
> can start with idea in [1] and see if this suits everyones needs
> b) how to ensure the platform gives this information in variety of arch
> we have (arm, x86, sh-....)
>
> Thoughts...?
> > And I don't think, it would be reasonable to let every slave driver use
> > this information. These lists can also be optimised for specific
> > platforms. E.g., on some sh-mobile SoCs you have two DMAC types. One of
> > them can serve devices from list A on any channel, the other one - from
> > list B. So, all you have to do, is to reference either A or B from your
> > DMAC platform data. Whereas doing a reverse mapping: for each (potential)
> > DMA user reference a list of channels, that it can use - would be really
> > clumsy.
> >
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/060717.html
> [2]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/059212.html
> [3]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/059217.html
>
>
> --
> ~Vinod
>

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

\
 
 \ /
  Last update: 2012-03-07 10:21    [from the cache]
©2003-2011 Jasper Spaans