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

[Jon Hunter <jon-hunter@ti.com>]

On 05/16/2012 11:16 AM, Jassi Brar wrote:
> On 16 May 2012 21:31, Jon Hunter <jon-hunter@ti.com> wrote:
>> On 05/16/2012 08:15 AM, Jon Hunter wrote:
>>> Hi Jassi,
>>>
>>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>>> Hi Jon,
>>>>
>>>> On 16 May 2012 06:41, Jon Hunter <jon-hunter@ti.com> wrote:
>>>>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>>>>>
>>>>>> +       i2c1: i2c@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.
>>>>>
>>>>> Actually, no. The phandle in the DT specifies the DMA controller to use.
>>>>> Then the client simply asks for a channel with a particular property,
>>>>> for example, DMA_MEM_TO_DEV (ie. TX) and the channel information is return.
>>>>>
>>>> See below.
>>>>
>>>>>> 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.
>>>>>
>>>>> Yes that is the intention here.
>>>>>
>>>> But the client is required to specify the dmac that would serve it.
>>>> Which is more
>>>> than simply asking for "some suitable channel".
>>>
>>> No this is not the case with what I propose. The client knows nothing
>>> about the dmac.
>>
>> By the way, I do see your point. You wish to describe the all the
>> mappings available to all dma controllers and then set a mapping in the
>> device tree. Where as I am simply setting a mapping and do not list all
>> other possibilities (assuming that there some).
>>
>> What is still unclear to me, is if you use this token approach how
>> readable is the device-tree? For example, if you have a client that can
>> use one of two dmac and for each dmac the request/channel number is
>> different, then by using a global token how can I determine what the
>> options available for this client are?
>>
> Simple - you/client need not know about any option at all :)
> 
> Client driver would simply request some channel and if it
> doesn't get it, it bails out.
> 
> It would be the DMACs' DT node that would contain that info.

Yes, but what if I am doing some custom application and want to modify
the mapping that is being used? So I just wanted to make sure it is easy
to understand assuming that you understand what your h/w is capable of.

>> Take your example ...
>>
>> mmc1: mmc@13002000 {
>>        ...
>>        dma_tx = <891>   //some platform-wide unique value
>>        dma_rx = <927>   //some platform-wide unique value
>>        ...
>> };
>>
>> DMAC's Node:-
>>
>> pdma2: pdma@10800000 {
>>         .......
>>        dma_map = <891, 7>,       // Map mmc1_tx onto i/f 7
>>                  <927, 8>,       // Map mmc1_rx onto i/f 8
>>        .......
>> };
>>
>> But now I have another dmac which has the following options ...
>>
>> pdma1: pdma@10000000 {
>>         .......
>>        dma_map = <598, 2>,       // Map mmc1_tx onto i/f 2
>>                  <230, 3>,       // Map mmc1_rx onto i/f 3
>>        .......
>> };
>>
> No, rather the pdma1 node should look like
> 
>  pdma1: pdma@10000000 {
>          .......
>         dma_map = <891, 2>,       // Map mmc1_tx onto i/f 2
>                    <927, 3>,       // Map mmc1_rx onto i/f 3
>         .......
> };
> 
> Because the tokens 891 and 927 are came from the client's node/driver.
> 
> After the DMAC driver has probed both pdma-0 & 1, it would
> know that MMC1 could be served by 2 DMACs. And basically
> its the dmac driver that should be making about routing decisions,
> not the client.
> 
> Btw, everything remains same, only we have now decided to not
> use tokens but phandle+req_sig_ids instead.

Ok, yes Stephen clarified that too. Makes sense.

Cheers
Jon