How to handle named resources with DT?

How to handle named resources with DT?

[Cousson, Benoit]

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.

Do you have any plan to add that, or do you have any clean way to avoid 
that without having to use the resource index?

Thanks,
Benoit

How to handle named resources with DT?

[G, Manjunath Kondaiah]

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. 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.

BTW, this is not required for omap since dt-hwmod binding will fetch
pdev pointer from hwmod database and it will be used "as is" without 
any modification which inturn does not break any existing pm 
functionality.

-M

> 
> Do you have any plan to add that, or do you have any clean way to
> avoid that without having to use the resource index?
> 
> Thanks,
> Benoit

How to handle named resources with DT?

[Cousson, Benoit]

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.

> 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.

BTW, it's strange that a default support does not exist for dma request 
(and not channel).
The mechanism is similar to irq line, and quite standard to many SoC 
AFAIK. Or maybe I missed it.

> BTW, this is not required for omap since dt-hwmod binding will fetch
> pdev pointer from hwmod database and it will be used "as is" without
> any modification which inturn does not break any existing pm
> functionality.

Well for the moment... but I have some long term plan as well:-)

Thanks,
Benoit

How to handle named resources with DT?

[Grant Likely]

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.

>
>> 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.  The
common code only takes care of translating IRQ and register ranges.
For DMA you'll need a binding for the dma channels.  You can either
make them explicitly ordered, or use different property names for each
of the dma channels.

>
> BTW, it's strange that a default support does not exist for dma request (and
> not channel).
> The mechanism is similar to irq line, and quite standard to many SoC AFAIK.
> Or maybe I missed it.

DMA channels haven't historically had the same global scope that irq
numbers have.  There hasn't been a pressing need up to now to have
common infrastructure, though it is probably a good idea to define a
common binding.

>> BTW, this is not required for omap since dt-hwmod binding will fetch
>> pdev pointer from hwmod database and it will be used "as is" without
>> any modification which inturn does not break any existing pm
>> functionality.
>
> Well for the moment... but I have some long term plan as well:-)
>
> Thanks,
> Benoit
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

How to handle named resources with DT?

[Cousson, Benoit]

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.

>>> 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.

> The
> common code only takes care of translating IRQ and register ranges.
> For DMA you'll need a binding for the dma channels.  You can either
> make them explicitly ordered, or use different property names for each
> of the dma channels.

FWIW, DMA channel != DMA request. The DMA request is a physical line 
that is connected to a DMA controller. It is similar to an IRQ connected 
to an interrupt controller. It is a HW resource like an IRQ.
The DMA channel is a logical entry in the DMA controller that will be 
used by the driver.

>> BTW, it's strange that a default support does not exist for dma request (and
>> not channel).
>> The mechanism is similar to irq line, and quite standard to many SoC AFAIK.
>> Or maybe I missed it.
>
> DMA channels haven't historically had the same global scope that irq
> numbers have.  There hasn't been a pressing need up to now to have
> common infrastructure, though it is probably a good idea to define a
> common binding.

Cool, I think so as well.

Regards,
Benoit

How to handle named resources with DT?

[Matt Porter]

On Aug 9, 2011, at 1:47 PM, 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.

That's exactly what the reasoning was for adding it.

http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-12/1944.html

-Matt

How to handle named resources with DT?

[Scott Wood]

On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
> On 8/9/2011 7:23 PM, Grant Likely wrote:
>> 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.

You could have a named u32 property that contains the reg index, e.g.:

dev {
	reg = <0x20000 0x200 0x24000 0x200>;
	foo-reg = <0>;
	bar-reg = <1>;
};

-Scott

How to handle named resources with DT?

[Grant Likely]

On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
> On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
> > On 8/9/2011 7:23 PM, Grant Likely wrote:
> >> 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.
> 
> You could have a named u32 property that contains the reg index, e.g.:
> 
> dev {
> 	reg = <0x20000 0x200 0x24000 0x200>;
> 	foo-reg = <0>;
> 	bar-reg = <1>;
> };

That's a little nasty.  A reg-names = "foo", "bar"; would probably be
better.

g.

How to handle named resources with DT?

[Cousson, Benoit]

On 8/9/2011 10:57 PM, Grant Likely wrote:
> On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
>> On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
>>> On 8/9/2011 7:23 PM, Grant Likely wrote:
>>>> 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.
>>
>> You could have a named u32 property that contains the reg index, e.g.:
>>
>> dev {
>> 	reg =<0x20000 0x200 0x24000 0x200>;
>> 	foo-reg =<0>;
>> 	bar-reg =<1>;
>> };
>
> That's a little nasty.  A reg-names = "foo", "bar"; would probably be
> better.

Yep, I agree.

And what about something like that?
   reg = <0x20000 0x200>, "foo",
	<0x20000 0x200>, "bar" ;

It is doable?

Regards,
Benoit

How to handle named resources with DT?

[Grant Likely]

On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 10:57 PM, Grant Likely wrote:
> >On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
> >>On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
> >>>On 8/9/2011 7:23 PM, Grant Likely wrote:
> >>>>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.
> >>
> >>You could have a named u32 property that contains the reg index, e.g.:
> >>
> >>dev {
> >>	reg =<0x20000 0x200 0x24000 0x200>;
> >>	foo-reg =<0>;
> >>	bar-reg =<1>;
> >>};
> >
> >That's a little nasty.  A reg-names = "foo", "bar"; would probably be
> >better.
> 
> Yep, I agree.
> 
> And what about something like that?
>   reg = <0x20000 0x200>, "foo",
> 	<0x20000 0x200>, "bar" ;
> 
> It is doable?

Definitely not.  It would break all existing 'reg' parsing
implementations quite badly.

g.

How to handle named resources with DT?

[Cousson, Benoit]

On 8/9/2011 11:17 PM, Grant Likely wrote:
> On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 10:57 PM, Grant Likely wrote:
>>> On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
>>>> On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
>>>>> On 8/9/2011 7:23 PM, Grant Likely wrote:
>>>>>> 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.
>>>>
>>>> You could have a named u32 property that contains the reg index, e.g.:
>>>>
>>>> dev {
>>>> 	reg =<0x20000 0x200 0x24000 0x200>;
>>>> 	foo-reg =<0>;
>>>> 	bar-reg =<1>;
>>>> };
>>>
>>> That's a little nasty.  A reg-names = "foo", "bar"; would probably be
>>> better.
>>
>> Yep, I agree.
>>
>> And what about something like that?
>>    reg =<0x20000 0x200>, "foo",
>> 	<0x20000 0x200>, "bar" ;
>>
>> It is doable?
>
> Definitely not.  It would break all existing 'reg' parsing
> implementations quite badly.

OK, so what about extending the reg attribute to be a reg node?

dev {
	reg {
		name = "foo_wrapper";
		start = <0x10000>;
		end = <0x200>;
	}
	reg {
		name = "foo";
		start = <0x20000>;
		end = <0x200>;
	}
}

A little bit more verbose, but at least we can add any attribute we want.

Regards,
Benoit

How to handle named resources with DT?

[Grant Likely]

On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 11:17 PM, Grant Likely wrote:
> >On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
> >>On 8/9/2011 10:57 PM, Grant Likely wrote:
> >>>On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
> >>>>On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
> >>>>>On 8/9/2011 7:23 PM, Grant Likely wrote:
> >>>>>>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.
> >>>>
> >>>>You could have a named u32 property that contains the reg index, e.g.:
> >>>>
> >>>>dev {
> >>>>	reg =<0x20000 0x200 0x24000 0x200>;
> >>>>	foo-reg =<0>;
> >>>>	bar-reg =<1>;
> >>>>};
> >>>
> >>>That's a little nasty.  A reg-names = "foo", "bar"; would probably be
> >>>better.
> >>
> >>Yep, I agree.
> >>
> >>And what about something like that?
> >>   reg =<0x20000 0x200>, "foo",
> >>	<0x20000 0x200>, "bar" ;
> >>
> >>It is doable?
> >
> >Definitely not.  It would break all existing 'reg' parsing
> >implementations quite badly.
> 
> OK, so what about extending the reg attribute to be a reg node?
> 
> dev {
> 	reg {
> 		name = "foo_wrapper";
> 		start = <0x10000>;
> 		end = <0x200>;
> 	}
> 	reg {
> 		name = "foo";
> 		start = <0x20000>;
> 		end = <0x200>;
> 	}
> }
> 
> A little bit more verbose, but at least we can add any attribute we want.

That won't work either because that also breaks the existing 'reg'
binding.  Anything you do will need to supplement the existing
binding without changing it in an incompatible way.

g.

How to handle named resources with DT?

[Cousson, Benoit]

On 8/9/2011 11:49 PM, Grant Likely wrote:
> On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 11:17 PM, Grant Likely wrote:
>>> On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
>>>> On 8/9/2011 10:57 PM, Grant Likely wrote:
>>>>> On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
>>>>>> On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
>>>>>>> On 8/9/2011 7:23 PM, Grant Likely wrote:
>>>>>>>> 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.
>>>>>>
>>>>>> You could have a named u32 property that contains the reg index, e.g.:
>>>>>>
>>>>>> dev {
>>>>>> 	reg =<0x20000 0x200 0x24000 0x200>;
>>>>>> 	foo-reg =<0>;
>>>>>> 	bar-reg =<1>;
>>>>>> };
>>>>>
>>>>> That's a little nasty.  A reg-names = "foo", "bar"; would probably be
>>>>> better.
>>>>
>>>> Yep, I agree.
>>>>
>>>> And what about something like that?
>>>>    reg =<0x20000 0x200>, "foo",
>>>> 	<0x20000 0x200>, "bar" ;
>>>>
>>>> It is doable?
>>>
>>> Definitely not.  It would break all existing 'reg' parsing
>>> implementations quite badly.
>>
>> OK, so what about extending the reg attribute to be a reg node?
>>
>> dev {
>> 	reg {
>> 		name = "foo_wrapper";
>> 		start =<0x10000>;
>> 		end =<0x200>;
>> 	}
>> 	reg {
>> 		name = "foo";
>> 		start =<0x20000>;
>> 		end =<0x200>;
>> 	}
>> }
>>
>> A little bit more verbose, but at least we can add any attribute we want.
>
> That won't work either because that also breaks the existing 'reg'
> binding.  Anything you do will need to supplement the existing
> binding without changing it in an incompatible way.

OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus, 
reg_named...?

Benoit

How to handle named resources with DT?

[David Gibson]

On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 11:49 PM, Grant Likely wrote:
> >On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
> >>On 8/9/2011 11:17 PM, Grant Likely wrote:
> >>>On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
> >>>>On 8/9/2011 10:57 PM, Grant Likely wrote:
> >>>>>On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
> >>>>>>On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
> >>>>>>>On 8/9/2011 7:23 PM, Grant Likely wrote:
> >>>>>>>>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.
> >>>>>>
> >>>>>>You could have a named u32 property that contains the reg index, e.g.:
> >>>>>>
> >>>>>>dev {
> >>>>>>	reg =<0x20000 0x200 0x24000 0x200>;
> >>>>>>	foo-reg =<0>;
> >>>>>>	bar-reg =<1>;
> >>>>>>};
> >>>>>
> >>>>>That's a little nasty.  A reg-names = "foo", "bar"; would probably be
> >>>>>better.
> >>>>
> >>>>Yep, I agree.
> >>>>
> >>>>And what about something like that?
> >>>>   reg =<0x20000 0x200>, "foo",
> >>>>	<0x20000 0x200>, "bar" ;
> >>>>
> >>>>It is doable?
> >>>
> >>>Definitely not.  It would break all existing 'reg' parsing
> >>>implementations quite badly.
> >>
> >>OK, so what about extending the reg attribute to be a reg node?
> >>
> >>dev {
> >>	reg {
> >>		name = "foo_wrapper";
> >>		start =<0x10000>;
> >>		end =<0x200>;
> >>	}
> >>	reg {
> >>		name = "foo";
> >>		start =<0x20000>;
> >>		end =<0x200>;
> >>	}
> >>}
> >>
> >>A little bit more verbose, but at least we can add any attribute we want.
> >
> >That won't work either because that also breaks the existing 'reg'
> >binding.  Anything you do will need to supplement the existing
> >binding without changing it in an incompatible way.
> 
> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
> reg_named...?

He already suggested reg-names to be interpreted in parallel with the
existing reg property.  The (serious) problem with replacing the reg
property is that it will break all existing OSes (including old Linux
versions) that don't understand the new property.

Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order.  In which
case you could argue it's more sensible to just have a static place to
name mapping in the Linux driver.

