[PATCH] of: Add generic device tree DMA helpers

[Cousson, Benoit]

On 3/19/2012 4:20 PM, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
>> On 03/18/2012 09:13 PM, Arnd Bergmann :
>>> On Saturday 17 March 2012, Grant Likely wrote:
>>>>> +static LIST_HEAD(of_dma_list);
>>>>> +
>>>>> +struct of_dma {
>>>>> +     struct list_head of_dma_controllers;
>>>>> +     struct device_node *of_node;
>>>>> +     int of_dma_n_cells;
>>>>> +     int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
>>>>> +};
>>>>
>>>> This _xlate is nearly useless as a generic API.  It solves the problem for
>>>> the specific case where the driver is hard-coded to know which DMA engine
>>>> to talk to, but since the returned data doesn't provide any context, it
>>>> isn't useful if there are multiple DMA controllers to choose from.
>>>>
>>>> The void *data pointer must be replaced with a typed structure so that
>>>> context can be returned.
>>>
>>> I've read up a bit more on how the existing drivers use the filter
>>> functions, it seems there are multiple classes of them, the classes
>>> that I've encountered are:
>>>
>>> 1. matches on chan->device pointer and/or chan_id
>>
>> I have the impression that we are now talking about *channel* selection.
>> It is not the purpose of those helper functions. It is just to retrieve
>> a *request line* for a particular slave interface.
>
> The request line on what though?  The DMA controller, or something
> else?

The idea is just to represent the request line from the IP to the DMA 
controller. This is exactly the same pattern than for the IRQ line 
toward the IRQ controller.

> The reason I ask is because on ARM boards, the DMA controller has N
> request lines.  Three of those request lines are multiplexed in an
> external FPGA to select between N different peripherals.
>
> For example, the UART and MMCI may be routed to the FPGA multiplexer,
> and either could be routed to DMA controller request signal 0, 1, or 2,
> whereas a different UART might be routed directly to DMA controller
> request signal 3 and 4.
>
> At the moment, we handle this via platform data and callbacks passed
> into the PL080 DMA driver, by matching virtual DMA channels based upon
> strings looked up in the platform data.  This gives the range of
> DMA request signal numbers on the controller, and calls a platform
> provided function to setup the multiplexer.
>
> Clearly, if your proposal is all about DMA controller request signals
> only, the above scheme can't be represented in DT...

Yes, this is the goal. I guess in your case you do need some DMA nexus 
node like DT is already providing for the IRQ. But you still should be 
able to describe how the HW blocks are interconnected.

> and that's what
> worries me - the fact is that the DMA engine API can and does cope
> with this but it seems that we're building restrictions in with DT on
> what can be represented.

But then you are mixing the SW representation and the HW one. DMAengine 
is the Linux way of managing DMA channel. DT is supposed to be OS 
agnostic and just describe the HW.
So you cannot take into account some DMAengine specificity to define the 
DT binding. At least in theory.

> That makes me wonder whether the model that's being chosen is anywhere
> near correct for the DMA engine API.

That's not the goal. The goal is to describe how the DMA request lines 
are connected from the IP to the controller.

> Now, as I've said before, I'm trying to work on creating an OMAP DMA engine
> implementation, and I'd _really_ like to have the freedom to do what's
> necessary there without having to think one bit about DT getting in the
> way.  To put it another way, I don't want to be constrained by any weirdo
> DT representations at the moment, and I really don't want to waste time
> discussing them at the moment, rather than getting on with that job.
> Because if I end up discussing this at length, I'm not going to be able
> to do anything on the OMAP DMA engine stuff.

The current way of representing the DMA requests for OMAP SDMA is pretty 
straightforward and fit well with the current binding. It looks to me 
that this is the ARM boards that will be tricky to handle.

Regards,
Benoit