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.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
