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

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Wed, Mar 07, 2012 at 10:18:42AM +0100, Guennadi Liakhovetski wrote:
> 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.

Well, I am quite convinced (being on my third or fourth DMA engine driver)
that DMA engine does stuff quite wrongly when it comes to slave stuff.
Why?

The code required to support slave device transfers is very much the same
for each driver (that's partly because I'm writing my drivers in the same
way.)  Essentially, slave channels aren't physical channels themselves,
but virtual channels which get assigned to physical channels at some point.
I would really like to see some common infrastructure for handling these
virtual channels so I don't have to write yet another version of that code,
and that's something I'll be working on.

My main critera for selecting a virtual channel is the DMA request signal
into the DMA controller itself, and nothing more.  Most other non-specific
configuration information (data register, data register width, burst size
etc) comes from the peripheral driver.

Any other data relevant to the DMA engine needs to come from the platform
in some way, that being DT or platform data or whatever.  For example,
with a DMA engine which has two bus interfaces, where it matters which
bus interface is used, that needs to be specified by the platform and not
by the DMA engine itself nor the peripheral driver.

That would also include, if relevant, which physical channels a virtual
channel (dma request) could be routed to.

Note that we've been omitting that from the PL08x driver so far - memory-
to-memory requests are supposed to only be handled by a couple of channels
which are designed for that purpose (so they don't flood the bus) but
we currently allocate them to any channel...