In short, yes, named reg elements in the DT would be nice in theory,
but I'm not convinced it's worth a DT flag day to accomplish it.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Paul Walmsley]

On Wed, 10 Aug 2011, David Gibson wrote:

> Of course, the problem with reg-names is that it will be ignored by
> older OSes, and so 'reg' must still be in the correct order.

Most ARM SoC Linux ports aren't using DT now, so there isn't really an 
older OS case here.  Might as well try to get something implemented in a 
clean way while there's still some chance for it.

A more persuasive case could probably be made about DT bootloader-related 
issues.  Those would have to be converted to use reg-names, also.


- Paul

How to handle named resources with DT?

[Cousson, Benoit]

On 8/10/2011 3:52 AM, David Gibson wrote:
> On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 11:49 PM, Grant Likely wrote:
>>> On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
>>>> On 8/9/2011 11:17 PM, Grant Likely wrote:
>>>>> On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
>>>>>> On 8/9/2011 10:57 PM, Grant Likely wrote:
>>>>>>> On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
>>>>>>>> On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
>>>>>>>>> On 8/9/2011 7:23 PM, Grant Likely wrote:
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> You could have a named u32 property that contains the reg index, e.g.:
>>>>>>>>
>>>>>>>> dev {
>>>>>>>> 	reg =<0x20000 0x200 0x24000 0x200>;
>>>>>>>> 	foo-reg =<0>;
>>>>>>>> 	bar-reg =<1>;
>>>>>>>> };
>>>>>>>
>>>>>>> That's a little nasty.  A reg-names = "foo", "bar"; would probably be
>>>>>>> better.
>>>>>>
>>>>>> Yep, I agree.
>>>>>>
>>>>>> And what about something like that?
>>>>>>    reg =<0x20000 0x200>, "foo",
>>>>>> 	<0x20000 0x200>, "bar" ;
>>>>>>
>>>>>> It is doable?
>>>>>
>>>>> Definitely not.  It would break all existing 'reg' parsing
>>>>> implementations quite badly.
>>>>
>>>> OK, so what about extending the reg attribute to be a reg node?
>>>>
>>>> dev {
>>>> 	reg {
>>>> 		name = "foo_wrapper";
>>>> 		start =<0x10000>;
>>>> 		end =<0x200>;
>>>> 	}
>>>> 	reg {
>>>> 		name = "foo";
>>>> 		start =<0x20000>;
>>>> 		end =<0x200>;
>>>> 	}
>>>> }
>>>>
>>>> A little bit more verbose, but at least we can add any attribute we want.
>>>
>>> That won't work either because that also breaks the existing 'reg'
>>> binding.  Anything you do will need to supplement the existing
>>> binding without changing it in an incompatible way.
>>
>> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
>> reg_named...?
>
> He already suggested reg-names to be interpreted in parallel with the
> existing reg property.  The (serious) problem with replacing the reg
> property is that it will break all existing OSes (including old Linux
> versions) that don't understand the new property.

That's why I was proposing a new extended node for that. Legacy tag will 
still be there for legacy HW.

Adding reg-names is doable easily, but not super nice. And the same 
trick will be needed for IRQs and then DMAs (not yet in core DT anyway).
Having a more scalable mechanism to allow further improvement will be good.

> Of course, the problem with reg-names is that it will be ignored by
> older OSes, and so 'reg' must still be in the correct order.  In which
> case you could argue it's more sensible to just have a static place to
> name mapping in the Linux driver.
>
> In short, yes, named reg elements in the DT would be nice in theory,
> but I'm not convinced it's worth a DT flag day to accomplish it.

Sorry, but I'm not sure to understand the meaning of that last sentence.

Benoit

How to handle named resources with DT?

[Scott Wood]

On 08/09/2011 08:52 PM, David Gibson wrote:
> Of course, the problem with reg-names is that it will be ignored by
> older OSes, and so 'reg' must still be in the correct order.  In which
> case you could argue it's more sensible to just have a static place to
> name mapping in the Linux driver.

I think the intent was just to use this for some new bindings -- not to
change existing ones.

-Scott

How to handle named resources with DT?

[Cousson, Benoit]

On 8/10/2011 5:18 PM, Scott Wood wrote:
> On 08/09/2011 08:52 PM, David Gibson wrote:
>> Of course, the problem with reg-names is that it will be ignored by
>> older OSes, and so 'reg' must still be in the correct order.  In which
>> case you could argue it's more sensible to just have a static place to
>> name mapping in the Linux driver.
>
> I think the intent was just to use this for some new bindings -- not to
> change existing ones.

Yes, indeed. I've just realized it was maybe not clear in my email.

Thanks,
Benoit

How to handle named resources with DT?

[Grant Likely]

On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 11:49 PM, Grant Likely wrote:
>> >That won't work either because that also breaks the existing 'reg'
>> >binding. ?Anything you do will need to supplement the existing
>> >binding without changing it in an incompatible way.
>>
>> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
>> reg_named...?
>
> He already suggested reg-names to be interpreted in parallel with the
> existing reg property. ?The (serious) problem with replacing the reg
> property is that it will break all existing OSes (including old Linux
> versions) that don't understand the new property.
>
> Of course, the problem with reg-names is that it will be ignored by
> older OSes, and so 'reg' must still be in the correct order. ?In which
> case you could argue it's more sensible to just have a static place to
> name mapping in the Linux driver.
>
> In short, yes, named reg elements in the DT would be nice in theory,
> but I'm not convinced it's worth a DT flag day to accomplish it.

I'm inclined the same way, though I agree with the replies that point
out it wouldn't result in a 'flag day' because existing bindings
cannot become incompatible.  The problem I have is that adding
reg-names or similar implies that ordering of the reg property is no
longer defined which I absolutely do not think is a good idea.

Please, stick with the established convention and explicitly order
'reg' and 'interrupts' properties.  If there is a specific use case
where this doesn't work, then bring it up, but I haven't seen any yet.
 The current users of _byname that I've looked seem to only use it for
convenience, not because a register range may be optional.  ie. they
all fail out if a reg resource isn't present.

So, the original answer stands, don't use _byname for DT bindings.

g.

How to handle named resources with DT?

[David Brown]

On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:

> Please, stick with the established convention and explicitly order
> 'reg' and 'interrupts' properties.  If there is a specific use case
> where this doesn't work, then bring it up, but I haven't seen any yet.
>  The current users of _byname that I've looked seem to only use it for
> convenience, not because a register range may be optional.  ie. they
> all fail out if a reg resource isn't present.

The msm_serial driver uses the presence of one of it's _byname reg
regions to distinguish between two different types of the controller.
Fortunately, it is the last register range that has this.

It's probably best to make the DT code depend on compatible (or some
attribute) to determine if this functionality is available, or in this
case, even make it a separate memory region.  I'm not sure what the
cleanest way is to implement this, and still have the driver work with
non-DT systems.

Patches coming soon...

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

How to handle named resources with DT?

[Grant Likely]

On Wed, Aug 10, 2011 at 1:57 PM, David Brown <davidb@codeaurora.org> wrote:
> On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote:
>
>> Please, stick with the established convention and explicitly order
>> 'reg' and 'interrupts' properties. ?If there is a specific use case
>> where this doesn't work, then bring it up, but I haven't seen any yet.
>> ?The current users of _byname that I've looked seem to only use it for
>> convenience, not because a register range may be optional. ?ie. they
>> all fail out if a reg resource isn't present.
>
> The msm_serial driver uses the presence of one of it's _byname reg
> regions to distinguish between two different types of the controller.
> Fortunately, it is the last register range that has this.
>
> It's probably best to make the DT code depend on compatible (or some
> attribute) to determine if this functionality is available, or in this
> case, even make it a separate memory region. ?I'm not sure what the
> cleanest way is to implement this, and still have the driver work with
> non-DT systems.

You can use the .data field in the match table to add in
compatible-specific configuration data.

g.

How to handle named resources with DT?

[Cousson, Benoit]

On 8/10/2011 9:22 PM, Grant Likely wrote:
> On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
> <david@gibson.dropbear.id.au>  wrote:
>> On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
>>> On 8/9/2011 11:49 PM, Grant Likely wrote:
>>>> That won't work either because that also breaks the existing 'reg'
>>>> binding.  Anything you do will need to supplement the existing
>>>> binding without changing it in an incompatible way.
>>>
>>> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
>>> reg_named...?
>>
>> He already suggested reg-names to be interpreted in parallel with the
>> existing reg property.  The (serious) problem with replacing the reg
>> property is that it will break all existing OSes (including old Linux
>> versions) that don't understand the new property.
>>
>> Of course, the problem with reg-names is that it will be ignored by
>> older OSes, and so 'reg' must still be in the correct order.  In which
>> case you could argue it's more sensible to just have a static place to
>> name mapping in the Linux driver.
>>
>> In short, yes, named reg elements in the DT would be nice in theory,
>> but I'm not convinced it's worth a DT flag day to accomplish it.
>
> I'm inclined the same way, though I agree with the replies that point
> out it wouldn't result in a 'flag day' because existing bindings
> cannot become incompatible.  The problem I have is that adding
> reg-names or similar implies that ordering of the reg property is no
> longer defined which I absolutely do not think is a good idea.

That will not be an issue if "reg-named" is a completely new node. It 
will replace the "reg" node only when a named entry is needed.
Most devices will use the regular "reg" entry, and only the one that 
need extra information will use the reg-named.

That seems to be pretty straightforward to implement, and as soon as it 
is useful even for a couple of drivers, it worth adding it.

It is anyway better than having to add a custom property to get the 
information we will miss otherwise.

Moreover, since some drivers are relying on that call, it will avoid 
having to add extra code for nothing if CONFIG_OF is set.

It will allow the driver to use a pretty standard API in anycase vs 
using platform_get_resource + some extra optional calls to of_ functions 
+ some code to get the information for non-DT build.

> Please, stick with the established convention and explicitly order
> 'reg' and 'interrupts' properties.  If there is a specific use case
> where this doesn't work, then bring it up, but I haven't seen any yet.

There will always be some alternatives, but they will be uglier, and the 
effort to add some extra node to DT is so small, that it is better to do 
that instead of adding some useless extra code in the driver.

>   The current users of _byname that I've looked seem to only use it for
> convenience, not because a register range may be optional.  ie. they
> all fail out if a reg resource isn't present.

If that API can help the driver writer and can avoid adding 10 lines of 
code, it is still useful to use it.

To be honest, I still do not understand why you are so reluctant to add 
that small feature.

That will not break compatibility and it will make our life easier.
Don't you want to make our life easier? :-)

Benoit

How to handle named resources with DT?

[David Gibson]

On Thu, Aug 11, 2011 at 02:28:55PM +0200, Cousson, Benoit wrote:
> On 8/10/2011 9:22 PM, Grant Likely wrote:
> >On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
> ><david@gibson.dropbear.id.au>  wrote:
> >>On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
> >>>On 8/9/2011 11:49 PM, Grant Likely wrote:
> >>>>That won't work either because that also breaks the existing 'reg'
> >>>>binding.  Anything you do will need to supplement the existing
> >>>>binding without changing it in an incompatible way.
> >>>
> >>>OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
> >>>reg_named...?
> >>
> >>He already suggested reg-names to be interpreted in parallel with the
> >>existing reg property.  The (serious) problem with replacing the reg
> >>property is that it will break all existing OSes (including old Linux
> >>versions) that don't understand the new property.
> >>
> >>Of course, the problem with reg-names is that it will be ignored by
> >>older OSes, and so 'reg' must still be in the correct order.  In which
> >>case you could argue it's more sensible to just have a static place to
> >>name mapping in the Linux driver.
> >>
> >>In short, yes, named reg elements in the DT would be nice in theory,
> >>but I'm not convinced it's worth a DT flag day to accomplish it.
> >
> >I'm inclined the same way, though I agree with the replies that point
> >out it wouldn't result in a 'flag day' because existing bindings
> >cannot become incompatible.  The problem I have is that adding
> >reg-names or similar implies that ordering of the reg property is no
> >longer defined which I absolutely do not think is a good idea.
> 
> That will not be an issue if "reg-named" is a completely new node.
> It will replace the "reg" node only when a named entry is needed.
> Most devices will use the regular "reg" entry, and only the one that
> need extra information will use the reg-named.

Um, you seem to be confusing nodes and properties here.

