[PATCH V3 1/2] of: Add generic device tree DMA helpers

[Guennadi Liakhovetski]

On Thu, 14 Jun 2012, Jon Hunter wrote:

> 
> On 06/14/2012 10:17 AM, Guennadi Liakhovetski wrote:
> > Hi all
> > 
> > Sorry for jumping in so late in the game. But I think, the model, to which 
> > this discussion is slowly converging, is not very well suitable for the 
> > shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and 
> > the model is indeed suitable, in which case I'd be grateful, if someone 
> > could explain, how this model could be used for shdma. Below I'll try to 
> > describe main properties of shdma served DMACs, I've done this a couple of 
> > times before during various dmaengine related discussions. Let's see how 
> > we can use this model for these SoCs.
> > 
> > On Sat, 9 Jun 2012, Arnd Bergmann wrote:
> > 
> >> On Friday 08 June 2012, Jon Hunter wrote:
> > 
> > [snip]
> > 
> >>> It seems to me we were pretty close on alignment. In fact, I was quite
> >>> happy with Steven's 2nd to last proposal of  ...
> >>>
> >>> simple 1 req:
> >>> dmas = <0 &dmac1 xxx>;
> >>>
> >>> simple 2 req:
> >>> dmas = <0 &dmac1 xxx 1 &dmac1 yyy>;
> >>>
> >>> multiple dmacs:
> >>> dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>;
> > 
> > A typical sh-mobile SoC contains several DMAC instances of several 
> > sub-types, all served by the same driver. Let's take sh7372 to be 
> > specific (see arch/arm/mach-shmobile/setup-sh7372.c for details). On 
> > sh7372 we've got 3 generic DMAC instances and 2 dedicated USB DMACs.
> > 
> > Generic DMACs have 6 physical channels each, USB DMACs 2.
> 
> For OMAP we also have dedicated DMAC for the USB controllers. However,
> these DMAC are very much integrated into the USB controller itself.
> Hence, in the of OMAP we would only be using the binding really to
> handle the generic DMAC. However, I would not like to think that this is
> limited to only generic DMAC.
> 
> > 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?

I personally haven't worked with the renesas_usbhs USB driver or with the 
respective DMA driver part, but from what I can see, no "slave-select" 
values are required, i.e., request lines seem to be fixed.

> In other words, what purpose would the DMA binding serve
> for the USB DMACs?

The USB driver has to tell the dmaengine which DMAC instances are suitable 
for it, and which are not.

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

As has been discussed before, the presence of external DMA request lines 
makes specifying fixed DMA channel maps in SoC dtsi files impossible.

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

Sorry, I don't think artificially limiting the flexibility to just 1 
controller is a good option. The option of listing all 3 in each device 
doesn't seem too good to me either. What if a future SoC version has 5 of 
them? I really would prefer to have a list of "generic" DMAC instances 
somewhere and be able to omit any explicit references to specific DMACs in 
device DMA bindings. I can also imagine a possibility, that in the future 
we won't have just one "generic" DMAC type, but, say, 2 DMAC groups, 
serving different, but possibly intersecting, sets of devices. In that 
case I'd just like to be able to specify "use group A" in the binding. Do 
I understand correctly, that with the proposed scheme this is impossible?

> > Even if we assume, that for this specific case we don't have to 
> > map each physical channel, because so far they are "mostly" all equal on 
> > each DMAC instance. Mostly, because external DMA request lines on sh7724 
> > can only be used with channels 0 and 1 out of 6 of DMAC0... What we 
> > certainly don't want to do is specify fixed physical DMA channels or even 
> > controller instances in slave DMA bindings.
> 
> You could just use the binding to return a handle to one DMAC and then
> just request a channel. I don't see that the binding would require you
> to specify fixed channels.

That's good, but as I said above, I'd also like to be more flexible in the 
selection of DMACs.

> > To me it looks like the above proposal would only very suboptimally be 
> > usable with sh-mobile SoCs...
> 
> I guess I don't see that, but then again I am not familiar with the all
> the details of the SH devices.
> 
> However, thinking about it some more, if a DMAC is this generic, what
> information do you want the binding to provide?

Configuration data for the DMAC. Currently this consists (apart from FIFO 
access register addresses) of 2 values: a magic value, specifying a 
certain slave (DMA request line selection), and a value for a 
configuration register. The latter contains information about transfer 
sizes, repeat / reload modes, address incrementing policies etc. These 
seem to be computable, but they are at least partially SoC-specific too.

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