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

[jaswinder.singh@linaro.org (Jassi Brar)]

On 17 May 2012 01:12, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> 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!