> That seems to be pretty straightforward to implement, and as soon as
> it is useful even for a couple of drivers, it worth adding it.
> 
> It is anyway better than having to add a custom property to get the
> information we will miss otherwise.
> 
> Moreover, since some drivers are relying on that call, it will avoid
> having to add extra code for nothing if CONFIG_OF is set.
> 
> It will allow the driver to use a pretty standard API in anycase vs
> using platform_get_resource + some extra optional calls to of_
> functions + some code to get the information for non-DT build.

You don't need to add stuff to the DT to use the byname interface.
Really.  All you need is a way for the driver (well match table entry,
really) to provide a list of names to attach to the reg entries in
order.

> >Please, stick with the established convention and explicitly order
> >'reg' and 'interrupts' properties.  If there is a specific use case
> >where this doesn't work, then bring it up, but I haven't seen any yet.
> 
> There will always be some alternatives, but they will be uglier, and
> the effort to add some extra node to DT is so small, that it is
> better to do that instead of adding some useless extra code in the
> driver.
> 
> >  The current users of _byname that I've looked seem to only use it for
> >convenience, not because a register range may be optional.  ie. they
> >all fail out if a reg resource isn't present.
> 
> If that API can help the driver writer and can avoid adding 10 lines
> of code, it is still useful to use it.
> 
> To be honest, I still do not understand why you are so reluctant to
> add that small feature.

Because this is a totally new basic feature to add to the DT
bindings.  Once in there, we're stuck with it indefinitely, which
means it warrants considerably more conservatism than mere internal
code changes which can be easily updated or reverted.

> That will not break compatibility and it will make our life easier.
> Don't you want to make our life easier? :-)
> 
> Benoit
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Cousson, Benoit]

On 8/12/2011 5:02 AM, David Gibson wrote:
> On Thu, Aug 11, 2011 at 02:28:55PM +0200, Cousson, Benoit wrote:
>> On 8/10/2011 9:22 PM, Grant Likely wrote:
>>> On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
>>> <david@gibson.dropbear.id.au>   wrote:
>>>> On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
>>>>> On 8/9/2011 11:49 PM, Grant Likely wrote:
>>>>>> That won't work either because that also breaks the existing 'reg'
>>>>>> binding.  Anything you do will need to supplement the existing
>>>>>> binding without changing it in an incompatible way.
>>>>>
>>>>> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
>>>>> reg_named...?
>>>>
>>>> He already suggested reg-names to be interpreted in parallel with the
>>>> existing reg property.  The (serious) problem with replacing the reg
>>>> property is that it will break all existing OSes (including old Linux
>>>> versions) that don't understand the new property.
>>>>
>>>> Of course, the problem with reg-names is that it will be ignored by
>>>> older OSes, and so 'reg' must still be in the correct order.  In which
>>>> case you could argue it's more sensible to just have a static place to
>>>> name mapping in the Linux driver.
>>>>
>>>> In short, yes, named reg elements in the DT would be nice in theory,
>>>> but I'm not convinced it's worth a DT flag day to accomplish it.
>>>
>>> I'm inclined the same way, though I agree with the replies that point
>>> out it wouldn't result in a 'flag day' because existing bindings
>>> cannot become incompatible.  The problem I have is that adding
>>> reg-names or similar implies that ordering of the reg property is no
>>> longer defined which I absolutely do not think is a good idea.
>>
>> That will not be an issue if "reg-named" is a completely new node.
>> It will replace the "reg" node only when a named entry is needed.
>> Most devices will use the regular "reg" entry, and only the one that
>> need extra information will use the reg-named.
>
> Um, you seem to be confusing nodes and properties here.

I don't think so. What I was proposing before was something like that:

dev {
	reg_named {
		name = "foo_wrapper";
		start =<0x10000>;
		end =<0x200>;
	}
	reg_named {
		name = "foo";
		start =<0x20000>;
		end =<0x200>;
	}
}

So, AFAIK, this is a node and not a property, isn't it?

OK, I was proposing as well something at attribute level:
reg_named = <0x10000 0x200>, "foo_wrapper", <0x20000 0x200>, "foo";

But I'm not sure it is easy to parse. Moreover, I cannot find a way to 
differentiate a string from a cell in the property, so maybe I'm missing 
something.

>> That seems to be pretty straightforward to implement, and as soon as
>> it is useful even for a couple of drivers, it worth adding it.
>>
>> It is anyway better than having to add a custom property to get the
>> information we will miss otherwise.
>>
>> Moreover, since some drivers are relying on that call, it will avoid
>> having to add extra code for nothing if CONFIG_OF is set.
>>
>> It will allow the driver to use a pretty standard API in anycase vs
>> using platform_get_resource + some extra optional calls to of_
>> functions + some code to get the information for non-DT build.
>
> You don't need to add stuff to the DT to use the byname interface.
> Really.  All you need is a way for the driver (well match table entry,
> really) to provide a list of names to attach to the reg entries in
> order.

That looks interesting, but I'm not sure to understand how it works.
Do you have an example?
It still looks like I will have to add some extra stuff in the driver, 
whereas I will not have to if the DT core can handle that new reg_named.

>>> Please, stick with the established convention and explicitly order
>>> 'reg' and 'interrupts' properties.  If there is a specific use case
>>> where this doesn't work, then bring it up, but I haven't seen any yet.
>>
>> There will always be some alternatives, but they will be uglier, and
>> the effort to add some extra node to DT is so small, that it is
>> better to do that instead of adding some useless extra code in the
>> driver.
>>
>>>   The current users of _byname that I've looked seem to only use it for
>>> convenience, not because a register range may be optional.  ie. they
>>> all fail out if a reg resource isn't present.
>>
>> If that API can help the driver writer and can avoid adding 10 lines
>> of code, it is still useful to use it.
>>
>> To be honest, I still do not understand why you are so reluctant to
>> add that small feature.
>
> Because this is a totally new basic feature to add to the DT
> bindings.  Once in there, we're stuck with it indefinitely, which
> means it warrants considerably more conservatism than mere internal
> code changes which can be easily updated or reverted.

OK, so it means that we need to be very careful with the design, but 
does not mean it should be rejected.
Since that feature can be useful for some people, it still worth doing 
it. Or do we have to keep that bindings for OMAP only?
In a period of consolidation, that does not seems to be the right solution.

Bottom-line, I can start with a RFC patch to add a new bindings and see 
it is make sense to go further with it.

Benoit

How to handle named resources with DT?

[Felipe Balbi]

Hi,

On Fri, Aug 12, 2011 at 01:02:18PM +1000, David Gibson wrote:
> > That seems to be pretty straightforward to implement, and as soon as
> > it is useful even for a couple of drivers, it worth adding it.
> > 
> > It is anyway better than having to add a custom property to get the
> > information we will miss otherwise.
> > 
> > Moreover, since some drivers are relying on that call, it will avoid
> > having to add extra code for nothing if CONFIG_OF is set.
> > 
> > It will allow the driver to use a pretty standard API in anycase vs
> > using platform_get_resource + some extra optional calls to of_
> > functions + some code to get the information for non-DT build.
> 
> You don't need to add stuff to the DT to use the byname interface.
> Really.  All you need is a way for the driver (well match table entry,
> really) to provide a list of names to attach to the reg entries in
> order.

the whole point of using *byname() is for the driver to not care about
the order of the resources. So if driver has to provided an ordered list
of names, what's the benefit ? Sounds really stupid to provide an
ordered list of names to an ordered list of resources, just to use
*byname() instead of just assuming the list of resources is already
ordered.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110812/e7931997/attachment.sig>

How to handle named resources with DT?

[Arnd Bergmann]

On Friday 12 August 2011, Felipe Balbi wrote:
> On Fri, Aug 12, 2011 at 01:02:18PM +1000, David Gibson wrote:
> 
> the whole point of using *byname() is for the driver to not care about
> the order of the resources. So if driver has to provided an ordered list
> of names, what's the benefit ? Sounds really stupid to provide an
> ordered list of names to an ordered list of resources, just to use
> *byname() instead of just assuming the list of resources is already
> ordered.

It only make sense for drivers that support both device tree probing
and legacy probing of static platform devices.

Note how almost all drivers use only platform_get_resource and not
platform_get_resource_byname:

arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource | wc -l
565
arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | wc -l
41
arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | xargs grep -wL platform_get_resource | wc -l # both
28
arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | xargs grep -wl platform_get_resource  | wc -l # only _byname
13

I think it's much easier to change the existing users of _byname over
to fixed indexes than to come up with a new scheme that is better.

	Arnd

How to handle named resources with DT?

[Cousson, Benoit]

On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
> On Friday 12 August 2011, Felipe Balbi wrote:
>> On Fri, Aug 12, 2011 at 01:02:18PM +1000, David Gibson wrote:
>>
>> the whole point of using *byname() is for the driver to not care about
>> the order of the resources. So if driver has to provided an ordered list
>> of names, what's the benefit ? Sounds really stupid to provide an
>> ordered list of names to an ordered list of resources, just to use
>> *byname() instead of just assuming the list of resources is already
>> ordered.
>
> It only make sense for drivers that support both device tree probing
> and legacy probing of static platform devices.
>
> Note how almost all drivers use only platform_get_resource and not
> platform_get_resource_byname:
>
> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource | wc -l
> 565
> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | wc -l
> 41
> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | xargs grep -wL platform_get_resource | wc -l # both
> 28
> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | xargs grep -wl platform_get_resource  | wc -l # only _byname
> 13

That's true, but this is mainly because most of the time there is only 
one irq, dma or mem resource, so the _byname is not useful.
As soon as you start having multiple entries, relying on the order 
become less readable and error prone. Then getting the resource by name 
become useful.
There are probably a lot of API that are less used than this one, but 
does that mean that we have to remove them?

The extreme case (soon in mainline) in OMAP is that one:

static struct omap_hwmod_addr_space omap44xx_aess_addrs[] = {
	{
		.name		= "dmem",
		.pa_start	= 0x40180000,
		.pa_end		= 0x4018ffff
	},
	{
		.name		= "cmem",
		.pa_start	= 0x401a0000,
		.pa_end		= 0x401a1fff
	},
	{
		.name		= "smem",
		.pa_start	= 0x401c0000,
		.pa_end		= 0x401c5fff
	},
	{
		.name		= "pmem",
		.pa_start	= 0x401e0000,
		.pa_end		= 0x401e1fff
	},
	{
		.name		= "reg",
		.pa_start	= 0x401f1000,
		.pa_end		= 0x401f13ff,
		.flags		= ADDR_TYPE_RT
     }
};

In that case, the driver knows exactly where is the relevant memory 
buffer he has to use.

> I think it's much easier to change the existing users of _byname over
> to fixed indexes than to come up with a new scheme that is better.

As you said previously, since we have to support both legacy probing and 
DT for some time, it will be easier for these drivers to rely on the 
same API.

Considering that adding that new property is not a huge effort anyway 
and _byname API is a standard API that any driver should be able to use 
if needed, it still worth adding the DT support for named resources for 
my point of view.
Moreover that seems much more consistent with the device tree format in 
general that does rely a lot on named properties for passing parameter 
to driver. That just my .2 cents.

Regards,
Benoit

How to handle named resources with DT?

[Grant Likely]

On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
>> It only make sense for drivers that support both device tree probing
>> and legacy probing of static platform devices.
>>
>> Note how almost all drivers use only platform_get_resource and not
>> platform_get_resource_byname:
>>
>> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource | wc -l
>> 565
>> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | wc
>> -l
>> 41
>> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname |
>> xargs grep -wL platform_get_resource | wc -l # both
>> 28
>> arnd at ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname |
>> xargs grep -wl platform_get_resource ?| wc -l # only _byname
>> 13
>
> That's true, but this is mainly because most of the time there is only one
> irq, dma or mem resource, so the _byname is not useful.
> As soon as you start having multiple entries, relying on the order become
> less readable and error prone. Then getting the resource by name become
> useful.
> There are probably a lot of API that are less used than this one, but does
> that mean that we have to remove them?
>
> The extreme case (soon in mainline) in OMAP is that one:
>
> static struct omap_hwmod_addr_space omap44xx_aess_addrs[] = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "dmem",
> ? ? ? ? ? ? ? ?.pa_start ? ? ? = 0x40180000,
> ? ? ? ? ? ? ? ?.pa_end ? ? ? ? = 0x4018ffff
> ? ? ? ?},
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "cmem",
> ? ? ? ? ? ? ? ?.pa_start ? ? ? = 0x401a0000,
> ? ? ? ? ? ? ? ?.pa_end ? ? ? ? = 0x401a1fff
> ? ? ? ?},
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "smem",
> ? ? ? ? ? ? ? ?.pa_start ? ? ? = 0x401c0000,
> ? ? ? ? ? ? ? ?.pa_end ? ? ? ? = 0x401c5fff
> ? ? ? ?},
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "pmem",
> ? ? ? ? ? ? ? ?.pa_start ? ? ? = 0x401e0000,
> ? ? ? ? ? ? ? ?.pa_end ? ? ? ? = 0x401e1fff
> ? ? ? ?},
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "reg",
> ? ? ? ? ? ? ? ?.pa_start ? ? ? = 0x401f1000,
> ? ? ? ? ? ? ? ?.pa_end ? ? ? ? = 0x401f13ff,
> ? ? ? ? ? ? ? ?.flags ? ? ? ? ?= ADDR_TYPE_RT
> ? ?}
> };
>
> In that case, the driver knows exactly where is the relevant memory buffer
> he has to use.
>
>> I think it's much easier to change the existing users of _byname over
>> to fixed indexes than to come up with a new scheme that is better.
>
> As you said previously, since we have to support both legacy probing and DT
> for some time, it will be easier for these drivers to rely on the same API.
>
> Considering that adding that new property is not a huge effort anyway and
> _byname API is a standard API that any driver should be able to use if
> needed, it still worth adding the DT support for named resources for my
> point of view.

