On 17 May 2012 01:12, Arnd Bergmann [off-list ref] wrote:

quoted

Generic binding to provide a way to provide the client-channel map and
other dmac specific parameters to the dma controller driver

DMA Model:-
  Only the most common characteristics of a dma setup are assumed
in this binding.
Client: Some h/w controller that could request a DMA controller in
the system to perform data transfer on its behalf. Example SPI, MMC,
I2S etc.
DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc.

 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.

Btw, just to be clear... this is not _my_ setup.
The dma controller manuals might use different terms but underneath
most(if not all) dma controllers fit this model. At lease every dmac
on Samsung SoCs and ARM's PL330 and PL08x does.
In fact, I have trouble imaging some dmac not conforming to this model...
but then again it could be just me.

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.

The idea was that a client shouldn't need to know/tell which dma controller
serves it or which peripheral interface of a dma controller.
I think in future third-party device IPs, like ARM's Primecell, are only gonna
get more common so it makes even more sense.

I believe that it can work and that it solves the problem you are
faced with at minimal complexity, but you put the burden of this
complexity on everybody who does not have this issue, and make
the general binding confusing and harder to read.

I am sorry if I gave you the wrong impression, but I didn't intend to just
scratch my personal itch. I truly believed I and Stephen reached a generic
solution i.e, as much as it could be.

It also adds much more data to the device tree (in source and binary form)
because you need to describe every device using a dma controller
and have a label to reference it.

I don't see why one can't add entries to chan-map as and when more
clients appear for the DMAC ? It should be perfectly ok to specify less
than the maximum possible clients in chan-map.
Requiring labels - yes, doesn't sound very nice, but many nodes already do.

More importantly, you make it very hard to add devices in a board file
to a dma controller that already has descriptions for some channels,
because you cannot easily extend the chan-map unless you rewrite all of it.

I am not sure I understand the point.

We really need something simpler than this for the common case.
I have already made suggestions for how to make it still possible
to cover the corner case of multiple dma engines connected to the
same slave, which would keep the complexity local to those devices
that actually need it.

Thanks $DEITY, I posted a preview. Maybe I should put it on hold.
And thank you for speaking up immediately. Really!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html