Hi Arnd 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. 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/ -- 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