The assumption being made here is that the current Linux
implementation detail dictates the binding design, but it does not.
Binding authors should certainly look at the Linux implementation for
inspiration, but established DT patterns still prevail if they are
suitable for describing the hardware. In this case the pattern is that
tuples in the reg property are strongly ordered and specified by the
driver binding.

So, I remain unconvinced that the 'reg' property binding is
insufficient.  I have no plans to merge support for fetching _byname
values from the device tree.

g.

How to handle named resources with DT?

[Kevin Hilman]

Grant Likely <grant.likely@secretlab.ca> writes:

> On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
>> On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
 
[...]

>>
>>> I think it's much easier to change the existing users of _byname over
>>> to fixed indexes than to come up with a new scheme that is better.

I disagree.  It's not only about ordering.  More on that below.

>> As you said previously, since we have to support both legacy probing and DT
>> for some time, it will be easier for these drivers to rely on the same API.
>>
>> Considering that adding that new property is not a huge effort anyway and
>> _byname API is a standard API that any driver should be able to use if
>> needed, it still worth adding the DT support for named resources for my
>> point of view.
>
> The assumption being made here is that the current Linux
> implementation detail dictates the binding design, but it does not.
>
> Binding authors should certainly look at the Linux implementation for
> inspiration, but established DT patterns still prevail if they are
> suitable for describing the hardware. In this case the pattern is that
> tuples in the reg property are strongly ordered and specified by the
> driver binding.
>
> So, I remain unconvinced that the 'reg' property binding is
> insufficient.  

If significant, in-tree usages of the feature for platform_devices is
not enough, What are you looking for as convincing arguments? 

> I have no plans to merge support for fetching _byname values from the
> device tree.

I find this an unfortunate position to hold to in this climate of
consolidation.

One of the goals of consolidation is to have core features handled by
core code.  To me this is a classic trade-off.  Either we implement it
in core code, or we force all the users (drivers, in this case) to
implement it themselves.  IMO, consolidation should be pointing us to
solving these kinds of problems in core code, rather than spreading it
across a bunch of drivers (and device code where the data lives.)
Especially so in this case since there are existing, in-tree users
demonstrating the usefulness of _byname.

Not implementing this in core code means all drivers using _byname have
to be converted, adding multiple lines of (IMHO ugly) code when it could
be implemented cleanly by core code, keeping drivers much more readable.
To me, the fact that there would also be an API difference compared to
the existing platform_device probing (which will stay for the forseeable
future) would be a major eye-sore in the drivers.

In addition, converting all the drivers away from _byname is not just a
matter of changing the drivers.  It also means of course you have to
make sure that all of the data is in order.  On OMAP, that means
reworking and/or regenerating all of the hwmod data to ensure it is in
the right order.  Sounds like the kind of churn that would get us
flamed.

But that's not all...

It's not just about data ordering.  As already pointed out, use of
_byname is also used to differentiate between different
versions/capabilities of the IP.  The driver can determine based on the
availability of a named resource the capabilities of the device.
Forcing resource ordering means some other mechanism also has to be
added for detection of the IP version and/or capabilities.

In summary, with the push towards consolidation, we're also trying to
have common drivers that support multiple versions of an IP across
differnet SoCs with varying capabilities.  Having named resources on the
platform_device is an established way of handling this cleanly in the
driver without the driver having to check SoC-specific or IP-version
specific registers.

Kevin

How to handle named resources with DT?

[Felipe Balbi]

Hi,

On Wed, Aug 24, 2011 at 12:15:03PM -0700, Kevin Hilman wrote:
> Grant Likely <grant.likely@secretlab.ca> writes:
> 
> > On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
> >> On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
>  
> [...]
> 
> >>
> >>> I think it's much easier to change the existing users of _byname over
> >>> to fixed indexes than to come up with a new scheme that is better.
> 
> I disagree.  It's not only about ordering.  More on that below.
> 
> >> As you said previously, since we have to support both legacy probing and DT
> >> for some time, it will be easier for these drivers to rely on the same API.
> >>
> >> Considering that adding that new property is not a huge effort anyway and
> >> _byname API is a standard API that any driver should be able to use if
> >> needed, it still worth adding the DT support for named resources for my
> >> point of view.
> >
> > The assumption being made here is that the current Linux
> > implementation detail dictates the binding design, but it does not.
> >
> > Binding authors should certainly look at the Linux implementation for
> > inspiration, but established DT patterns still prevail if they are
> > suitable for describing the hardware. In this case the pattern is that
> > tuples in the reg property are strongly ordered and specified by the
> > driver binding.
> >
> > So, I remain unconvinced that the 'reg' property binding is
> > insufficient.  
> 
> If significant, in-tree usages of the feature for platform_devices is
> not enough, What are you looking for as convincing arguments? 
> 
> > I have no plans to merge support for fetching _byname values from the
> > device tree.
> 
> I find this an unfortunate position to hold to in this climate of
> consolidation.
> 
> One of the goals of consolidation is to have core features handled by
> core code.  To me this is a classic trade-off.  Either we implement it
> in core code, or we force all the users (drivers, in this case) to
> implement it themselves.  IMO, consolidation should be pointing us to
> solving these kinds of problems in core code, rather than spreading it
> across a bunch of drivers (and device code where the data lives.)
> Especially so in this case since there are existing, in-tree users
> demonstrating the usefulness of _byname.
> 
> Not implementing this in core code means all drivers using _byname have
> to be converted, adding multiple lines of (IMHO ugly) code when it could
> be implemented cleanly by core code, keeping drivers much more readable.
> To me, the fact that there would also be an API difference compared to
> the existing platform_device probing (which will stay for the forseeable
> future) would be a major eye-sore in the drivers.
> 
> In addition, converting all the drivers away from _byname is not just a
> matter of changing the drivers.  It also means of course you have to
> make sure that all of the data is in order.  On OMAP, that means
> reworking and/or regenerating all of the hwmod data to ensure it is in
> the right order.  Sounds like the kind of churn that would get us
> flamed.
> 
> But that's not all...
> 
> It's not just about data ordering.  As already pointed out, use of
> _byname is also used to differentiate between different
> versions/capabilities of the IP.  The driver can determine based on the
> availability of a named resource the capabilities of the device.
> Forcing resource ordering means some other mechanism also has to be
> added for detection of the IP version and/or capabilities.
> 
> In summary, with the push towards consolidation, we're also trying to
> have common drivers that support multiple versions of an IP across
> differnet SoCs with varying capabilities.  Having named resources on the
> platform_device is an established way of handling this cleanly in the
> driver without the driver having to check SoC-specific or IP-version
> specific registers.

on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in a certain
order. It sounds to me that this will be prone to error in many ways
until everything is synced up and on the correct order.

Ditching _byname is a very bad idea.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110825/59dcac69/attachment.sig>

How to handle named resources with DT?

[Russell King - ARM Linux]

On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
> on top of all that, for IPs which are used on many SoCs (such as MUSB)
> it's quite silly to force all users to provide resources in a certain
> order. It sounds to me that this will be prone to error in many ways
> until everything is synced up and on the correct order.
> 
> Ditching _byname is a very bad idea.

I continue to disagree.  The current _byname is an abonimation and hack
to try to "fix" this problem.

_byname should have been implemented differently - rather than overriding
the resources name field (which is _normally_ specified to be the device
or driver name), a new field should have been introduced in struct resource
to carry the resource sub-name (which is really what it is.)

That would have avoided making /proc/iomem completely illegible with
multiple devices using this feature.

How to handle named resources with DT?

[Arnd Bergmann]

On Thursday 25 August 2011, Russell King - ARM Linux wrote:
> 
> On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
> > on top of all that, for IPs which are used on many SoCs (such as MUSB)
> > it's quite silly to force all users to provide resources in a certain
> > order. It sounds to me that this will be prone to error in many ways
> > until everything is synced up and on the correct order.
> > 
> > Ditching _byname is a very bad idea.
> 
> I continue to disagree.  The current _byname is an abonimation and hack
> to try to "fix" this problem.
> 
> _byname should have been implemented differently - rather than overriding
> the resources name field (which is normally specified to be the device
> or driver name), a new field should have been introduced in struct resource
> to carry the resource sub-name (which is really what it is.)
> 
> That would have avoided making /proc/iomem completely illegible with
> multiple devices using this feature.

I agree 100%.

I'm also sure that the danger of breaking something by removing the
_byname resource resolution for each driver that we convert to DT
based probing is very small: We already need to change all static
platform_device definitions along with changing the driver, and
identifying them by index is no more ambiguous than accessing an
individual MMIO register by its index. You can even use an enum
or macro to name the indexes like:

enum {
	FOO_RESOURCE_SETUP,
	FOO_RESOURCE_POWER,
	FOO_RESOURCE_BUFFER,
};

static struct resource foo_res[] = {
	[FOO_RESOURCE_SETUP] = {
		.start = FOO_SETUP_BASE,
		.end   = FOO_SETUP_BASE + FOO_SETUP_LEN -1,
		.flags = IORESOURCE_MEM,
	},
	[FOO_RESOURCE_POWER] = {
		.start = FOO_POWER_BASE,
		.end   = FOO_POWER_BASE + FOO_POWER_LEN -1,
		.flags = IORESOURCE_MEM,
	},
	[FOO_RESOURCE_BUFFER] = {
		.start = FOO_BUFFER_BASE,
		.end   = FOO_BUFFER_BASE + FOO_BUFFER_LEN -1,
		.flags = IORESOURCE_MEM,
	},
};

	Arnd

How to handle named resources with DT?

