On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote: > On 8/9/2011 10:55 PM, Grant Likely wrote: > >On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote: > >>On 8/9/2011 7:23 PM, Grant Likely wrote: > >>>On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoit<b-cousson@xxxxxx> wrote: > >>>>Hi Manju, > >>>> > >>>>On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: > >>>>> > >>>>>Hi Benoit, > >>>>> > >>>>>On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: > >>>>>> > >>>>>>Hi Grant, > >>>>>> > >>>>>>Trying to bind hwmod informations with DT, I'm facing a little > >>>>>>limitation. > >>>>>>A bunch of drivers are using the platform_get_resource_byname, so > >>>>>>the name for the resource is needed. > >>>>>> > >>>>>>The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and > >>>>>>IORESOURCE_DMA types of resources. > >>>>> > >>>>>IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and > >>>>>it will be part of pdev. > >>>> > >>>>Yes, but without the proper name in the resource structure. It will be then > >>>>impossible to use the platform_get_resource_byname function that is > >>>>currently used by a bunch of drivers. > >>> > >>>There is no analogous mechanism for _byname in the device tree. The > >>>DT binding for a device must explicitly state what order the register > >>>ranges are in. The driver will need to be adapted. > >> > >>That seems to be a small regression for my point of view. Relying on > >>the order is not super safe. This is not very readable either. > >>That's for that exact reason that we changed our drivers to use > >>platform_get_resource_byname. That's probably the reason why that > >>API is there as well. > >>For the same IP, the number of entries can vary depending of the SoC > >>revision. > >>By using the _byname, we can check if the resource is there or not > >>without having to care about the position. > > > >We've done it that way for a very long time with the device tree. If > >you want to do something by name, then propose a binding that will > >make it work alongside the existing scheme. > > > >> > >>>>>For IORESOURCE_DMA, you can have property > >>>>>"dma-channel" in dtsi file and fetch dma-channel in driver probe > >>>>>through "of_property_read_u32()" api. > >>>> > >>>>That will not be enough to get the name. So maybe something like: > >>>> dmas =<12>, "rx_req",<13>, "tx_req"; > >>>>will be doable. > >>>>The issue is that the name is optional so managing the multiple entries > >>>>might be tricky. > >>> > >>>DMA channels will never show up in the resource structure anyway. > >> > >>Can you elaborate on that point? AFAIK, IORESOURCE_DMA is already > >>used today. > > > >IORESOURCE_DMA is a Linux construct, as is IORESOURCE_IRQ and > >IORESOURCE_MEM. However, IRQ and MEM can be directly mapped from the > >common 'reg' and 'interrupts' bindings used by pretty much all device > >tree nodes. Therefore common code can be written to translate MEM and > >IRQ that will always work. There is no such common binding in place > >for DMA regions, so common setup code cannot do it transparently for > >the device driver. > > OK, sure, I get your point now. I was thinking about a "potential" > dma support from the core DT, since this is very similar to IRQ. > > Otherwise, we can do it OMAP specific if nobody else care about > that. But I still think it should be useful for other platforms. I think people care, and it will be a net win, but it does mean you need do the work of crafting a binding that will work for a large proportion of SoCs. g. -- 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
