Hi Arnd

On Fri, 15 Jun 2012, Arnd Bergmann wrote:

On Thursday 14 June 2012, Jon Hunter wrote:

quoted

quoted

Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot.

Generic DMACs can serve any slave (peripheral) request line on any their 
physical channel, USB DMACs only serve fixed USB controller instances. To 
configure (connect) a certain physical DMA channel to s specific 
peripheral request line, a certain value has to be written to a 
configuration register of that physical DMA channel.

Do you still need to specify a request line for the USB DMACs or are
these fixed? In other words, what purpose would the DMA binding serve
for the USB DMACs?

If I understood Guennadi right, the DMA engines are the same kind as the
other ones, so we really want to use the same bindings for each instance.

Exactly, at least they are compatible and are presently handles by the 
same dma-engine driver. There are some differences in the register layout, 
I think, which we might need to handle at some point, maybe by specifying 
different "compatible" identifiers or by some other means.

quoted

quoted

To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic 
DMACs (DMAC0) have external DMA request pins, others don't.

OMAP also has this. To me an request line going to an external pin can
be handled in the same way as one going to a internal peripheral.
However, what happens to that pin externally is a different story.

Right, I don't see a problem here with any of the proposed binding.

quoted

quoted

I'm sure there's more to that, but that's about the scope, that's 
currently supported or wants to be supported by the driver.

Currently we do the slave-switching in the following way: platform data 
for each DMAC instance references a table of supported peripherals with 
their IDs and configuration register values. Each peripheral, that wishes 
to use DMA, provides its slave ID to the DMAC driver, by which it checks, 
whether this peripheral is supported and, if so, finds its configuration, 
picks up the next free channel and configures it.

So, with the above in mind, IIUC, the above DT binding proposal would 
require us to reference all 3 generic DMAC instances in each slave dmas 
property? 

You could if you wanted to have the ability to select 1 out of the 3.
However, I would not say it is a hard requirement. You could just
provide one. Or you could list all 3, but use some form of match
variable to indicate a default DMAC for a given peripheral.

Right. From the description above, it seems that shmobile is actually
simpler than some of the others because the slave ID is always the
same for each of the controllers.

Exactly.

In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
controller with its slave ID separately, even if that means a lot
of duplicate data for shmobile.

So, you don't think it's worth making a short-cut possible to specify a 
DMAC type instead of each instance phandle? It really would mean __a lot__ 
of duplication - with 3 generic controllers on (some) current chips and 
possibly more on those, that I'm not aware about.

I'm not sure I understand what the "configuration register values"
above are.

As I explained in an earlier mail, those include transfer size and other 
parameters, but cannot be completely calculated in device drivers, because 
they also vary between SoCs.

Most likely, those should all be part of the slave ID,
which would then span multiple 32-bit values in the "dmas" property.

Yes, we could do that.

Conveniently, that also takes care of removing the DMAC platform data.

Right, my only concern so far is a huge redundancy, that accepting and 
using the proposed scheme would incur.

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