[Kevin Hilman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 25 August 2011, Russell King - ARM Linux wrote:
>> 
>> On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
>> > on top of all that, for IPs which are used on many SoCs (such as MUSB)
>> > it's quite silly to force all users to provide resources in a certain
>> > order. It sounds to me that this will be prone to error in many ways
>> > until everything is synced up and on the correct order.
>> > 
>> > Ditching _byname is a very bad idea.
>> 
>> I continue to disagree.  The current _byname is an abonimation and hack
>> to try to "fix" this problem.
>> 
>> _byname should have been implemented differently - rather than overriding
>> the resources name field (which is normally specified to be the device
>> or driver name), a new field should have been introduced in struct resource
>> to carry the resource sub-name (which is really what it is.)
>> 
>> That would have avoided making /proc/iomem completely illegible with
>> multiple devices using this feature.
>
> I agree 100%.

Please clarify. 

What I hear Russell saying is a problem with the *implementation* of the
_byname API.  

What I hear you sating is that since DT doesn't support this, we need to
remove it's usage completely from platform_devices also.

These are two very different approaches.

Fixing the implementation as Russell suggested seems relatively easy,
and conceptually similar to adding it to the DT.  Removing _byname all
together seems like significant work just to avoid adding a feature to
the DT core.

Kevin

How to handle named resources with DT?

[Arnd Bergmann]

On Thursday 25 August 2011 11:16:25 Kevin Hilman wrote:
> Please clarify. 
> 
> What I hear Russell saying is a problem with the implementation of the
> _byname API.  
> 
> What I hear you sating is that since DT doesn't support this, we need to
> remove it's usage completely from platform_devices also.
> 
> These are two very different approaches.
> 
> Fixing the implementation as Russell suggested seems relatively easy,
> and conceptually similar to adding it to the DT.  Removing _byname all
> together seems like significant work just to avoid adding a feature to
> the DT core.

It's not at all about whether the Linux codein drivers/of supports this
or not, adding it would be trivial. The point is that it would be
*wrong* to add it because there already exists a way to identify every
resource in the device tree and we should not extend that interface
to have multiple ways to do the same thing just for convenience of
a few device drivers! One of the important advantages of using the
IEEE device tree bindings is that we can define device trees that
are to a large degree compatible with how AIX, Solaris, MacOS, FreeBSD
and probably many more (lesser known) operating systems probe
their systems.

Changing the resource interface in Linux to have two 'name' fields
would also be terribly confusing and is not a good interface, it would
just solve another problem (silly entries in /proc/iomem) that we don't
need to have in the first place when we do the obvious conversion
of the drivers to the IEEE standard way of doing this.

	Arnd

Removing platform_get_resource_byname() (was Re: How to handle named resources with DT?)

[Paul Walmsley]

On Thu, 25 Aug 2011, Arnd Bergmann wrote:

> It's not at all about whether the Linux codein drivers/of supports this
> or not, adding it would be trivial. The point is that it would be
> *wrong* to add it because there already exists a way to identify every
> resource in the device tree and we should not extend that interface
> to have multiple ways to do the same thing just for convenience of
> a few device drivers!

The point is that:

- there was a reason why platform_get_resource_byname() was added to the 
  Linux kernel, that at least some people find useful and relevant

- some folks are effectively proposing to remove
  platform_get_resource_byname() not because it's a bad interface, but 
  because it would result in changes to the way that DT files are 
  generated and used

Just as you consider the preservation of platform_get_resource_byname() to 
be wrong (because it conflicts with DT), some people consider the above 
rationale to be faulty, because it removes a useful way to abstract 
drivers from SoC data.

For example, consider that the ordering of device resources, such as IRQ 
lines or memory regions, in the hardware IP block is arbitrary.  Whomever 
generates a DT file for that hardware will need to hardcode the driver's 
assumptions for resource order into the DT generator.  And then hope that 
the binding assumptions made by that driver are coordinated between all of 
the other potential DT users out there: other OSes (proprietary or not), 
bootloaders, etc.

Contrast this with the situation when named resources are used.  The 
resources are named with a string that represents their use by the 
hardware IP block.  In this situation, the order in which they appear in 
the DT file is unimportant.  There need be no extra hacks added to the DT 
generation code or to the drivers to ensure that they find the correct 
resource.

Please don't misunderstand: I personally don't consider this specific 
problem to be a showstopper.  It makes sense to me to improve the DT 
format to use named resources.  But if the consensus is that the problem 
is just going to be knowingly pushed on to the poor folks who have to 
generate DT files, who will have to maintain a bunch of hacks to do so, 
then, so be it.  But the issue highlights a much larger problem: the 
apparent level of resistance to improving the DT data format in ways that 
may affect backwards compatibility.

There are several aspects of DT, and the way that it's used in the kernel, 
that could be improved -- like, for example, the fact that computer 
systems for the past several years are not well-represented by a tree of 
devices.  And if we don't have a strategy for versioning the content and 
the layout of the device data, as opposed to simply its binary format, 
then it's unwise to consider it for broader adoption until this exists, 
IMHO.

> One of the important advantages of using the IEEE device tree bindings 
> is that we can define device trees that are to a large degree compatible 
> with how AIX, Solaris, MacOS, FreeBSD and probably many more (lesser 
> known) operating systems probe their systems.

By that rationale, we should just use ACPI.  It's far more widely deployed 
than all of those other OSes combined.  (No, I don't think we should use 
ACPI.)

By the way, MacOS stopped using Device Tree several years ago.

> Changing the resource interface in Linux to have two 'name' fields
> would also be terribly confusing and is not a good interface

There are other ways of solving that particular problem, other than having 
two 'name' fields.

> it would just solve another problem (silly entries in /proc/iomem) that 
> we don't need to have in the first place when we do the obvious 
> conversion of the drivers to the IEEE standard way of doing this.

Just like MacOS, the IEEE gave up on Device Tree -- in fact, over a decade 
ago -- so it doesn't make sense to cite them as an authority any more.

My point is not to disrespect DT, which seems like a useful way of moving 
device data out of the kernel tree; but rather, to try to ensure that 
we're not locked into a rigid and outdated way of doing things: either 
technically, or by people's attitudes.


- Paul

How to handle named resources with DT?

[David Gibson]

On Thu, Aug 25, 2011 at 11:16:25AM -0700, Kevin Hilman wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Thursday 25 August 2011, Russell King - ARM Linux wrote:
> >> On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
> >> > on top of all that, for IPs which are used on many SoCs (such as MUSB)
> >> > it's quite silly to force all users to provide resources in a certain
> >> > order. It sounds to me that this will be prone to error in many ways
> >> > until everything is synced up and on the correct order.
> >> > 
> >> > Ditching _byname is a very bad idea.
> >> 
> >> I continue to disagree.  The current _byname is an abonimation and hack
> >> to try to "fix" this problem.
> >> 
> >> _byname should have been implemented differently - rather than overriding
> >> the resources name field (which is normally specified to be the device
> >> or driver name), a new field should have been introduced in struct resource
> >> to carry the resource sub-name (which is really what it is.)
> >> 
> >> That would have avoided making /proc/iomem completely illegible with
> >> multiple devices using this feature.
> >
> > I agree 100%.
> 
> Please clarify. 
> 
> What I hear Russell saying is a problem with the *implementation* of the
> _byname API.  
> 
> What I hear you sating is that since DT doesn't support this, we need to
> remove it's usage completely from platform_devices also.
> 
> These are two very different approaches.
> 
> Fixing the implementation as Russell suggested seems relatively easy,
> and conceptually similar to adding it to the DT.  Removing _byname all
> together seems like significant work just to avoid adding a feature to
> the DT core.

Seriously, how many times do I have to say it?


Using _byname in drivers DOES NOT require adding names to the DT.


All it needs is some glue logic to attach names as the device tree is
read.  This is properly thought of as part of the code which
translates the device tree into struct platform_device, not as part of
drivers proper.

FURTHERMORE, even if there were names in the DT, you'd *still* need
this glue logic, so that drivers converted to _byname could still use
old device trees.

Insisting that the names come from the DT is to mistakenly think of
the DT as an extension of the kernel's internal interfaces, instead of
as the external and OS neutral data structure it actually is.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Arnd Bergmann]

On Friday 26 August 2011, David Gibson wrote:
> Seriously, how many times do I have to say it?
> 
> 
> Using _byname in drivers DOES NOT require adding names to the DT.
> 
> 
> All it needs is some glue logic to attach names as the device tree is
> read.  This is properly thought of as part of the code which
> translates the device tree into struct platform_device, not as part of
> drivers proper.

But if you do such code, the only logical place for it to live would
be in that driver, otherwise you end up with multiple places in the
kernel source tree that deal with the same devices and need to be
updated in lock-step. Getting away from this mess is one of the main
reasons for converting to device tree based probing in the first place.

> FURTHERMORE, even if there were names in the DT, you'd still need
> this glue logic, so that drivers converted to _byname could still use
> old device trees.

I don't think anyone was talking about converting driver /to/ the
_byname method, the debate is mostly whether we should move away from
that while we convert drivers to no longer rely on board code but
instead allow them to be probed from the device tree.

> Insisting that the names come from the DT is to mistakenly think of
> the DT as an extension of the kernel's internal interfaces, instead of
> as the external and OS neutral data structure it actually is.

Agreed, that was my main point anyway: Getting the name from the
device tree would be a huge mistake. By comparison, the scenario you
describe -- adding another identifier to struct resource and initializing
from the driver that consumes it -- would not be harmful at all, just a
little silly when you end up with a probe function like

static int __devinit foo_probe(struct platform_device *pdev)
{
	struct foo_private *priv = kzalloc(sizeof (*priv));
	pdev->dev.private_data = priv;
	struct resource *res;

	if (pdev->dev.of_node) {
		platform_get_resource(pdev, IORESOURCE_MEM, FOO_RESOURCE_BAR).id = "bar";
		platform_get_resource(pdev, IORESOURCE_MEM, FOO_RESOURCE_BAZ).id = "baz";
	}

	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "bar");
	priv.bar = resource_iomap(res);
	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "baz");
	priv.baz = resource_iomap(res);

	foo_register(priv);
}

	Arnd

How to handle named resources with DT?

[David Gibson]

On Fri, Aug 26, 2011 at 12:58:32PM +0200, Arnd Bergmann wrote:
> On Friday 26 August 2011, David Gibson wrote:
> > Seriously, how many times do I have to say it?
> > 
> > 
> > Using _byname in drivers DOES NOT require adding names to the DT.
> > 
> > 
> > All it needs is some glue logic to attach names as the device tree is
> > read.  This is properly thought of as part of the code which
> > translates the device tree into struct platform_device, not as part of
> > drivers proper.
> 
> But if you do such code, the only logical place for it to live would
> be in that driver, otherwise you end up with multiple places in the
> kernel source tree that deal with the same devices and need to be
> updated in lock-step. Getting away from this mess is one of the main
> reasons for converting to device tree based probing in the first place.

Obviously it would be in the driver file, but I'd think of it more as
some metadata attached to the driver, rather than truly part of the
driver.

> > FURTHERMORE, even if there were names in the DT, you'd still need
> > this glue logic, so that drivers converted to _byname could still use
> > old device trees.
> 
> I don't think anyone was talking about converting driver /to/ the
> _byname method, the debate is mostly whether we should move away from
> that while we convert drivers to no longer rely on board code but
> instead allow them to be probed from the device tree.
> 
> > Insisting that the names come from the DT is to mistakenly think of
> > the DT as an extension of the kernel's internal interfaces, instead of
> > as the external and OS neutral data structure it actually is.
> 
> Agreed, that was my main point anyway: Getting the name from the
> device tree would be a huge mistake. By comparison, the scenario you
> describe -- adding another identifier to struct resource and initializing
> from the driver that consumes it -- would not be harmful at all, just a
> little silly when you end up with a probe function like

If you open code it this way then yes, it's silly.  But what about
something like this:

static struct of_device_id foodevice_of_match[] __devinitdata = {
	{ .compatible = "foocorp,foodevice1234",
	  .resource_names = {"base_regs", "extra_regs", }, },
	{ .compatible = "foocorp,foodevice1239",
	  .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
	{ },
};

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Arnd Bergmann]

