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

On 02/27/2012 03:22 PM, Cousson, Benoit :

On 2/27/2012 2:09 PM, Nicolas Ferre wrote:

quoted

On 02/23/2012 04:57 PM, Cousson, Benoit :

quoted

On 2/23/2012 4:51 PM, Nicolas Ferre wrote:

quoted

On 02/23/2012 11:03 AM, Cousson, Benoit :

quoted

Salut Nico,

Coucou Benoit ;-)

quoted

On 2/22/2012 11:59 AM, Nicolas Ferre wrote:

quoted

On 01/27/2012 06:29 PM, Cousson, Benoit :

quoted

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 ;-)

quoted

quoted

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.

quoted

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?

Well, in fact I cannot find a place where to store a "xlate" callback:
- it have to be provided by the DMA controller (the one pointed out by
the phandle) and not the caller of the of_get_dma_request() funtion
- it has to be generic enough to match the dmaengine/non-dmaengine cases
(so it cannot be stored in the dmaengine "struct dma_device").

So I guess that the very basic idea of returning the full DMA specifier
(struct of_phandle_args) is the best... My only concern is that the
"helper" becomes very short and empty in this case...

Bye,
-- 
Nicolas Ferre