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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux