How to handle named resources with DT?

[b-cousson@ti.com (Cousson, Benoit)]

On 8/9/2011 11:16 PM, Grant Likely wrote:
> 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.

The devil is in the details, but the way the DMA lines are connected in 
OMAP is similar to IRQ lines, and maybe a little bit simpler.

So starting with a copy/paste of the of_irq file should be a good start.
And then the issues will start:-)

Benoit


>
> g.
>