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

Cousson, Benoit b-cousson at ti.com
Mon Feb 27 09:22:48 EST 2012

On 2/27/2012 2:09 PM, Nicolas Ferre wrote:
> On 02/23/2012 04:57 PM, Cousson, Benoit :
>> On 2/23/2012 4:51 PM, Nicolas Ferre wrote:
>>> On 02/23/2012 11:03 AM, Cousson, Benoit :
>>>> Salut Nico,
>>> Coucou Benoit ;-)
>>>> On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
>>>>> On 01/27/2012 06:29 PM, Cousson, Benoit :
>>>>>> Add some basic helpers to retrieve a DMA controller device_node
>>>>>> and the DMA request line number.
>>>>>> For legacy reason another API will export the DMA request number
>>>>>> into a Linux resource of type IORESOURCE_DMA.
>>>>>> This API is usable only on system with an unique DMA controller.
>>>>> Hi,
>>>>> I followed that discussion and I like very much the biding that Benoit
>>>>> is proposing. It will help me a lot with my current work on Atmel DMA
>>>>> controller.
>>>>> If I understand correctly, some rework is needed before it can be
>>>>> integrated in a stable git tree (I mean before we can base our work on
>>>>> top of it). So, in the meantime, what should I do to help and make
>>>>> things go forward? to be quite frank, I would be interested to have a
>>>>> working DMA enabled device soon ;-)
>>>> Me too, but unfortunately, I was busy trying to add irq_domain and
>>>> fixing issues with SPARSE_IRQ on OMAP :-(
>>> Been there, loved that ;-)
>>>>> Do you think that 3.4 is out of reach?
>>>> Maybe not, from the comments, it looks like we should add a .xlate
>>>> callback to allow any custom parsing of the DMA nodes attributes.
>>>> I'll be more than happy, if you can finalize that patch :-)
>>> I will try to figure out what I can understand from the irq mechanism of
>>> .xlate and try to see if I can implement it on top of your patch.
>> In fact that dma code is a big copy/paste of the of/gpio one and gpio
>> was already managing .xlate function.
>> I removed it because I thought it was useless for the DMA :-)
>> You might just have to copy the original code...
> The thing is that with gpio, we can rely on the gpio_chip structure for
> having a common storage location of such .xlate callbacks.
> In our DMA case, I guess that we should not cling to dmaengine
> infrastructure because not all of us are using it right now.

Yep, that's the main issue compared to GPIO or IRQ.

> So, maybe we should provide some simple "xlate" helpers like the
> irqdomain ones. But I fear that a "callback" directly called from the
> of_get_dma_request() function is not possible (the gpio code model).

I think a well that we cannot much but a simple very abstract callback 
since we do not have any formal DMA representation?

I'm not sure to understand you concern?

> On the other hand, the "cookie" based infrastructure seems a little
> overkill to me. It seems that, in this case, we must establish a
> relation between the DMA controller code and the device tree DMA
> helpers. Please correct me if I am wrong.

Yes, and in our case the DMA controller cannot be specified with 
anything else than a Linux device for the moment.


More information about the linux-arm-kernel mailing list