On Friday 26 August 2011, David Gibson wrote:
> If you open code it this way then yes, it's silly.  But what about
> something like this:
> 
> static struct of_device_id foodevice_of_match[] __devinitdata = {
>         { .compatible = "foocorp,foodevice1234",
>           .resource_names = {"base_regs", "extra_regs", }, },
>         { .compatible = "foocorp,foodevice1239",
>           .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
>         { },
> };

Hmm, I hadn't thought of that. This looks quite nice indeed. No objections
to this from my side.

	Arnd

How to handle named resources with DT?

[Arnd Bergmann]

On Friday 26 August 2011, Arnd Bergmann wrote:
> On Friday 26 August 2011, David Gibson wrote:
> > If you open code it this way then yes, it's silly.  But what about
> > something like this:
> > 
> > static struct of_device_id foodevice_of_match[] __devinitdata = {
> >         { .compatible = "foocorp,foodevice1234",
> >           .resource_names = {"base_regs", "extra_regs", }, },
> >         { .compatible = "foocorp,foodevice1239",
> >           .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
> >         { },
> > };
> 
> Hmm, I hadn't thought of that. This looks quite nice indeed. No objections
> to this from my side.
> 

Ah well, one objection on second thought:

This assumes that there is just one type of resource, but named resources
may be used for iomem, ioport and irq resources. If you have multiple
IRQs and multiple IOMEM resources, I don't see how the index in the 
resource_names array can be used for both of them.

	Arnd

How to handle named resources with DT?

[David Gibson]

On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
> On Friday 26 August 2011, Arnd Bergmann wrote:
> > On Friday 26 August 2011, David Gibson wrote:
> > > If you open code it this way then yes, it's silly.  But what about
> > > something like this:
> > > 
> > > static struct of_device_id foodevice_of_match[] __devinitdata = {
> > >         { .compatible = "foocorp,foodevice1234",
> > >           .resource_names = {"base_regs", "extra_regs", }, },
> > >         { .compatible = "foocorp,foodevice1239",
> > >           .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
> > >         { },
> > > };
> > 
> > Hmm, I hadn't thought of that. This looks quite nice indeed. No objections
> > to this from my side.
> > 
> 
> Ah well, one objection on second thought:
> 
> This assumes that there is just one type of resource, but named resources
> may be used for iomem, ioport and irq resources. If you have multiple
> IRQs and multiple IOMEM resources, I don't see how the index in the 
> resource_names array can be used for both of them.

Details, shmetails, so you have both 'reg_names' and 'interrupt_names'.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Arnd Bergmann]

On Sunday 28 August 2011 00:37:36 David Gibson wrote:
> On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
> > On Friday 26 August 2011, Arnd Bergmann wrote:
> > > On Friday 26 August 2011, David Gibson wrote:
> > > > If you open code it this way then yes, it's silly.  But what about
> > > > something like this:
> > > > 
> > > > static struct of_device_id foodevice_of_match[] __devinitdata = {
> > > >         { .compatible = "foocorp,foodevice1234",
> > > >           .resource_names = {"base_regs", "extra_regs", }, },
> > > >         { .compatible = "foocorp,foodevice1239",
> > > >           .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
> > > >         { },
> > > > };
> > > 
> > > Hmm, I hadn't thought of that. This looks quite nice indeed. No objections
> > > to this from my side.
> > > 
> > 
> > Ah well, one objection on second thought:
> > 
> > This assumes that there is just one type of resource, but named resources
> > may be used for iomem, ioport and irq resources. If you have multiple
> > IRQs and multiple IOMEM resources, I don't see how the index in the 
> > resource_names array can be used for both of them.
> 
> Details, shmetails, so you have both 'reg_names' and 'interrupt_names'.

Right, and I guess we can simply ignore DMA and ioport resources because they
are extremely rare, right?

One more detail: IIRC struct of_device_id is exported to module_init_tools
for purposes of autoloading, so changing the structure breaks user space.

	Arnd

How to handle named resources with DT?

[Paul Walmsley]

On Sat, 27 Aug 2011, Arnd Bergmann wrote:

> Right, and I guess we can simply ignore DMA and ioport resources because 
> they are extremely rare, right?

DMA resources are quite widely used.

For example, looking at the SoCs with some publicly-available 
documentation, the Motorola i.MX51 reference manual lists 47 SDMA request 
lines across about 17 different IP block types[1], and to pick a 
representative OMAP, the OMAP3430 technical reference manual lists 77 SDMA 
request lines, used by at least 9 different IP block types[2].

Also, many IP blocks have multiple DMA resources.  For example, the above 
references list UART, MCSPI, PATA, I2C, FIRI, MCBSP, SSI, CTI, CSPI, 
eCSPI, EMI, eSDHC, SPI, and DSS.


- Paul

1. Table 3-3, "SDMA Event Mapping".  _MCIMX51 Multimedia Applications 
   Processor Reference Manual (MCIMX51RM) Rev. 1 2/2010_.  Available from
   http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX515&fpsp=1&tab=Documentation_Tab

2. This is simply one example from the OMAP3430 TRM, but similar tables
   are available for OMAP2420, 2430, 3430, 3630, 4430, 4460, 4470, etc.
   Table 9-3, "SDMA Request Mapping". _OMAP34xx Multimedia Device Silicon 
   Revision 3.1.x Version J (SWPU223J)_ (public version).  Available from 
   http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12667

How to handle named resources with DT?

[Arnd Bergmann]

On Saturday 27 August 2011, Paul Walmsley wrote:
> On Sat, 27 Aug 2011, Arnd Bergmann wrote:
> 
> > Right, and I guess we can simply ignore DMA and ioport resources because 
> > they are extremely rare, right?
> 
> DMA resources are quite widely used.
> 
> For example, looking at the SoCs with some publicly-available 
> documentation, the Motorola i.MX51 reference manual lists 47 SDMA request 
> lines across about 17 different IP block types[1], and to pick a 
> representative OMAP, the OMAP3430 technical reference manual lists 77 SDMA 
> request lines, used by at least 9 different IP block types[2].
> 
> Also, many IP blocks have multiple DMA resources.  For example, the above 
> references list UART, MCSPI, PATA, I2C, FIRI, MCBSP, SSI, CTI, CSPI, 
> eCSPI, EMI, eSDHC, SPI, and DSS.

I don't doubt that many devices have a DMA controllers with multiple
channels, but I think the last time we discussed those, the conclusion
was that they should not actually be represented as DMA resources.

The problem with DMA resources is that they assume the presence of
a global number space for DMA channel numbers, while in reality a
lot of devices have multiple DMA controllers that have independent
channel numbers.

We should have a proper device tree binding for dma-controllers that
enables us to find both the channel and the controller in a simple
dma-controller API call without having to resort to global numbers.

In a way that is the same with IRQ numbers, however the concept of
a global number space for interrupt lines is used in so many places
in the kernel that we can't reasonably move away from that. For
dma-engine drivers, the concept does not exist in a driver-independent
way and we should not introduce it.

	Arnd

How to handle named resources with DT?

[David Gibson]

On Sat, Aug 27, 2011 at 08:13:59PM +0200, Arnd Bergmann wrote:
> On Sunday 28 August 2011 00:37:36 David Gibson wrote:
> > On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
> > > On Friday 26 August 2011, Arnd Bergmann wrote:
> > > > On Friday 26 August 2011, David Gibson wrote:
> > > > > If you open code it this way then yes, it's silly.  But what about
> > > > > something like this:
> > > > > 
> > > > > static struct of_device_id foodevice_of_match[] __devinitdata = {
> > > > >         { .compatible = "foocorp,foodevice1234",
> > > > >           .resource_names = {"base_regs", "extra_regs", }, },
> > > > >         { .compatible = "foocorp,foodevice1239",
> > > > >           .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
> > > > >         { },
> > > > > };
> > > > 
> > > > Hmm, I hadn't thought of that. This looks quite nice indeed. No objections
> > > > to this from my side.
> > > > 
> > > 
> > > Ah well, one objection on second thought:
> > > 
> > > This assumes that there is just one type of resource, but named resources
> > > may be used for iomem, ioport and irq resources. If you have multiple
> > > IRQs and multiple IOMEM resources, I don't see how the index in the 
> > > resource_names array can be used for both of them.
> > 
> > Details, shmetails, so you have both 'reg_names' and 'interrupt_names'.
> 
> Right, and I guess we can simply ignore DMA and ioport resources because they
> are extremely rare, right?

Well, remember it's where resources can appear in the DT node that
matters, not what the types are in the platform device.  ioports will
typically appear suitably encoded in 'reg', so that's covered.  I've
never been very clear on what exactly DMA resources cover, but yeah,
you might need something for dma-reg or other device tree properties.

> One more detail: IIRC struct of_device_id is exported to module_init_tools
> for purposes of autoloading, so changing the structure breaks user
> space.

Ah.  That is a bit more of a problem.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Paul Walmsley]

On Sun, 28 Aug 2011, David Gibson wrote:

> I've never been very clear on what exactly DMA resources cover,

DMA resource data are usually DMA request line ID numbers.

DMA request lines are dedicated, unidirectional hardware signals from I/O 
devices to one or more independent DMA controllers[1][2][3].  Request 
lines indicate when the device is ready to accept data from the DMA 
controller, or, when the device has data ready for the DMA controller to 
fetch.  On a given DMA controller, each request line has its own unique ID 
number[4][5][6].

During a DMA transfer, the I/O device asserts or deasserts its DMA request 
lines as its FIFOs fill or drain[7][8].  This will pause or resume the DMA 
transfer, if the DMA controller is programmed with the correct DMA request 
line IDs[9][10][11][12].  In a hardware-synchronized DMA transfer, the DMA 
controller must be controlled by the device because it is not good to read 
from an empty device FIFO, or to write to a full device FIFO.  There 
aren't many sane courses of action in those circumstances with most 
interconnects and DMA controllers.

So in terms of Linux kernel code, the driver needs the DMA request line ID 
numbers so it and the DMA code can program the DMA controller to 
synchronize DMA transfers with the I/O device(s).

Like hardware IRQ IDs, these DMA request line IDs are properties of a DMA 
controller itself, but are associated with individual I/O devices.  And 
like IRQ IDs, these DMA request line ID mappings may change from chip 
version to chip version[13], even for the same IP block.  So it is useful 
for device data formats to provide DMA request line IDs dynamically.

Several upstream device drivers get their DMA request line IDs from the 
device data format[14][15][16].  But more drivers should be doing this 
than currently are[17]:

- the device driver author may have hardcoded the DMA request line ID, 
  assuming it would never change

- DMA could be broken on the device due to hardware bugs, so it is unused

- the driver author may just never have gotten around to implementing DMA, 
  or was reassigned to another project, or couldn't figure it out

- the device may have its own internal DMA controller logic, so support 
  for an external DMA controller was simply never added

When looking at a driver, it may not be obvious which of the cases 
apply.

(N.B., I/O device IP blocks that contain their own dedicated DMA 
controllers that are specialized to transfer only to memory don't need DMA 
request lines.)


- Paul


All code citations below are of Linux v3.1-rc3.

1. A DMA controller's view of DMA request lines.  Figure 9-4, "SDMA 
   Controller Integration".  _OMAP34xx Multimedia Device Silicon Revision 
   3.1.x Version R (SWPU223R)_ (public version).
   http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip

2. A simple device's view of DMA request lines, only connected to one
   DMA controller.  Figure 22-17, "MMC/SD/SDIO1 Integration". _OMAP34xx 
   Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public 
   version).
   http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip

3. A device's view of its DMA request lines connected to two separate DMA
   controllers, and thus with distinct numbering.  Note also that the 
   device refers to its signals with strings, while the DMA controllers
   refer to the same signals with ID numbers.  Figure 21-16, "McBSP1 
   Integration". _OMAP34xx Multimedia Device Silicon Revision 3.1.x 
   Version R (SWPU223R)_ (public version).
   http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip

4. Table 5-1 "Peripheral Addresses and Selectors". _RMI Alchemy Au1550 
   Security Network Processor Data Book Revision E_.  May 2007.
   Available from 
   http://www.poeticmonkey.com/ebay/semiconductors/cpus/au1550/au1550_db_0507e.pdf

5. Table 6-7 "Priority and Default Mapping of Peripheral to DMA". 
   _ADSP-BF51x Blackfin Processor Hardware Reference Preliminary Revision 
   0.1_ (January 2009).  Available from 
   http://www.analog.com/static/imported-files/processor_manuals/bf51x_hwr_rev_0-1.pdf

6. Table 16-5 "sDMA Controller Request Mapping". _OMAP4460 Multimedia 
   Device Silicon Revision 1.x Version H (Public Version) (SWPU235H)_.
   Available from 
   http://focus.ti.com/pdfs/wtbu/OMAP4460_ES1.x_PUBLIC_TRM_vH.zip

7. A really nice illustration of the interaction between a FIFO and
   DMA request line during DMA receive.  Figure 17-25
   "Receive FIFO DMA Request Generation (32 Characters)".  _OMAP34xx 
   Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public 
   version).
   http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip

8. A similarly good illustration of the interaction between a FIFO and 
   DMA request line during DMA transmit.  Figure 17-26
   "Transmit FIFO DMA Request Generation (56 Spaces)".  _OMAP34xx
   Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public 
   version).
   http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip

9. Table 3-23 "DMACCxConfiguration Register bit assignments".  _PrimeCell 
   DMA Controller (PL080) Technical Reference Manual (DDI0196G)_.
   http://infocenter.arm.com/help/topic/com.arm.doc.ddi0196g/DDI0196.pdf

10. Section 16.4.9.2 "Hardware Synchronization".  _OMAP4460 Multimedia
    Device Silicon Revision 1.x Version H (Public Version) (SWPU235H)_.
    Available from
    http://focus.ti.com/pdfs/wtbu/OMAP4460_ES1.x_PUBLIC_TRM_vH.zip

11. Page 6-5 "Peripheral DMA". _ADSP-BF51x Blackfin Processor Hardware 
    Reference Preliminary Revision 0.1_ (January 2009).  Available from   
    http://www.analog.com/static/imported-files/processor_manuals/bf51x_hwr_rev_0-1.pdf

12. Section 5.3.1.1 "Command 0". _RMI Alchemy Au1550
    Security Network Processor Data Book Revision E_.  May 2007.
    Available from
    http://www.poeticmonkey.com/ebay/semiconductors/cpus/au1550/au1550_db_0507e.pdf

