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/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
