[PATCH V3 1/2] of: Add generic device tree DMA helpers
g.liakhovetski at gmx.de
Fri Jun 15 05:18:53 EDT 2012
On Fri, 15 Jun 2012, Arnd Bergmann wrote:
> On Thursday 14 June 2012, Jon Hunter wrote:
> > > 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.
> > > 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.
> > > 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.
> 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.
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
More information about the linux-arm-kernel