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

[Jassi Brar]

On 4 May 2012 20:47, Jon Hunter <jon-hunter at ti.com> wrote:
> Hi Jassi,
>
> On 05/04/2012 01:56 AM, Jassi Brar wrote:
>> On 1 May 2012 02:47, Jon Hunter <jon-hunter at ti.com> wrote:
>>> From: Jon Hunter <jon-hunter at ti.com>
>>>
>>> This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
>>> to add some basic helpers to retrieve a DMA controller device_node and the
>>> DMA request/channel information.
>>>
>>> Aim of DMA helpers
>>> - The purpose of device-tree (as far as I understand), is to describe the
>>>  capabilites of the hardware. Thinking about DMA controllers purely from the
>>>  context of the hardware to begin with, we can describe a device in terms of
>>>  a DMA controller as follows ...
>>>        1. Number of DMA controllers
>>>        2. Number of channels (maybe physical or logical)
>>>        3. Mapping of DMA requests signals to DMA controller
>>>        4. Number of DMA interrupts
>>>        5. Mapping of DMA interrupts to channels
>>> - With the above in mind the aim of the DT DMA helper functions is to extract
>>>  the above information from the DT and provide to the appropriate driver.
>>>  However, due to the vast number of DMA controllers and not all are using a
>>>  common driver (such as DMA Engine) it has been seen that this is not a
>>>  trivial task.
>>>
>> Sorry for being slow, but so far I thought DT is only to provide _h/w_
>> specific info
>> to the _controller_ drivers. It was not supposed to provide any info
>> pertaining to
>> some API (dmaengine in this case).
>>
>> And I believe this is one of few situations where we are better off
>> not generalizing
>> the interface - pass controller specific info in the controller
>> driver's specified format.
>> Generalizing only seems to complicate things here, when we anyway have machine
>> specific dtb, which could always have clients requesting and the
>> controllers given
>> dma's info in controller driver's specific format.
>>
>> Perhaps I am overlooking the need to generalize. If you think so, please help me
>> understand by pointing out some use case for it.
>
> No not really, your points are valid. From reading the previous
> discussions one of the items that was clearly lacking was the ability to
> represent and identify a device having more than one DMA controller. In
> other words, when you request the DMA resource, how do you identify
> which DMA controller in the system that resource belongs too. With DMA
> engine there are ways we can do this.
>
Well, if we really can't have dmac drivers make 'intelligent' runtime decision
of request mapping on more than one capable controllers, we still can
make it simpler than the proposed scheme.

+       i2c1: i2c at 1 {
+               ...
+               dma = <&sdma 2 1 &sdma 3 2>;
+               ...
+       };
>
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.

I think such client->req_line map should be provided to the dmac controller
driver via its dt node in some format. The dmac driver could then populate
a dma_chan, or similar, only for that req_line and not for the unused one
which otherwise could also have served the same client.

Ideally the I2C driver should simply ask, say, a channel for TX and another
for RX, everything else should already be setup via dmac's dt nodes.

Channel properties like duplex, priority etc specified in client's dt node
doesn't seem really necessary - the client's driver is able to adjust
according to the capability of the channel the dmaengine api is able
to provide and the client driver can't really do anything if it saw "txrx"
specified in it's dt node while it doesn't yet support full-duplex (say).

Having spilled my guts and realizing the fact that the Maradonas and Peles
of the game seem to have already bought the scheme, I am afraid it only
points to my not yet diagnosed adhd  :o