13. For example, consider what happens to the EXT_DMAREQ3 request line ID
    on the SDMA controller:
    ... from the OMAP2420:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/dma.h;h=dc562a5c0a8ad2c7117b0b02e43b85cabe7b9aa5;hb=c11a7e26f8ee60bda0e64983291113ce5d04df55#l113
    ... to the OMAP2430:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/dma.h;h=dc562a5c0a8ad2c7117b0b02e43b85cabe7b9aa5;hb=c11a7e26f8ee60bda0e64983291113ce5d04df55#l125
    ... to the OMAP3430:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/dma.h;h=dc562a5c0a8ad2c7117b0b02e43b85cabe7b9aa5;hb=c11a7e26f8ee60bda0e64983291113ce5d04df55#l179

14. An OMAP2+ driver example is: drivers/tty/serial/omap-serial.c lines 
    1249 and 1255:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/tty/serial/omap-serial.c#l1249

15. An Alchemy AU1xxx example is: sound/soc/au1x/dbdma2.c lines 173 and 
    177:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/soc/au1x/dbdma2.c#l173

16. A Blackfin BF51x example is: drivers/spi/spi-bfin5xx.c line 1323:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/spi/spi-bfin5xx.c#l1323

17. First Law of Kernel Hacking: the bodies are always buried in the 
    device driver code.

How to handle named resources with DT?

[Russell King - ARM Linux]

On Sun, Aug 28, 2011 at 05:06:43PM -0600, Paul Walmsley wrote:
> DMA resource data are usually DMA request line ID numbers.

Not always.  On ARMs development platforms, we ended up using strings -
because we've ended up with a DMA controller with N request signals,
where the first three request signals come from a MUX which assigns
them to other devices in the system.

An opaque number doesn't hack it because you start having to define
arbitary ranges for such things, and that very quickly starts getting
you into sticky problems when you have to work out that request
signal S1 is routed through mux M1 which is connected to DMA request
signal D1, and if M1 is in use, then maybe M2 can be used instead
which routes to DMA request signal D2.

The idea that DMA should be small integers is very limiting.

How to handle named resources with DT?

[Paul Walmsley]

Hi,

one case that I forgot to mention:

On Sun, 28 Aug 2011, Paul Walmsley wrote:

> Several upstream device drivers get their DMA request line IDs from the 
> device data format[14][15][16].  But more drivers should be doing this 
> than currently are[17]:
> 
> - the device driver author may have hardcoded the DMA request line ID, 
>   assuming it would never change
> 
> - DMA could be broken on the device due to hardware bugs, so it is unused
> 
> - the driver author may just never have gotten around to implementing DMA, 
>   or was reassigned to another project, or couldn't figure it out
> 
> - the device may have its own internal DMA controller logic, so support 
>   for an external DMA controller was simply never added

- the driver may be using software-initiated DMA, which doesn't use a 
  DMA request line, nor does it rely on the device to start or stop DMA.
  Instead, the CPU reprograms the DMA controller when the driver receives 
  an interrupt


- Paul

How to handle named resources with DT?

[Arnd Bergmann]

On Sunday 28 August 2011, David Gibson wrote:
> > Right, and I guess we can simply ignore DMA and ioport resources because they
> > are extremely rare, right?
> 
> Well, remember it's where resources can appear in the DT node that
> matters, not what the types are in the platform device.  ioports will
> typically appear suitably encoded in 'reg', so that's covered.  I've
> never been very clear on what exactly DMA resources cover, but yeah,
> you might need something for dma-reg or other device tree properties.

DMA resources are only meaningful with the legacy ISA dma API, all
other uses are basically ad-hoc and I think we can ignore them or
replace them with proper bindings when converting the drivers to
device-tree based probing.

	Arnd

How to handle named resources with DT?

[Paul Walmsley]

On Fri, 26 Aug 2011, David Gibson wrote:

> static struct of_device_id foodevice_of_match[] __devinitdata = {
> 	{ .compatible = "foocorp,foodevice1234",
> 	  .resource_names = {"base_regs", "extra_regs", }, },
> 	{ .compatible = "foocorp,foodevice1239",
> 	  .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
> 	{ },
> };

This preserves platform_device_get_byname(), which is good.  It also 
facilitates debugging: like naming resources in the device tree data, it 
provides something human-readable to output to /proc/iomem and similar 
mechanisms.

But it doesn't resolve the problem on the DT generation side.

When someone at a hardware vendor writes the DT generator code, they'll 
have to implement a similar table to yours for each IP block with multiple 
resources of the same type.

IP blocks with multiple resources of the same type are not isolated cases.  
For example, of the 82 IP block instances on the OMAP4 that have hwmod 
data currently upstream (a subset of what's actually on the chip), at 
least 68 of them (83%) have multiple resources of the same type[1][2].

Certainly, from a kernel development perspective, one can decide to just 
dump this kind of DT generation problem back on the hardware vendors.  
But it seems more efficient and less error-prone to simply remove both 
mapping tables, and to export names directly from the IP block data into 
the device data format.


- Paul

1. The number is actually higher than this.  This count doesn't
   include IP blocks with multiple address ranges on different 
   interconnects.

2. Data from arch/arm/mach-omap2/omap_hwmod_44xx_data.c, as of Linux 
   v3.1-rc3.
   Available from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod_44xx_data.c;h=6201422c0606b5103c01e563f67060134658774d;hb=HEAD

How to handle named resources with DT?

[Mark Brown]

On Sat, Aug 27, 2011 at 03:47:55PM -0600, Paul Walmsley wrote:

> Certainly, from a kernel development perspective, one can decide to just 
> dump this kind of DT generation problem back on the hardware vendors.  
> But it seems more efficient and less error-prone to simply remove both 
> mapping tables, and to export names directly from the IP block data into 
> the device data format.

That seems sensible, though we'd probably want to keep the option to
remap in there at least on the generation side in case some integrators
end up renaming the ports on the IP block for some reason.

How to handle named resources with DT?

[Cousson, Benoit]

On 8/26/2011 12:58 PM, Arnd Bergmann wrote:
> On Friday 26 August 2011, David Gibson wrote:
>> Seriously, how many times do I have to say it?

[...]

>> Insisting that the names come from the DT is to mistakenly think of
>> the DT as an extension of the kernel's internal interfaces, instead of
>> as the external and OS neutral data structure it actually is.

You are wrongly interpreting the consequence: a smart Linux guy added a 
_byname API, without seeing the real cause: most HW resources have a 
name to identify them and not a number.

> Agreed, that was my main point anyway: Getting the name from the
> device tree would be a huge mistake.

No, it would not. In fact, storing name in DT is even much more aligned 
with the goal of DT for my point of view, since it is supposed to 
describe the HW without any assumption about the OS usage. DT data are 
supposed to be driven by the HW specs.


The ordering you are relying on for the moment is purely arbitrary and 
do not have any signification for the HW point of view. Just have a look 
at a HW spec and you will see that most signals have a *name*, not a 
number, to identify them.

Without that, you have to add some unnecessary and error prone 
processing to the original information:
- Encode an information that is there originally (resource name from the 
HW spec) into a arbitrary number without any meaning: Why tx_irq should 
be before the rx_irq and after the err_irq???
- Remove the original name to confuse people.
- Expect the driver to use a number that does not come from the HW spec 
but from a DT binding text file to figure out what resource it has to use.
- Pray that the driver guy didn't wrongly interpret the irq #2138469 to 
be the tx_irq instead of the rx_irq.

That's a lot of (error prone) indirections that can be avoided by using 
the name directly.


If you extend a little bit the scope of the discussion and start 
considering that clocks, voltage rails, reset lines are as well a 
resources for the IP point of view, do you really think that using a 
number to identify a clock or a voltage will really make sense?
Guess what? The current clock binding is using clock name...

In order to have a consistent way of using resources in DT, it makes 
sense to have the ability to provide a name for any kind of resources.
BTW, adding a name should not prevent people to use the legacy by index 
method.


Moreover, anybody deserve to have a name... Otherwise we will end up 
with situation like that:

resource #6: Who are you?
resource #2: The new #2.
resource #6: Who is #1?
resource #2: You are #6.
resource #6: I am not a number, I am a free resource.


Regards,
Benoit

How to handle named resources with DT?

[David Gibson]

On Fri, Aug 26, 2011 at 04:13:15PM +0200, Cousson, Benoit wrote:
> On 8/26/2011 12:58 PM, Arnd Bergmann wrote:
> >On Friday 26 August 2011, David Gibson wrote:
> >>Seriously, how many times do I have to say it?
> 
> [...]
> 
> >>Insisting that the names come from the DT is to mistakenly think of
> >>the DT as an extension of the kernel's internal interfaces, instead of
> >>as the external and OS neutral data structure it actually is.
> 
> You are wrongly interpreting the consequence: a smart Linux guy
> added a _byname API, without seeing the real cause: most HW
> resources have a name to identify them and not a number.

No, I'm really not.

> >Agreed, that was my main point anyway: Getting the name from the
> >device tree would be a huge mistake.
> 
> No, it would not. In fact, storing name in DT is even much more
> aligned with the goal of DT for my point of view, since it is
> supposed to describe the HW without any assumption about the OS
> usage. DT data are supposed to be driven by the HW specs.

So, I actually agree that in the long term getting resource names in
the DT would be a generally good thing.

But doing so is a *huge* change in one of the very core semantics of
all the DT bindings.  It's not something that should be done lightly
or quickly.  It absolutely should not be tied to how this is handled
on the Linux side.  Therefore *for now* it is much better to have glue
which binds existing DT practice to the new Linux interface; then
thinking about this from the DT point of view can be a long term
project.

> The ordering you are relying on for the moment is purely arbitrary
> and do not have any signification for the HW point of view. Just
> have a look at a HW spec and you will see that most signals have a
> *name*, not a number, to identify them.

Sure, but assigning that arbitrary order is well-established practice
for device DT bindings.

> Without that, you have to add some unnecessary and error prone
> processing to the original information:
> - Encode an information that is there originally (resource name from
> the HW spec) into a arbitrary number without any meaning: Why tx_irq
> should be before the rx_irq and after the err_irq???
> - Remove the original name to confuse people.
> - Expect the driver to use a number that does not come from the HW
> spec but from a DT binding text file to figure out what resource it
> has to use.

No, I don't expect that bit - see the discussion of how we can glue
the DT order to names inside the kernel.

> - Pray that the driver guy didn't wrongly interpret the irq #2138469
> to be the tx_irq instead of the rx_irq.

Um, this is an order, not an arbitrary int number.  So try irq #2.
Maybe #3 or #4 on a really complicated device.

> If you extend a little bit the scope of the discussion and start
> considering that clocks, voltage rails, reset lines are as well a
> resources for the IP point of view, do you really think that using a
> number to identify a clock or a voltage will really make sense?
> Guess what? The current clock binding is using clock name...

Yes.  There's a big difference between creating a new binding to use
names, and creating a new practice in the core DT semantics used by
every single existing binding.

> In order to have a consistent way of using resources in DT, it makes
> sense to have the ability to provide a name for any kind of
> resources.
> BTW, adding a name should not prevent people to use the legacy by
> index method.
> 
> 
> Moreover, anybody deserve to have a name... Otherwise we will end up
> with situation like that:
> 
> resource #6: Who are you?
> resource #2: The new #2.
> resource #6: Who is #1?
> resource #2: You are #6.
> resource #6: I am not a number, I am a free resource.

Allusions to TV programs do not an argument make, no matter how
interesting and influential they might have been.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Felipe Balbi]

Hi,

On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote:
> So, I actually agree that in the long term getting resource names in
> the DT would be a generally good thing.
> 
> But doing so is a *huge* change in one of the very core semantics of
> all the DT bindings.  It's not something that should be done lightly
> or quickly.  It absolutely should not be tied to how this is handled

the longer you take to change, the more complex will it be to change.
The longer we spend discussing the validity of _byname(), more
boards/archs/whatnot will be converted to DT without _byname() and after
a certain amount of them are converted, noone will be willing to change
and validate everything again.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110830/7f00a399/attachment.sig>

How to handle named resources with DT?

[David Gibson]

On Tue, Aug 30, 2011 at 12:27:24PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote:
> > So, I actually agree that in the long term getting resource names in
> > the DT would be a generally good thing.
> > 
> > But doing so is a *huge* change in one of the very core semantics of
> > all the DT bindings.  It's not something that should be done lightly
> > or quickly.  It absolutely should not be tied to how this is handled
> 
> the longer you take to change, the more complex will it be to
> change.

No, not really.

> The longer we spend discussing the validity of _byname(), more
> boards/archs/whatnot will be converted to DT without _byname() and after
> a certain amount of them are converted, noone will be willing to change
> and validate everything again.

I'm not discussing the validity of _byname (Russell King is, but
that's not an argument I have a position of).  What I'm saying is that
the kernel internal use of byname, and named resources in the DT are
different things which should be approached independently.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110831/04e80fbe/attachment.sig>

How to handle named resources with DT?

[Paul Walmsley]

On Fri, 26 Aug 2011, Arnd Bergmann wrote:

> I don't think anyone was talking about converting driver /to/ the
> _byname method

For drivers that use multiple resources of the same type, converting those 
to use platform_get_resource_byname() does indeed seem appropriate.

By the way, the same IP block design can exist on platforms with different 
device data formats.  For example, the PowerVR SGX core[1] is present on 
many ARM SoCs and on Intel Poulsbo designs.  The Poulsbo systems are 
presumably using ACPI/SFI *SDT tables.  So it seems unwise to couple 
drivers to any specific external device data format.


- Paul

1. One example: http://en.wikipedia.org/wiki/PowerVR#Series5_.28SGX.29

How to handle named resources with DT?

[Cousson, Benoit]

On 8/25/2011 12:28 PM, Russell King - ARM Linux wrote:
> On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
>> on top of all that, for IPs which are used on many SoCs (such as MUSB)
>> it's quite silly to force all users to provide resources in a certain
>> order. It sounds to me that this will be prone to error in many ways
>> until everything is synced up and on the correct order.
>>
>> Ditching _byname is a very bad idea.
>
> I continue to disagree.  The current _byname is an abonimation and hack
> to try to "fix" this problem.

What problem are you considering here?

> _byname should have been implemented differently - rather than overriding
> the resources name field (which is _normally_ specified to be the device
> or driver name), a new field should have been introduced in struct resource
> to carry the resource sub-name (which is really what it is.)

I guess we agree on that, but that just means that the implementation is 
bad, not that the function is useless or evil.

> That would have avoided making /proc/iomem completely illegible with
> multiple devices using this feature.

resources are used as well for irq and dma, so that aspect is irrelevant 
in that case.

Assuming that a new field is added to keep the original semantic ot the 
name, will you be happy with the _byname API?

Benoit

How to handle named resources with DT?

[Scott Wood]

On 08/09/2011 04:44 PM, Cousson, Benoit wrote:
> OK, so what about extending the reg attribute to be a reg node?
> 
> dev {
>     reg {
>         name = "foo_wrapper";
>         start = <0x10000>;
>         end = <0x200>;
>     }
>     reg {
>         name = "foo";
>         start = <0x20000>;
>         end = <0x200>;
>     }
> }
> 
> A little bit more verbose, but at least we can add any attribute we want.

A more standard way to do that would be something like:

dev {
	#address-cells = <1>;
	#size-cells = <1>;
	ranges;

	foo {
		reg = <0x10000 0x200>;
	};
	bar {
		reg = <0x20000 0x200>;
	};
};

...which is OK if you need the expressiveness of a full hierarchy (and
don't have some other meaning for child nodes of "dev"), but it seems
like it would be overkill for some places where named resources would be
useful.

-Scott

How to handle named resources with DT?

[Grant Likely]

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.

g.

How to handle named resources with DT?

[Cousson, Benoit]

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.

Regards,
Benoit

How to handle named resources with DT?

[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.

How to handle named resources with DT?

[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.
>

How to handle named resources with DT?

[Shawn Guo]

On Tue, Aug 09, 2011 at 11:37:10PM +0200, Cousson, Benoit wrote:
> 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.
> >
It is definitely useful for other platforms, so please add the support
in DT core.

> >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.
> 
When it comes out, I will happily test it on imx :)

> 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:-)
> 

I had a conversation with Arnd as below.  Arnd has the concern on
multiple dma controllers.  So it is a question if we need to handle
multiple dma controllers like we do for multiple irq controllers.

--- quote ---
Shawn Guo:
> Then like that IRQ number is decoded and populated into IORESOURCE_IRQ
> by device tree infrastructural code, we can also do the same into
> IORESOURCE_DMA.  In that case, drivers do not need any code change for
> getting dma channel/event numbers from device tree, as
> platform_get_resource(pdev, IORESOURCE_DMA) still works for them.

Arnd Bergmann:
But I really don't think there is value in using IORESOURCE_DMA for this.
We don't have the code to manage DMA resources for more than one DMA
controller AFAICT, and I think we should not add it. Globally
unique interrupt numbers cause us a lot of trouble and we go to great
lengths to fake them on modern devices. It would be much better
not to have them visible in the OS, and I don't want to add them to
a modern API like the dmaengine.
---

Regards,
Shawn

How to handle named resources with DT?

[Cousson, Benoit]

On 8/12/2011 6:10 AM, Shawn Guo wrote:
> On Tue, Aug 09, 2011 at 11:37:10PM +0200, Cousson, Benoit wrote:
>> 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.
>>>
> It is definitely useful for other platforms, so please add the support
> in DT core.

Well, I still have to solve the resource_byname issue for IRQ and REG 
first :-)

>>> 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.
>>
> When it comes out, I will happily test it on imx :)

