On 02/27/2012 03:22 PM, Cousson, Benoit : > 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? 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 -- 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
