* How to handle named resources with DT?
@ 2011-08-09 9:23 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 9:23 UTC (permalink / raw)
To: Grant Likely
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 9:23 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 9:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 9:23 ` Cousson, Benoit
@ 2011-08-09 16:29 ` G, Manjunath Kondaiah
-1 siblings, 0 replies; 141+ messages in thread
From: G, Manjunath Kondaiah @ 2011-08-09 16:29 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, devicetree-discuss,
Nayak, Rajendra, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 16:29 ` G, Manjunath Kondaiah
0 siblings, 0 replies; 141+ messages in thread
From: G, Manjunath Kondaiah @ 2011-08-09 16:29 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 16:29 ` G, Manjunath Kondaiah
@ 2011-08-09 16:57 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 16:57 UTC (permalink / raw)
To: G, Manjunath Kondaiah
Cc: Hilman, Kevin, Paul Walmsley, devicetree-discuss, Nayak,
Rajendra, Grant Likely, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 16:57 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 16:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 16:57 ` Cousson, Benoit
@ 2011-08-09 17:23 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 17:23 UTC (permalink / raw)
To: Cousson, Benoit
Cc: G, Manjunath Kondaiah, Hilman, Kevin, Paul Walmsley,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 17:23 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 17:23 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 17:23 ` Grant Likely
@ 2011-08-09 17:47 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 17:47 UTC (permalink / raw)
To: Grant Likely
Cc: G, Manjunath Kondaiah, Hilman, Kevin, Paul Walmsley,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 17:47 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 17:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 17:47 ` Cousson, Benoit
@ 2011-08-09 17:52 ` Matt Porter
-1 siblings, 0 replies; 141+ messages in thread
From: Matt Porter @ 2011-08-09 17:52 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Nayak, Rajendra, Grant Likely, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 17:52 ` Matt Porter
0 siblings, 0 replies; 141+ messages in thread
From: Matt Porter @ 2011-08-09 17:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 17:47 ` Cousson, Benoit
@ 2011-08-09 18:26 ` Scott Wood
-1 siblings, 0 replies; 141+ messages in thread
From: Scott Wood @ 2011-08-09 18:26 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 18:26 ` Scott Wood
0 siblings, 0 replies; 141+ messages in thread
From: Scott Wood @ 2011-08-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 9:23 ` Cousson, Benoit
@ 2011-08-09 19:51 ` Russell King - ARM Linux
-1 siblings, 0 replies; 141+ messages in thread
From: Russell King - ARM Linux @ 2011-08-09 19:51 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Nayak, Rajendra,
linux-omap, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 19:51 ` Russell King - ARM Linux
0 siblings, 0 replies; 141+ messages in thread
From: Russell King - ARM Linux @ 2011-08-09 19:51 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 17:47 ` Cousson, Benoit
@ 2011-08-09 20:55 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 20:55 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 20:55 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 18:26 ` Scott Wood
@ 2011-08-09 20:57 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 20:57 UTC (permalink / raw)
To: Scott Wood
Cc: Cousson, Benoit, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, linux-omap,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 20:57 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 20:57 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 19:51 ` Russell King - ARM Linux
@ 2011-08-09 20:59 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 20:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Nayak, Rajendra,
linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 20:59 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 20:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 20:55 ` Grant Likely
@ 2011-08-09 21:06 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:06 UTC (permalink / raw)
To: Grant Likely
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:06 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:06 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 20:57 ` Grant Likely
@ 2011-08-09 21:08 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:08 UTC (permalink / raw)
To: Grant Likely
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Scott Wood,
linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:08 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:06 ` Cousson, Benoit
@ 2011-08-09 21:16 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 21:16 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:16 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 21:16 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:08 ` Cousson, Benoit
@ 2011-08-09 21:17 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 21:17 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Scott Wood, Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, linux-omap, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:17 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 21:17 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:16 ` Grant Likely
@ 2011-08-09 21:37 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:37 UTC (permalink / raw)
To: Grant Likely
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Nayak, Rajendra, linux-omap,
linux-arm-kernel
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.
>
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:37 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:37 UTC (permalink / raw)
To: linux-arm-kernel
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.
>
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:17 ` Grant Likely
@ 2011-08-09 21:44 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:44 UTC (permalink / raw)
To: Grant Likely
Cc: Scott Wood, Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:44 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:44 ` Cousson, Benoit
@ 2011-08-09 21:49 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 21:49 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Scott Wood, Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, linux-omap, linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:49 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-09 21:49 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:44 ` Cousson, Benoit
@ 2011-08-09 21:52 ` Scott Wood
-1 siblings, 0 replies; 141+ messages in thread
From: Scott Wood @ 2011-08-09 21:52 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:52 ` Scott Wood
0 siblings, 0 replies; 141+ messages in thread
From: Scott Wood @ 2011-08-09 21:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:49 ` Grant Likely
@ 2011-08-09 21:53 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:53 UTC (permalink / raw)
To: Grant Likely
Cc: Scott Wood, Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-09 21:53 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-09 21:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 17:23 ` Grant Likely
@ 2011-08-10 1:29 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-10 1:29 UTC (permalink / raw)
To: Grant Likely
Cc: Cousson, Benoit, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 1:29 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-10 1:29 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:53 ` Cousson, Benoit
@ 2011-08-10 1:52 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-10 1:52 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 1:52 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-10 1:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 1:29 ` David Gibson
@ 2011-08-10 6:08 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-10 6:08 UTC (permalink / raw)
To: David Gibson
Cc: Grant Likely, Cousson, Benoit, Hilman, Kevin, G,
Manjunath Kondaiah, devicetree-discuss, linux-omap,
linux-arm-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 800 bytes --]
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 6:08 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-10 6:08 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 1:52 ` David Gibson
@ 2011-08-10 7:11 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-10 7:11 UTC (permalink / raw)
To: David Gibson
Cc: Cousson, Benoit, Grant Likely, Hilman, Kevin, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 7:11 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-10 7:11 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 1:52 ` David Gibson
@ 2011-08-10 15:01 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-10 15:01 UTC (permalink / raw)
To: David Gibson
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Scott Wood,
linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 15:01 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-10 15:01 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 1:52 ` David Gibson
@ 2011-08-10 15:18 ` Scott Wood
-1 siblings, 0 replies; 141+ messages in thread
From: Scott Wood @ 2011-08-10 15:18 UTC (permalink / raw)
To: David Gibson
Cc: Cousson, Benoit, Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 15:18 ` Scott Wood
0 siblings, 0 replies; 141+ messages in thread
From: Scott Wood @ 2011-08-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 15:18 ` Scott Wood
@ 2011-08-10 15:21 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-10 15:21 UTC (permalink / raw)
To: Scott Wood
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 15:21 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-10 15:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 1:52 ` David Gibson
@ 2011-08-10 19:22 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-10 19:22 UTC (permalink / raw)
To: David Gibson
Cc: Cousson, Benoit, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 19:22 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-10 19:22 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 19:22 ` Grant Likely
@ 2011-08-10 19:57 ` David Brown
-1 siblings, 0 replies; 141+ messages in thread
From: David Brown @ 2011-08-10 19:57 UTC (permalink / raw)
To: Grant Likely
Cc: David Gibson, Hilman, Kevin, Paul Walmsley, Cousson, Benoit, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 19:57 ` David Brown
0 siblings, 0 replies; 141+ messages in thread
From: David Brown @ 2011-08-10 19:57 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 19:57 ` David Brown
@ 2011-08-10 20:12 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-10 20:12 UTC (permalink / raw)
To: David Brown
Cc: David Gibson, Hilman, Kevin, Paul Walmsley, Cousson, Benoit, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-10 20:12 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-10 20:12 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-10 19:22 ` Grant Likely
@ 2011-08-11 12:28 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-11 12:28 UTC (permalink / raw)
To: Grant Likely
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Balbi, Felipe, Scott Wood, linux-omap,
linux-arm-kernel, David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-11 12:28 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-11 12:28 ` Cousson, Benoit
@ 2011-08-12 3:02 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-12 3:02 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel, Balbi, Felipe
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 3:02 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-12 3:02 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-09 21:37 ` Cousson, Benoit
@ 2011-08-12 4:10 ` Shawn Guo
-1 siblings, 0 replies; 141+ messages in thread
From: Shawn Guo @ 2011-08-12 4:10 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Nayak, Rajendra,
linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 4:10 ` Shawn Guo
0 siblings, 0 replies; 141+ messages in thread
From: Shawn Guo @ 2011-08-12 4:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 3:02 ` David Gibson
@ 2011-08-12 8:14 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-12 8:14 UTC (permalink / raw)
To: David Gibson
Cc: Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Balbi, Felipe,
Scott Wood, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 8:14 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-12 8:14 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 3:02 ` David Gibson
@ 2011-08-12 8:41 ` Felipe Balbi
-1 siblings, 0 replies; 141+ messages in thread
From: Felipe Balbi @ 2011-08-12 8:41 UTC (permalink / raw)
To: David Gibson
Cc: Cousson, Benoit, Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap,
linux-arm-kernel, Balbi, Felipe
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 8:41 ` Felipe Balbi
0 siblings, 0 replies; 141+ messages in thread
From: Felipe Balbi @ 2011-08-12 8:41 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 4:10 ` Shawn Guo
@ 2011-08-12 8:56 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-12 8:56 UTC (permalink / raw)
To: Shawn Guo
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Nayak, Rajendra,
linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 8:56 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-12 8:56 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 8:56 ` Cousson, Benoit
@ 2011-08-12 11:47 ` Shawn Guo
-1 siblings, 0 replies; 141+ messages in thread
From: Shawn Guo @ 2011-08-12 11:47 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Grant Likely, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Nayak, Rajendra,
linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 11:47 ` Shawn Guo
0 siblings, 0 replies; 141+ messages in thread
From: Shawn Guo @ 2011-08-12 11:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 8:41 ` Felipe Balbi
@ 2011-08-12 14:35 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-12 14:35 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, balbi-l0cyMroinI0
Cc: Hilman, Kevin, Paul Walmsley, Cousson, Benoit, G,
Manjunath Kondaiah, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Scott Wood, linux-omap
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@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource | wc -l
565
arnd@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | wc -l
41
arnd@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | xargs grep -wL platform_get_resource | wc -l # both
28
arnd@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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 14:35 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-12 14:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 8:56 ` Cousson, Benoit
@ 2011-08-12 14:40 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-12 14:40 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Cousson, Benoit, Shawn Guo, Hilman, Kevin, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Nayak, Rajendra,
Grant Likely, linux-omap
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 14:40 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-12 14:40 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 14:35 ` Arnd Bergmann
@ 2011-08-12 15:09 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-12 15:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Balbi, Felipe, David Gibson, Hilman, Kevin,
Paul Walmsley, G, Manjunath Kondaiah, devicetree-discuss,
Grant Likely, Scott Wood, linux-omap
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@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource | wc -l
> 565
> arnd@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | wc -l
> 41
> arnd@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | xargs grep -wL platform_get_resource | wc -l # both
> 28
> arnd@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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 15:09 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 15:09 ` Cousson, Benoit
@ 2011-08-12 17:21 ` Grant Likely
-1 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-12 17:21 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Arnd Bergmann, linux-arm-kernel, Balbi, Felipe, David Gibson,
Hilman, Kevin, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Scott Wood, linux-omap
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@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource | wc -l
>> 565
>> arnd@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname | wc
>> -l
>> 41
>> arnd@ocdc-kvm:~/linux-arm$ git grep -wl platform_get_resource_byname |
>> xargs grep -wL platform_get_resource | wc -l # both
>> 28
>> arnd@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-12 17:21 ` Grant Likely
0 siblings, 0 replies; 141+ messages in thread
From: Grant Likely @ 2011-08-12 17:21 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-12 17:21 ` Grant Likely
@ 2011-08-24 19:15 ` Kevin Hilman
-1 siblings, 0 replies; 141+ messages in thread
From: Kevin Hilman @ 2011-08-24 19:15 UTC (permalink / raw)
To: Grant Likely
Cc: Cousson, Benoit, Arnd Bergmann, linux-arm-kernel, Balbi, Felipe,
David Gibson, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss, Scott Wood, linux-omap
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-24 19:15 ` Kevin Hilman
0 siblings, 0 replies; 141+ messages in thread
From: Kevin Hilman @ 2011-08-24 19:15 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-24 19:15 ` Kevin Hilman
@ 2011-08-24 23:16 ` Felipe Balbi
-1 siblings, 0 replies; 141+ messages in thread
From: Felipe Balbi @ 2011-08-24 23:16 UTC (permalink / raw)
To: Kevin Hilman
Cc: Grant Likely, Cousson, Benoit, Arnd Bergmann, linux-arm-kernel,
Balbi, Felipe, David Gibson, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Scott Wood, linux-omap
[-- Attachment #1: Type: text/plain, Size: 4329 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-24 23:16 ` Felipe Balbi
0 siblings, 0 replies; 141+ messages in thread
From: Felipe Balbi @ 2011-08-24 23:16 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-24 23:16 ` Felipe Balbi
@ 2011-08-25 10:28 ` Russell King - ARM Linux
-1 siblings, 0 replies; 141+ messages in thread
From: Russell King - ARM Linux @ 2011-08-25 10:28 UTC (permalink / raw)
To: Felipe Balbi
Cc: Kevin Hilman, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Scott Wood,
linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-25 10:28 ` Russell King - ARM Linux
0 siblings, 0 replies; 141+ messages in thread
From: Russell King - ARM Linux @ 2011-08-25 10:28 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-25 10:28 ` Russell King - ARM Linux
@ 2011-08-25 15:05 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-25 15:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Kevin Hilman, Paul Walmsley, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Felipe Balbi,
Scott Wood, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-25 15:05 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-25 15:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-25 10:28 ` Russell King - ARM Linux
@ 2011-08-25 17:38 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-25 17:38 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Balbi, Felipe, Hilman, Kevin, Paul Walmsley, Arnd Bergmann, G,
Manjunath Kondaiah, devicetree-discuss, Grant Likely, Scott Wood,
linux-omap, linux-arm-kernel, David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-25 17:38 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-25 17:38 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-25 15:05 ` Arnd Bergmann
@ 2011-08-25 18:16 ` Kevin Hilman
-1 siblings, 0 replies; 141+ messages in thread
From: Kevin Hilman @ 2011-08-25 18:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Walmsley, Russell King - ARM Linux, Cousson, Benoit, G,
Manjunath Kondaiah, devicetree-discuss, Felipe Balbi,
Grant Likely, Scott Wood, linux-omap, linux-arm-kernel,
David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-25 18:16 ` Kevin Hilman
0 siblings, 0 replies; 141+ messages in thread
From: Kevin Hilman @ 2011-08-25 18:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-25 18:16 ` Kevin Hilman
@ 2011-08-25 21:02 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-25 21:02 UTC (permalink / raw)
To: Kevin Hilman
Cc: Russell King - ARM Linux, Felipe Balbi, Paul Walmsley, Cousson,
Benoit, G, Manjunath Kondaiah, devicetree-discuss, Grant Likely,
Scott Wood, linux-omap, linux-arm-kernel, David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-25 21:02 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-25 21:02 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-25 18:16 ` Kevin Hilman
@ 2011-08-26 4:12 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-26 4:12 UTC (permalink / raw)
To: Kevin Hilman
Cc: Arnd Bergmann, Russell King - ARM Linux, Felipe Balbi,
Paul Walmsley, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-26 4:12 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-26 4:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 4:12 ` David Gibson
@ 2011-08-26 10:58 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-26 10:58 UTC (permalink / raw)
To: David Gibson
Cc: Kevin Hilman, Paul Walmsley, Russell King - ARM Linux, G,
Manjunath Kondaiah, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Felipe Balbi, Scott Wood, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-26 10:58 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-26 10:58 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Removing platform_get_resource_byname() (was Re: How to handle named resources with DT?)
2011-08-25 21:02 ` Arnd Bergmann
(?)
@ 2011-08-26 11:01 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-26 11:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Hilman, Russell King - ARM Linux, Felipe Balbi, Cousson,
Benoit, G, Manjunath Kondaiah, devicetree-discuss, Grant Likely,
Scott Wood, linux-omap, linux-arm-kernel, David Gibson,
linux-kernel, Kumar Gala, Greg Kroah-Hartman
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Removing platform_get_resource_byname() (was Re: How to handle named resources with DT?)
@ 2011-08-26 11:01 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-26 11:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Hilman, Russell King - ARM Linux, Cousson, Benoit, G,
Manjunath Kondaiah, devicetree-discuss, Greg Kroah-Hartman,
linux-kernel, Felipe Balbi, Kumar Gala, Grant Likely, Scott Wood,
linux-omap, linux-arm-kernel, David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Removing platform_get_resource_byname() (was Re: How to handle named resources with DT?)
@ 2011-08-26 11:01 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-26 11:01 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 10:58 ` Arnd Bergmann
@ 2011-08-26 13:06 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-26 13:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Hilman, Russell King - ARM Linux, Felipe Balbi,
Paul Walmsley, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-26 13:06 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-26 13:06 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 10:58 ` Arnd Bergmann
@ 2011-08-26 14:13 ` Cousson, Benoit
-1 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-26 14:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Hilman, Kevin, Paul Walmsley, Russell King - ARM Linux, G,
Manjunath Kondaiah, devicetree-discuss, Balbi, Felipe,
Grant Likely, Scott Wood, linux-omap, linux-arm-kernel,
David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-26 14:13 ` Cousson, Benoit
0 siblings, 0 replies; 141+ messages in thread
From: Cousson, Benoit @ 2011-08-26 14:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 13:06 ` David Gibson
@ 2011-08-26 15:35 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-26 15:35 UTC (permalink / raw)
To: David Gibson
Cc: Kevin Hilman, Paul Walmsley, Russell King - ARM Linux, Cousson,
Benoit, G, Manjunath Kondaiah, devicetree-discuss, Felipe Balbi,
Grant Likely, Scott Wood, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-26 15:35 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-26 15:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 15:35 ` Arnd Bergmann
@ 2011-08-26 15:41 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-26 15:41 UTC (permalink / raw)
To: David Gibson
Cc: Kevin Hilman, Paul Walmsley, Russell King - ARM Linux, G,
Manjunath Kondaiah, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Felipe Balbi, Scott Wood, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-26 15:41 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-26 15:41 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 15:41 ` Arnd Bergmann
@ 2011-08-27 14:37 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-27 14:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Hilman, Russell King - ARM Linux, Felipe Balbi,
Paul Walmsley, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-27 14:37 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-27 14:37 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-27 14:37 ` David Gibson
@ 2011-08-27 18:13 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-27 18:13 UTC (permalink / raw)
To: David Gibson
Cc: Kevin Hilman, Paul Walmsley, Russell King - ARM Linux, Cousson,
Benoit, G, Manjunath Kondaiah, devicetree-discuss, Felipe Balbi,
Grant Likely, Scott Wood, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-27 18:13 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-27 18:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-27 18:13 ` Arnd Bergmann
@ 2011-08-27 19:31 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-27 19:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Gibson, Kevin Hilman, Russell King - ARM Linux,
Felipe Balbi, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
Sascha Hauer, Amit Kucheria, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-27 19:31 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 10:58 ` Arnd Bergmann
@ 2011-08-27 20:00 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-27 20:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Hilman, Russell King - ARM Linux, Cousson, Benoit, G,
Manjunath Kondaiah, devicetree-discuss, Felipe Balbi,
Grant Likely, Scott Wood, linux-omap, linux-arm-kernel,
David Gibson
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-27 20:00 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-27 20:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 13:06 ` David Gibson
@ 2011-08-27 21:47 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-27 21:47 UTC (permalink / raw)
To: David Gibson
Cc: Arnd Bergmann, Kevin Hilman, Russell King - ARM Linux,
Felipe Balbi, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-27 21:47 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-27 21:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-27 18:13 ` Arnd Bergmann
@ 2011-08-28 8:39 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-28 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Hilman, Russell King - ARM Linux, Felipe Balbi,
Paul Walmsley, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-28 8:39 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-28 8:39 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-28 8:39 ` David Gibson
@ 2011-08-28 23:06 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-28 23:06 UTC (permalink / raw)
To: David Gibson
Cc: Arnd Bergmann, Kevin Hilman, Russell King - ARM Linux,
Felipe Balbi, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-28 23:06 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-28 23:06 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-28 23:06 ` Paul Walmsley
@ 2011-08-28 23:43 ` Russell King - ARM Linux
-1 siblings, 0 replies; 141+ messages in thread
From: Russell King - ARM Linux @ 2011-08-28 23:43 UTC (permalink / raw)
To: Paul Walmsley
Cc: Kevin Hilman, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Felipe Balbi,
Scott Wood, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-28 23:43 ` Russell King - ARM Linux
0 siblings, 0 replies; 141+ messages in thread
From: Russell King - ARM Linux @ 2011-08-28 23:43 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-28 23:06 ` Paul Walmsley
@ 2011-08-29 1:57 ` Paul Walmsley
-1 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-29 1:57 UTC (permalink / raw)
To: David Gibson
Cc: Arnd Bergmann, Kevin Hilman, Russell King - ARM Linux,
Felipe Balbi, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-29 1:57 ` Paul Walmsley
0 siblings, 0 replies; 141+ messages in thread
From: Paul Walmsley @ 2011-08-29 1:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-27 19:31 ` Paul Walmsley
@ 2011-08-29 17:16 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-29 17:16 UTC (permalink / raw)
To: Paul Walmsley
Cc: David Gibson, Kevin Hilman, Russell King - ARM Linux,
Felipe Balbi, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
Sascha Hauer, Amit Kucheria, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-29 17:16 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-29 17:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-28 8:39 ` David Gibson
@ 2011-08-29 17:18 ` Arnd Bergmann
-1 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-29 17:18 UTC (permalink / raw)
To: David Gibson
Cc: Kevin Hilman, Russell King - ARM Linux, Felipe Balbi,
Paul Walmsley, Cousson, Benoit, G, Manjunath Kondaiah,
devicetree-discuss, Grant Likely, Scott Wood, linux-omap,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-29 17:18 ` Arnd Bergmann
0 siblings, 0 replies; 141+ messages in thread
From: Arnd Bergmann @ 2011-08-29 17:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-27 21:47 ` Paul Walmsley
@ 2011-08-29 21:54 ` Mark Brown
-1 siblings, 0 replies; 141+ messages in thread
From: Mark Brown @ 2011-08-29 21:54 UTC (permalink / raw)
To: Paul Walmsley
Cc: Russell King - ARM Linux, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Felipe Balbi,
Scott Wood, linux-omap,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-29 21:54 ` Mark Brown
0 siblings, 0 replies; 141+ messages in thread
From: Mark Brown @ 2011-08-29 21:54 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-26 14:13 ` Cousson, Benoit
@ 2011-08-30 2:29 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-30 2:29 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Arnd Bergmann, Hilman, Kevin, Russell King - ARM Linux, Balbi,
Felipe, Paul Walmsley, G, Manjunath Kondaiah, devicetree-discuss,
Grant Likely, Scott Wood, linux-omap, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-30 2:29 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-30 2:29 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-30 2:29 ` David Gibson
@ 2011-08-30 9:27 ` Felipe Balbi
-1 siblings, 0 replies; 141+ messages in thread
From: Felipe Balbi @ 2011-08-30 9:27 UTC (permalink / raw)
To: David Gibson
Cc: Cousson, Benoit, Arnd Bergmann, Hilman, Kevin,
Russell King - ARM Linux, Balbi, Felipe, Paul Walmsley, G,
Manjunath Kondaiah, devicetree-discuss, Grant Likely, Scott Wood,
linux-omap, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-30 9:27 ` Felipe Balbi
0 siblings, 0 replies; 141+ messages in thread
From: Felipe Balbi @ 2011-08-30 9:27 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 141+ messages in thread
* Re: How to handle named resources with DT?
2011-08-30 9:27 ` Felipe Balbi
@ 2011-08-31 2:32 ` David Gibson
-1 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-31 2:32 UTC (permalink / raw)
To: Felipe Balbi
Cc: Russell King - ARM Linux, G, Manjunath Kondaiah,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Scott Wood,
linux-omap, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1.1: Type: text/plain, Size: 1304 bytes --]
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
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply [flat|nested] 141+ messages in thread
* How to handle named resources with DT?
@ 2011-08-31 2:32 ` David Gibson
0 siblings, 0 replies; 141+ messages in thread
From: David Gibson @ 2011-08-31 2:32 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 141+ messages in thread
end of thread, other threads:[~2011-08-31 2:32 UTC | newest]
Thread overview: 141+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-09 9:23 How to handle named resources with DT? Cousson, Benoit
2011-08-09 9:23 ` Cousson, Benoit
2011-08-09 16:29 ` G, Manjunath Kondaiah
2011-08-09 16:29 ` G, Manjunath Kondaiah
2011-08-09 16:57 ` Cousson, Benoit
2011-08-09 16:57 ` Cousson, Benoit
2011-08-09 17:23 ` Grant Likely
2011-08-09 17:23 ` Grant Likely
2011-08-09 17:47 ` Cousson, Benoit
2011-08-09 17:47 ` Cousson, Benoit
2011-08-09 17:52 ` Matt Porter
2011-08-09 17:52 ` Matt Porter
2011-08-09 18:26 ` Scott Wood
2011-08-09 18:26 ` Scott Wood
2011-08-09 20:57 ` Grant Likely
2011-08-09 20:57 ` Grant Likely
[not found] ` <20110809205723.GE11568-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-08-09 21:08 ` Cousson, Benoit
2011-08-09 21:08 ` Cousson, Benoit
2011-08-09 21:17 ` Grant Likely
2011-08-09 21:17 ` Grant Likely
2011-08-09 21:44 ` Cousson, Benoit
2011-08-09 21:44 ` Cousson, Benoit
2011-08-09 21:49 ` Grant Likely
2011-08-09 21:49 ` Grant Likely
2011-08-09 21:53 ` Cousson, Benoit
2011-08-09 21:53 ` Cousson, Benoit
2011-08-10 1:52 ` David Gibson
2011-08-10 1:52 ` David Gibson
2011-08-10 7:11 ` Paul Walmsley
2011-08-10 7:11 ` Paul Walmsley
[not found] ` <20110810015214.GD23511-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2011-08-10 15:01 ` Cousson, Benoit
2011-08-10 15:01 ` Cousson, Benoit
2011-08-10 15:18 ` Scott Wood
2011-08-10 15:18 ` Scott Wood
[not found] ` <4E42A14B.9050308-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2011-08-10 15:21 ` Cousson, Benoit
2011-08-10 15:21 ` Cousson, Benoit
2011-08-10 19:22 ` Grant Likely
2011-08-10 19:22 ` Grant Likely
2011-08-10 19:57 ` David Brown
2011-08-10 19:57 ` David Brown
2011-08-10 20:12 ` Grant Likely
2011-08-10 20:12 ` Grant Likely
2011-08-11 12:28 ` Cousson, Benoit
2011-08-11 12:28 ` Cousson, Benoit
2011-08-12 3:02 ` David Gibson
2011-08-12 3:02 ` David Gibson
[not found] ` <20110812030218.GP30552-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2011-08-12 8:14 ` Cousson, Benoit
2011-08-12 8:14 ` Cousson, Benoit
2011-08-12 8:41 ` Felipe Balbi
2011-08-12 8:41 ` Felipe Balbi
[not found] ` <20110812084106.GC19467-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2011-08-12 14:35 ` Arnd Bergmann
2011-08-12 14:35 ` Arnd Bergmann
2011-08-12 15:09 ` Cousson, Benoit
2011-08-12 15:09 ` Cousson, Benoit
2011-08-12 17:21 ` Grant Likely
2011-08-12 17:21 ` Grant Likely
2011-08-24 19:15 ` Kevin Hilman
2011-08-24 19:15 ` Kevin Hilman
2011-08-24 23:16 ` Felipe Balbi
2011-08-24 23:16 ` Felipe Balbi
[not found] ` <20110824231613.GC19890-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2011-08-25 10:28 ` Russell King - ARM Linux
2011-08-25 10:28 ` Russell King - ARM Linux
[not found] ` <20110825102824.GB10405-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-08-25 15:05 ` Arnd Bergmann
2011-08-25 15:05 ` Arnd Bergmann
2011-08-25 18:16 ` Kevin Hilman
2011-08-25 18:16 ` Kevin Hilman
2011-08-25 21:02 ` Arnd Bergmann
2011-08-25 21:02 ` Arnd Bergmann
2011-08-26 11:01 ` Removing platform_get_resource_byname() (was Re: How to handle named resources with DT?) Paul Walmsley
2011-08-26 11:01 ` Paul Walmsley
2011-08-26 11:01 ` Paul Walmsley
2011-08-26 4:12 ` How to handle named resources with DT? David Gibson
2011-08-26 4:12 ` David Gibson
[not found] ` <20110826041200.GD2308-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2011-08-26 10:58 ` Arnd Bergmann
2011-08-26 10:58 ` Arnd Bergmann
2011-08-26 13:06 ` David Gibson
2011-08-26 13:06 ` David Gibson
2011-08-26 15:35 ` Arnd Bergmann
2011-08-26 15:35 ` Arnd Bergmann
[not found] ` <201108261735.55412.arnd-r2nGTMty4D4@public.gmane.org>
2011-08-26 15:41 ` Arnd Bergmann
2011-08-26 15:41 ` Arnd Bergmann
2011-08-27 14:37 ` David Gibson
2011-08-27 14:37 ` David Gibson
2011-08-27 18:13 ` Arnd Bergmann
2011-08-27 18:13 ` Arnd Bergmann
2011-08-27 19:31 ` Paul Walmsley
2011-08-27 19:31 ` Paul Walmsley
2011-08-29 17:16 ` Arnd Bergmann
2011-08-29 17:16 ` Arnd Bergmann
2011-08-28 8:39 ` David Gibson
2011-08-28 8:39 ` David Gibson
2011-08-28 23:06 ` Paul Walmsley
2011-08-28 23:06 ` Paul Walmsley
[not found] ` <alpine.DEB.2.00.1108281100150.23968-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2011-08-28 23:43 ` Russell King - ARM Linux
2011-08-28 23:43 ` Russell King - ARM Linux
2011-08-29 1:57 ` Paul Walmsley
2011-08-29 1:57 ` Paul Walmsley
2011-08-29 17:18 ` Arnd Bergmann
2011-08-29 17:18 ` Arnd Bergmann
2011-08-27 21:47 ` Paul Walmsley
2011-08-27 21:47 ` Paul Walmsley
[not found] ` <alpine.DEB.2.00.1108271444240.23968-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2011-08-29 21:54 ` Mark Brown
2011-08-29 21:54 ` Mark Brown
2011-08-26 14:13 ` Cousson, Benoit
2011-08-26 14:13 ` Cousson, Benoit
2011-08-30 2:29 ` David Gibson
2011-08-30 2:29 ` David Gibson
2011-08-30 9:27 ` Felipe Balbi
2011-08-30 9:27 ` Felipe Balbi
[not found] ` <20110830092722.GG23907-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2011-08-31 2:32 ` David Gibson
2011-08-31 2:32 ` David Gibson
2011-08-27 20:00 ` Paul Walmsley
2011-08-27 20:00 ` Paul Walmsley
2011-08-25 17:38 ` Cousson, Benoit
2011-08-25 17:38 ` Cousson, Benoit
2011-08-09 21:52 ` Scott Wood
2011-08-09 21:52 ` Scott Wood
2011-08-09 20:55 ` Grant Likely
2011-08-09 20:55 ` Grant Likely
2011-08-09 21:06 ` Cousson, Benoit
2011-08-09 21:06 ` Cousson, Benoit
2011-08-09 21:16 ` Grant Likely
2011-08-09 21:16 ` Grant Likely
2011-08-09 21:37 ` Cousson, Benoit
2011-08-09 21:37 ` Cousson, Benoit
2011-08-12 4:10 ` Shawn Guo
2011-08-12 4:10 ` Shawn Guo
2011-08-12 8:56 ` Cousson, Benoit
2011-08-12 8:56 ` Cousson, Benoit
2011-08-12 11:47 ` Shawn Guo
2011-08-12 11:47 ` Shawn Guo
2011-08-12 14:40 ` Arnd Bergmann
2011-08-12 14:40 ` Arnd Bergmann
2011-08-10 1:29 ` David Gibson
2011-08-10 1:29 ` David Gibson
2011-08-10 6:08 ` Paul Walmsley
2011-08-10 6:08 ` Paul Walmsley
2011-08-09 19:51 ` Russell King - ARM Linux
2011-08-09 19:51 ` Russell King - ARM Linux
2011-08-09 20:59 ` Cousson, Benoit
2011-08-09 20:59 ` Cousson, Benoit
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.