On 2/2/2012 9:45 AM, Russell King - ARM Linux wrote: > On Wed, Feb 01, 2012 at 11:50:30AM +0100, Cousson, Benoit wrote: >> Hi Russell, >> >> On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: >>> On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: >>>> This makes the assumption that dma specifiers will only ever be 1 >>>> cell. I think to be generally useful, the full dma specifier needs to >>>> be either handed to the dma controller to get a cookie or passed back >>>> to the caller in its entirety. >>> >>> More to the point, who says that the DMA specifier is even an integer? >>> When people are using DMA engines, it (probably) isn't an integer at >>> all. Several platforms I know of use strings for this. >>> >>> Some platforms can even select between two or more DMA engines for >>> handling the same peripheral - I believe Samsung do this depending >>> on their individual workloads. >>> >>> However, the opaque DMA engine API for requesting a channel doesn't >>> lend itself well to DT, as the match data and match function are >>> entirely left to the individual DMA engine driver and/or platform >>> itself. >>> >>> As far as creating another linear number space for DMA stuff, I'd >>> really suggest against that - you're going to need some additional >>> code in place to manage that numberspace. If you at least use a two- >>> paid cookie, eg 'dma controller phandle + request signal' then that >>> makes all the stuff we're starting to see with the IRQ subsystem, >>> IRQ domains etc become completely unnecessary. >>> >>> I guess what I'm saying is ignore the flat number space, and go >>> straight to some kind of 'dma domains' solution from the start. >> >> Fully agree, and this is exactly the idea of this DMA binding: First >> argument is always a DMA controller phandle and then you can add 0, 1 or >> more cells to define extra specifiers dependent of the DMA controller >> driver expectation. The one cell Grant was referring was just the extra >> specifier that is needed for a simple DMA engine like the SDMA we have >> inside OMAP. But the whole idea is to have a flexible enough mechanism >> to allow any kind of specifier. >> >> No more global linear number space like for IRQ! > > How does this work when you're stuffing a number into a struct resource > as a plain DMA number? That looks very much like a linear number space, > as you don't have a way to associate that number with anything else. As explained in the kernel doc header and in the changelog, that one is for legacy purpose only. +/** + * of_dma_to_resource - Decode a node's DMA and return it as a resource + * @dev: pointer to device tree node + * @index: zero-based index of the DMA request + * @r: pointer to resource structure to return result into. + * + * Using a resource to export a DMA request number to a driver should + * be used only for legacy purpose and on system when only one DMA controller + * is present. + * The proper and only scalable way is to use the native of_get_dma_request API + * in order retrieve both the DMA controller device node and the DMA request + * line for that controller. + */ There is indeed no way to put information about DMA controller and DMA line in the resource structure except if we start hacking the start and end attributes. But I'm not sure anyone will want to do that. The only way to take benefit of the extra information DT can provide is to use the of_get_dma_request API. 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
