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

Stephen Warren swarren at wwwdotorg.org
Wed May 16 13:46:12 EDT 2012


On 05/16/2012 11:37 AM, Jon Hunter wrote:
> 
> 
> On 05/16/2012 12:24 PM, Jassi Brar wrote:
>> On 16 May 2012 22:42, Jon Hunter <jon-hunter at ti.com> wrote:
>>
>>>>> 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.
>>>
>> Any scenario when a client would want to choose which dma controller
>> it runs on?
>>
>> Because when we say a client could be provided a channel on any of the
>> two given dmacs, it implies that the client wouldn't feel any difference.
> 
> That's not my point. I am saying for some reason, maybe QoS, _I_ want to
> specify which mapping used. I am the one that knows how the h/w is being
> used and _I_ want to customise the dma/channel mapping in the DT, such
> that when the client asks for it I know what it is getting. Yes to the
> client, it does not care, but I do.

If you really need to do that, you could always just lie in the DT node
of the DMA controllers you don't want to use, and omit the entry for the
DMA client(s) you don't want to use it.

Still, this all seems like policy that the DT file shouldn't really be
influencing. Admittedly, I'm not sure how else you'd achieve this.



More information about the linux-arm-kernel mailing list