On Wed, May 16, 2012 at 07:42:20PM +0000, Arnd Bergmann wrote: > On Wednesday 16 May 2012, Jassi Brar wrote: > > The assumed model of the DMAC, in this binding, has P peripheral > > interfaces (P request signals) that could request a data transfer > > and C physical channels that actually do the data transfers, hence, > > at most C out of P peripherals could be served by the DMAC at any > > point of time. Usually C := P, but not always. Usually, any of the > > physical channels could be employed by the DMAC driver to serve any > > client. > > The DMAC driver identifies a client by its i/f number, 'peri_id' > > on the given DMAC. For example, TX for SPI has 7th while RX_TX > > (half-duplex) for MMC has 10th peripheral interface (request-signal) > > on a given DMAC. Usually, any of the physical channels could be > > employed by the DMAC driver to serve a client. > > I'm still anything but convinced by this model. Basically it's the > exact opposite of what we do for every other subsystem (irq, pinctrl, > regulator, gpio, ...), where the device using some infrastructure > contains the information about who provides it, whereas here you > move all the information into the device that provides the functionality, > and have no handle in the device using it by which the driver can > identify it. I think the biggest difference between DMA and other subsystems is that other systems have only one provider. DMA on the other hand seems to have cases where you can make a choice between two or more providers of the service. The impression that I'm getting from this thread is that it's difficult to describe that kind of relationship in DT - DT is good at describing "A provides X to C" but not "A _or_ B provides X to C and you can chose either A or B depending on <something> to satisfy X". -- 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
