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

[Stephen Warren]

On 05/07/2012 11:19 AM, Jassi Brar wrote:
> On 7 May 2012 21:23, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 05/05/2012 11:10 AM, Jassi Brar wrote:
>>
>>> Hmm... there ought to be a way by which a client is handed a random 'token'
>>> via its dt node and similarly the dmac informed which channel (and with what
>>> capabilities) to allocate should it see a request coming with that token.
>>
>> I think that's the whole point of the patch.
>>
>> However, the token needs to be some driver-specific struct, since the
>> required information may be more than just a single channel or request
>> ID in general.
>>
> Well, what I call 'token' could just as well be some numerical hash of
> what you call 'driver-specific struct'.
> And I never thought we could do without h/w specific information,
> just that peculiarities lie with the dmac controllers and that's where
> the discerning should happen.
> 
> Our opinions differ in that, I believe client side shouldn't need to
> parse/decode the h/w specific parameters from data gotten via DT
> (what I call 'token' and you 'driver-specific struct') - because that is
> the key to having common client drivers working with different dma
> controllers. And yes, I don't think we could find a future proof generic
> and simple enough representation of dma resource specification in a
> DT node :)

Yes, I don't believe that follows.

The data doesn't need to be part of the DMA controller node in order for
the DMA controller driver to be the entity interpreting it.

In many existing DT bindings, the structure of the client's property is:

phandle specifier

... all possibly repeated n times if you need to represent n resources,
like n interrupts, n GPIOs, n DMA channels/...)

... where specifier is some arbitrary sequence of cells, whose size and
format are entirely determined by the driver for the node referred to by
phandle.

The parsing of this whole construct is hidden inside some utility code,
so clients simply call e.g. of_get_gpio(), which internally calls a
function in the relevant GPIO driver (as specified by the phandle) to
parse the specifier, and return whatever representation of that
specifier is required for the client to either use directly (e.g. GPIO
ID to pass to gpio_request()) or pass back to the relevant APIs for the
driver's subsystem (e.g. complete possibly driver-specific DMA
filter/data representation for dmaengine).

The advantage here is that:

* The specifier is stored in the client, not the IRQ/GPIO/DMA
controller's node, so it's located right at the usage site, which
typically makes working out what resources a client uses easier. This
also keeps client-specific information out of the provider node,
allowing it to be fully generic.

* The client doesn't know anything about the format of "specifier",
since the provider driver parses it, so clients can still work with
arbitrary providers of resources.

> Instead, I suggest we encode the finer details of each channel-request
> in node of the dma controller matched against the 'token' assigned
> to the respective clients.

Well, I guess I addressed that above - there's no need for the data to
be in the DMA controller node for the DMA controller driver to parse it.

> That encoding("channel_id") would be dma
> controller specific and if we also manage to contain it within fixed number
> of bytes we could also have common helpers for fetching it,

I don't think there's any need for it to fit into a fixed number of
bytes; the parsing routine can simply return a pointer to a
driver-specific structure (or perhaps a dmaengine-defined structure,
which in turn might contain a pointer to a driver-specific structure).
That would allow complete flexibility in the representation of the
driver-specific data.

> though
> it still would need to be decoded by dmac controller driver - which I think
> we can't do without, considering the variety of dma floating around.