How to handle named resources with DT?

[grant.likely@secretlab.ca (Grant Likely)]

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@ti.com>   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.