Now, you are putting a lot of pressure on my shoulders :-)

We are still missing basic DT support for OMAP4 and just started the 
OMAP3 beagleboard, so it will take some time before facing the DMA 
issue. But it will happen, probably sooner than later.

>
>> 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:-)
>>
>
> I had a conversation with Arnd as below.  Arnd has the concern on
> multiple dma controllers.  So it is a question if we need to handle
> multiple dma controllers like we do for multiple irq controllers.

Quite, interesting, I cannot find the thread, did you discuss that on 
linaro-dev, lakml?

> --- quote ---
> Shawn Guo:
>> Then like that IRQ number is decoded and populated into IORESOURCE_IRQ
>> by device tree infrastructural code, we can also do the same into
>> IORESOURCE_DMA.  In that case, drivers do not need any code change for
>> getting dma channel/event numbers from device tree, as
>> platform_get_resource(pdev, IORESOURCE_DMA) still works for them.
>
> Arnd Bergmann:
> But I really don't think there is value in using IORESOURCE_DMA for this.
> We don't have the code to manage DMA resources for more than one DMA
> controller AFAICT, and I think we should not add it. Globally
> unique interrupt numbers cause us a lot of trouble and we go to great
> lengths to fake them on modern devices.

Yeah, that totally makes sense. We do have several DMA engines in OMAP 
anyway, so unique number is clearly not the best approach.
But in that case, it means adding a new kernel API for that and not only 
an of_XXX one. Because driver should then rely on it with or without DT.

> It would be much better
> not to have them visible in the OS, and I don't want to add them to
> a modern API like the dmaengine.

That part is less clear to me, what does it means?

Regards,
Benoit

How to handle named resources with DT?

[Shawn Guo]

On Fri, Aug 12, 2011 at 10:56:13AM +0200, Cousson, Benoit wrote:
[...]
> >>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:-)
> >>
> >
> >I had a conversation with Arnd as below.  Arnd has the concern on
> >multiple dma controllers.  So it is a question if we need to handle
> >multiple dma controllers like we do for multiple irq controllers.
> 
> Quite, interesting, I cannot find the thread, did you discuss that
> on linaro-dev, lakml?
> 
http://thread.gmane.org/gmane.linux.drivers.devicetree/6587

-- 
Regards,
Shawn

How to handle named resources with DT?

[Arnd Bergmann]

On Friday 12 August 2011, Cousson, Benoit wrote:
> > Arnd Bergmann:
> > But I really don't think there is value in using IORESOURCE_DMA for this.
> > We don't have the code to manage DMA resources for more than one DMA
> > controller AFAICT, and I think we should not add it. Globally
> > unique interrupt numbers cause us a lot of trouble and we go to great
> > lengths to fake them on modern devices.
> 
> Yeah, that totally makes sense. We do have several DMA engines in OMAP 
> anyway, so unique number is clearly not the best approach.
> But in that case, it means adding a new kernel API for that and not only 
> an of_XXX one. Because driver should then rely on it with or without DT.
> 
> > It would be much better
> > not to have them visible in the OS, and I don't want to add them to
> > a modern API like the dmaengine.
> 
> That part is less clear to me, what does it means?
> 

I mean you can have DMA channel numbers visible in the device
tree, relative to a 'parent' dma controller, but I would not
expose them as numbers on a device driver interface. Instead,
I think the interface we provide to the device driver is one
where we pass the device using the DMA channel into a generic
dmaengine API and let that figure out where it's connected
in order to return a struct dma_chan pointer.

	ARnd

How to handle named resources with DT?

[David Gibson]

On Tue, Aug 09, 2011 at 11:23:45AM -0600, 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.

Well, the driver proper shouldn't need changing.  It should be
possible to assign the correct names in the glue which translates the
DT reg entries into the Linux resource structures.

The difficulty with adding th enames to the DT itself is that it
exposes the essentially Linux-specific names in what's supposed to be
an OS neutral data structure.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

How to handle named resources with DT?

[Paul Walmsley]

On Wed, 10 Aug 2011, David Gibson wrote:

> The difficulty with adding th enames to the DT itself is that it
> exposes the essentially Linux-specific names in what's supposed to be
> an OS neutral data structure.

The names are supposed to pertain to the hardware IP block, not the OS.  
See for example [1] and [2].  

If there's something OS-specific about the names, then the data isn't 
right.


- Paul

1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod_44xx_data.c;h=6201422c0606b5103c01e563f67060134658774d;hb=322a8b034003c0d46d39af85bf24fee27b902f48#l2359

2. Table 23-13 "HS I?C DMA Requests", OMAP4430 TRM version V 
   (SWPU231V), available from 
   http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vV.zip 

How to handle named resources with DT?

[Russell King - ARM Linux]

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.
>
> Do you have any plan to add that, or do you have any clean way to avoid  
> that without having to use the resource index?

Named resources are evil.  You only have to look at /proc/iomem to see
why that's the case.  Here's an example:

b7a01000-b7a01003 : set
  b7a01000-b7a01003 : set
b7a01004-b7a01007 : dat
  b7a01004-b7a01007 : dat
b7a01008-b7a0100b : dirout
  b7a01008-b7a0100b : dirout
b7a01020-b7a01023 : set
  b7a01020-b7a01023 : set
b7a01024-b7a01027 : dat
  b7a01024-b7a01027 : dat
b7a01028-b7a0102b : dirout
  b7a01028-b7a0102b : dirout
b7a01040-b7a01043 : set
  b7a01040-b7a01043 : set
b7a01044-b7a01047 : dat
  b7a01044-b7a01047 : dat
b7a01048-b7a0104b : dirout
  b7a01048-b7a0104b : dirout
b7a01060-b7a01063 : set
  b7a01060-b7a01063 : set
b7a01064-b7a01067 : dat
  b7a01064-b7a01067 : dat
b7a01068-b7a0106b : dirout
  b7a01068-b7a0106b : dirout
b7a01080-b7a01083 : set
  b7a01080-b7a01083 : set
b7a01084-b7a01087 : dat
  b7a01084-b7a01087 : dat
b7a01088-b7a0108b : dirout
  b7a01088-b7a0108b : dirout

How very informative.  Not.  So what device owns those?  Who knows,
that's lost by the crappy named resource stuff.

How to handle named resources with DT?

[Cousson, Benoit]

On 8/9/2011 9:51 PM, Russell King - ARM Linux wrote:
> 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.
>>
>> Do you have any plan to add that, or do you have any clean way to avoid
>> that without having to use the resource index?
>
> Named resources are evil.  You only have to look at /proc/iomem to see
> why that's the case.  Here's an example:
>
> b7a01000-b7a01003 : set
>    b7a01000-b7a01003 : set

So what? That just shows that /proc/iomem outputs sucks, but that does 
not prove that named resources are evil.

[...]

> How very informative.  Not.  So what device owns those?  Who knows,
> that's lost by the crappy named resource stuff.

Maybe, but this is not lost by the platform_device, and this is what 
really matters in this case.
We need to get the resource local to a device, we do not care about the 
global view. This is exactly what the platform_get_resource_byname is doing.
For my point of view, the need for that is similar to the clkdev / 
clk_get(dev, name) you did. For sure, in that case, the real global 
clock name is still relevant, but the important point for the driver is 
the local device name.

Not providing the name of the resource will give you the device name, 
but how informative is that for the driver? What entry is the good one 
in the middle of that list?

b7a01040-b7a01043 : omap_foo
b7a01044-b7a01047 : omap_foo
b7a01048-b7a0104b : omap_foo
b7a01060-b7a01063 : omap_foo

Bottom-line, in both cases, /proc/iomem sucks... But who cares about the 
internal representation? A platform_driver can still take advantage of 
that, and this is exactly what we are looking for.

Benoit