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

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

On Wed, 7 Mar 2012, Russell King - ARM Linux wrote:

> 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.

Right, I thought about virtual DMA channels, but I really hoped we 
wouldn't have to do that;-) Would we then also have to use virtual DMAC 
instances? Given that the core operates in terms of DMA-controller devices 
and channels and the hardware is also built around those concepts, it 
seems a natural choice to use a 1-to-1 correspondence.

In the sh-mobile case, AFAIK, until now we can have N DMA controllers of M 
types. Within each type the controllers are identical, meaning also, that 
all channels on them can be configured to work with all the same devices. 
Currently that's also what we present to the dmaengine core and to 
clients: N controllers. Whereas it has been suggested a couple of times, 
that neither the core nore clients should be bothered with specific DMA 
controller instances, so, we might as well just present M virtual 
controllers to the system - 1 of each type, each with a unique capability 
set?

Thanks
Guennadi

> 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...
> 

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