ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Subsystems (3)
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
If the module requires only one clocksource to function, then driver can very well call clk_get() api with "con_id = NULL",
clk = clk_get(dev, NULL);
And platform code should respect this and return valid clk handle. That means, now the clk_get() api would rely on dev_id, and platform code should either have clk node with matching dev_id (with con_id=NULL) or return dummy clk node.
With DT support, we can fix the dev_id for particular module using "struct of_dev_auxdata" to satisfy above clk framework requirement.
In case of AM33XX, we required this for the DCAN module, so this patch adds "of_dev_auxdata" for both DCAN_0/1 instances.
---
This patch is boot tested on BeagleBone platform, and checked for clk_get() return value in d_can module driver.
arch/arm/mach-omap2/board-generic.c | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/board-generic.c +17 -1
@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } }; +/* +* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +}; +static void __init omap_generic_init (void ) {omap_sdrc_init (NULL ,NULL ); -of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); +if (of_machine_is_compatible ("ti,am33xx" )) +of_platform_populate (NULL , omap_dt_match_table, + am33xx_auxdata_lookup,NULL ); +else +of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); }#ifdef CONFIG_SOC_OMAP2420
--
1.7.0.4
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Quoted 37 lines · Vaibhav Hiremath
If the module requires only one clocksource to function, then driver can very well call
clk_get()api with "con_id= NULL",clk = clk_get(dev, NULL);And platform code should respect this and return valid clk handle. That means, now the
clk_get()api would rely ondev_id, and platform code should either have clk node with matchingdev_id(with con_id=NULL) or return dummy clk node.With DT support, we can fix the
dev_idfor particular module using "structof_dev_auxdata" to satisfy above clk framework requirement.In case of AM33XX, we required this for the DCAN module, so this patch adds "
of_dev_auxdata" for both DCAN_0/1 instances.Signed-off-by Vaibhav Hiremath <[email protected]>Cc Tony Lindgren <[email protected]>Cc Paul Walmsley <[email protected]>Cc Benoit Cousson <[email protected]>Cc Grant Likely <[email protected]>---
This patch is boot tested on BeagleBone platform, and checked forclk_get()return value ind_canmodule driver.arch/arm/mach-omap2/board-generic.c | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)arch/arm/mach-omap2/board-generic.c +1
-0@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } }; +/*
arch/arm/mach-omap2/board-generic.c static struct of_device_id omap_dt_match_table[] __initdata = { · line 50
Quoted 10 lines
arch/arm/mach-omap2/board-generic.c +10
-0+* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +};
Adding an additional clkdev lookup accomplishes the same thing and is a cleaner solution.
Rob
Quoted 23 lines
arch/arm/mach-omap2/board-generic.c +6
-2+static void __init omap_generic_init (void ) {omap_sdrc_init (NULL ,NULL ); -of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); +if (of_machine_is_compatible ("ti,am33xx" )) +of_platform_populate (NULL , omap_dt_match_table, + am33xx_auxdata_lookup,NULL ); +else +of_platform_populate (NULL , omap_dt_match_table,NULL ,NULL ); }#ifdef CONFIG_SOC_OMAP2420 --1.7.0.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Quoted 37 lines · Rob Herring
Quoted 36 lines · Vaibhav Hiremath
If the module requires only one clocksource to function, then driver can very well call
clk_get()api with "con_id= NULL",clk = clk_get(dev, NULL);And platform code should respect this and return valid clk handle. That means, now the
clk_get()api would rely ondev_id, and platform code should either have clk node with matchingdev_id(with con_id=NULL) or return dummy clk node.With DT support, we can fix the
dev_idfor particular module using "structof_dev_auxdata" to satisfy above clk framework requirement.In case of AM33XX, we required this for the DCAN module, so this patch adds "
of_dev_auxdata" for both DCAN_0/1 instances.Signed-off-by Vaibhav Hiremath <[email protected]>Cc Tony Lindgren <[email protected]>Cc Paul Walmsley <[email protected]>Cc Benoit Cousson <[email protected]>Cc Grant Likely <[email protected]>---
This patch is boot tested on BeagleBone platform, and checked forclk_get()return value ind_canmodule driver.arch/arm/mach-omap2/board-generic.c | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)arch/arm/mach-omap2/board-generic.c +0
-0@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } };
Quoted 15 lines
arch/arm/mach-omap2/board-generic.c static struct of_device_id omap_dt_match_table[] __initdata = { · line 50
Quoted 11 lines
arch/arm/mach-omap2/board-generic.c +11
-0+/* +* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +};Adding an additional clkdev lookup accomplishes the same thing and is a cleaner solution.
That is also required and I have submitted patch for the same -
http://www.spinics.net/lists/arm-kernel/msg187998.html
With DT support, I am getting dev_id as -
- Without "reg" property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
- With "reg" property: 481cc000.d_can and 481d0000.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so doesn't this patch make sense?
Similar thing has already been done for other platforms too.
Thanks,
Vaibhav
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Op 7 aug. 2012, om 17:53 heeft "Hiremath, Vaibhav" <[email protected]> het volgende geschreven:
Quoted 64 lines · Rob Herring
Quoted 37 lines · Vaibhav Hiremath
Quoted 36 lines
If the module requires only one clocksource to function, then driver can very well call
clk_get()api with "con_id= NULL",clk = clk_get(dev, NULL);And platform code should respect this and return valid clk handle. That means, now the
clk_get()api would rely ondev_id, and platform code should either have clk node with matchingdev_id(with con_id=NULL) or return dummy clk node.With DT support, we can fix the
dev_idfor particular module using "structof_dev_auxdata" to satisfy above clk framework requirement.In case of AM33XX, we required this for the DCAN module, so this patch adds "
of_dev_auxdata" for both DCAN_0/1 instances.Signed-off-by Vaibhav Hiremath <[email protected]>Cc Tony Lindgren <[email protected]>Cc Paul Walmsley <[email protected]>Cc Benoit Cousson <[email protected]>Cc Grant Likely <[email protected]>---
This patch is boot tested on BeagleBone platform, and checked forclk_get()return value ind_canmodule driver.
arch/arm/mach-omap2/board-generic.c| 18 +++++++++++++++++-1 files changed, 17 insertions(+), 1 deletions(-)arch/arm/mach-omap2/board-generic.c +0
-0@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } };Quoted 15 lines
arch/arm/mach-omap2/board-generic.c static struct of_device_id omap_dt_match_table[] __initdata = { · line 50
Quoted 11 lines
arch/arm/mach-omap2/board-generic.c +11
-0+/* +* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +};Adding an additional clkdev lookup accomplishes the same thing and is a cleaner solution.
That is also required and I have submitted patch for the same -
http://www.spinics.net/lists/arm-kernel/msg187998.html
With DT support, I am getting
dev_idas -- Without "reg" property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
Quoted 6 lines
- With "reg" property: 481cc000.d_can and 481d0000.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so doesn't this patch make sense?
Similar thing has already been done for other platforms too.
Davinci-mdio has a similar problem
regards,
Koen
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
In reply to Hiremath, VaibhavQuoted 54 lines · Vaibhav
Quoted 37 lines · Rob Herring
Quoted 36 lines · Vaibhav Hiremath
If the module requires only one clocksource to function, then driver can very well call
clk_get()api with "con_id= NULL",clk = clk_get(dev, NULL);And platform code should respect this and return valid clk handle. That means, now the
clk_get()api would rely ondev_id, and platform code should either have clk node with matchingdev_id(with con_id=NULL) or return dummy clk node.With DT support, we can fix the
dev_idfor particular module using "structof_dev_auxdata" to satisfy above clk framework requirement.In case of AM33XX, we required this for the DCAN module, so this patch adds "
of_dev_auxdata" for both DCAN_0/1 instances.Signed-off-by Vaibhav Hiremath <[email protected]>Cc Tony Lindgren <[email protected]>Cc Paul Walmsley <[email protected]>Cc Benoit Cousson <[email protected]>Cc Grant Likely <[email protected]>---
This patch is boot tested on BeagleBone platform, and checked forclk_get()return value ind_canmodule driver.arch/arm/mach-omap2/board-generic.c | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)arch/arm/mach-omap2/board-generic.c +0
-0@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } };Quoted 15 lines
arch/arm/mach-omap2/board-generic.c static struct of_device_id omap_dt_match_table[] __initdata = { · line 50
Quoted 11 lines
arch/arm/mach-omap2/board-generic.c +11
-0+/* +* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +};Adding an additional clkdev lookup accomplishes the same thing and is a cleaner solution.
Quoted 3 lines
That is also required and I have submitted patch for the same -
That only adds the non-DT name. What I'm saying is you can have 2 lookup names for the same clock.
Quoted 10 lines
With DT support, I am getting
dev_idas -- Without "reg" property: d_can.16 and d_can.17,
(I believe it changes dynamically here)- With "reg" property: 481cc000.d_can and 481d0000.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so doesn't this patch make sense?
The spec doesn't have a base address for the module? This name is going to get used in sysfs anyway, and the old name should be going away.
Quoted 1 line
Similar thing has already been done for other platforms too.
Only ones I haven't reviewed.
Rob
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Quoted 68 lines · Rob Herring
Quoted 54 lines · Vaibhav
Quoted 37 lines · Rob Herring
Quoted 36 lines · Vaibhav Hiremath
If the module requires only one clocksource to function, then driver can very well call
clk_get()api with "con_id= NULL",clk = clk_get(dev, NULL);And platform code should respect this and return valid clk handle. That means, now the
clk_get()api would rely ondev_id, and platform code should either have clk node with matchingdev_id(with con_id=NULL) or return dummy clk node.With DT support, we can fix the
dev_idfor particular module using "structof_dev_auxdata" to satisfy above clk framework requirement.In case of AM33XX, we required this for the DCAN module, so this patch adds "
of_dev_auxdata" for both DCAN_0/1 instances.Signed-off-by Vaibhav Hiremath <[email protected]>Cc Tony Lindgren <[email protected]>Cc Paul Walmsley <[email protected]>Cc Benoit Cousson <[email protected]>Cc Grant Likely <[email protected]>---
This patch is boot tested on BeagleBone platform, and checked forclk_get()return value ind_canmodule driver.arch/arm/mach-omap2/board-generic.c | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)arch/arm/mach-omap2/board-generic.c +0
-0@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } };Quoted 15 lines
arch/arm/mach-omap2/board-generic.c static struct of_device_id omap_dt_match_table[] __initdata = { · line 50
Quoted 11 lines
arch/arm/mach-omap2/board-generic.c +11
-0+/* +* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +};Adding an additional clkdev lookup accomplishes the same thing and is a cleaner solution.
Quoted 3 lines
That is also required and I have submitted patch for the same -
That only adds the non-DT name. What I'm saying is you can have 2 lookup names for the same clock.
Quoted 6 lines
With DT support, I am getting
dev_idas -- Without "reg" property: d_can.16 and d_can.17,
(I believe it changes dynamically here)
Quoted 8 lines
Quoted 4 lines
- With "reg" property: 481cc000.d_can and 481d0000.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so doesn't this patch make sense?
The spec doesn't have a base address for the module? This name is going to get used in sysfs anyway, and the old name should be going away.
This is certainly going to change user interface change, and I thought we should not change the user interface irrespective of whether it is DT or non-DT.
Few points, which I do care about, are,
1. request_irq():
For the driver if I am using dev_name(dev) as for the 3rd argument, which will now different with DT support - brings change in user interface.
Non-DT:
#cat /proc/interrupts
CPU0
52: 0 INTC xxx0
55: 0 INTC xxx1
DT:
#cat /proc/interrupts
CPU0
52: 0 INTC 481cc000.xxx
55: 0 INTC 481d0000.xxx2. SYSFS:
For example,
Without auxdata:
/sys/devices/481cc000.xxx/
/sys/devices/481d0000.xxx/With auxdata:
/sys/devices/xxx.0/
/sys/devices/xxx.1/From user perspective, I still would not want to change the existing naming convention.
3. Certainly I don't want user to go back to spec everytime to find out which address is mapped to which instance of module.
Also, in addition to that, in case of SoC's like AM33xx (for that matter, any embedded SoC) we have different domains and modules are placed in different domains as per use-cases.
For example, in this case, can0 is places in wakeup domain and can1 is placed in per-domain. Some boards might use only one instance or some board might use both of them.
I still would like to keep instance number wherever user interface comes into picture and populate base address as an additional info to user.
I may be missing something, may be I am not able to see the bigger picture here.
Grant/Benoit, May be you can conform and put your opinion on this.
Thanks,
Vaibhav
PATCH 1/1 ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
Quoted 122 lines · Vaibhav
Quoted 68 lines · Rob Herring
Quoted 54 lines · Vaibhav
Quoted 37 lines · Rob Herring
Quoted 36 lines · Vaibhav Hiremath
If the module requires only one clocksource to function, then driver can very well call
clk_get()api with "con_id= NULL",clk = clk_get(dev, NULL);And platform code should respect this and return valid clk handle. That means, now the
clk_get()api would rely ondev_id, and platform code should either have clk node with matchingdev_id(with con_id=NULL) or return dummy clk node.With DT support, we can fix the
dev_idfor particular module using "structof_dev_auxdata" to satisfy above clk framework requirement.In case of AM33XX, we required this for the DCAN module, so this patch adds "
of_dev_auxdata" for both DCAN_0/1 instances.Signed-off-by Vaibhav Hiremath <[email protected]>Cc Tony Lindgren <[email protected]>Cc Paul Walmsley <[email protected]>Cc Benoit Cousson <[email protected]>Cc Grant Likely <[email protected]>---
This patch is boot tested on BeagleBone platform, and checked forclk_get()return value ind_canmodule driver.arch/arm/mach-omap2/board-generic.c | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-)arch/arm/mach-omap2/board-generic.c +0
-0@@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } };Quoted 15 lines
arch/arm/mach-omap2/board-generic.c static struct of_device_id omap_dt_match_table[] __initdata = { · line 50
Quoted 11 lines
arch/arm/mach-omap2/board-generic.c +11
-0+/* +* Lookup table for attaching a specific name and platform_data pointer to +* devices as they get created by of_platform_populate(). Ideally this table +* would not exist, but the current clock implementation depends on some devices +* having a specific name OR to satisfy NULL con_id requirement from driver. +*/ +static const struct of_dev_auxdata am33xx_auxdata_lookup[]__initconst = { +OF_DEV_AUXDATA ("bosch,d_can" ,0x481cc000 ,"d_can.0" ,NULL ), +OF_DEV_AUXDATA ("bosch,d_can" ,0x481d0000 ,"d_can.1" ,NULL ), + { }, +};Adding an additional clkdev lookup accomplishes the same thing and is a cleaner solution.
Quoted 3 lines
That is also required and I have submitted patch for the same -
That only adds the non-DT name. What I'm saying is you can have 2 lookup names for the same clock.
Quoted 6 lines
With DT support, I am getting
dev_idas -- Without "reg" property: d_can.16 and d_can.17,
(I believe it changes dynamically here)Quoted 8 lines
Quoted 4 lines
- With "reg" property: 481cc000.d_can and 481d0000.d_can
Which is not so intuitive, I would like to see them as per Spec/TRM, so doesn't this patch make sense?
The spec doesn't have a base address for the module? This name is going to get used in sysfs anyway, and the old name should be going away.
This is certainly going to change user interface change, and I thought we should not change the user interface irrespective of whether it is DT or non-DT.
Few points, which I do care about, are,1.
request_irq():
For the driver if I am usingdev_name(dev)as for the 3rd argument, which will now different with DT support - brings change in user interface.Non-DT: #cat /proc/interrupts CPU0 52: 0 INTC xxx0 55: 0 INTC xxx1 DT: #cat /proc/interrupts CPU0 52: 0 INTC 481cc000.xxx 55: 0 INTC 481d0000.xxx2. SYSFS:
For example, Without auxdata: /sys/devices/481cc000.xxx/ /sys/devices/481d0000.xxx/ With auxdata: /sys/devices/xxx.0/ /sys/devices/xxx.1/ From user perspective, I still would not want to change the existing naming convention.3. Certainly I don't want user to go back to spec everytime to find out which address is mapped to which instance of module.
Also, in addition to that, in case of SoC's like AM33xx (for that matter, any embedded SoC) we have different domains and modules are placed in different domains as per use-cases.
For example, in this case, can0 is places in wakeup domain and can1 is placed in per-domain. Some boards might use only one instance or some board might use both of them.
Quoted 9 lines
I still would like to keep instance number wherever user interface comes into picture and populate base address as an additional info to user.
I may be missing something, may be I am not able to see the bigger picture here.
Grant/Benoit, May be you can conform and put your opinion on this.
Rob,
I think we do not have any conclusion on this, so here should I assume that I should just simply add another clk node entry in clock-tree, like below -
CLK("481cc000.d_can", NULL, &dcan0_fck, CK_AM33XX),
CLK("481d0000.d_can", NULL, &dcan1_fck, CK_AM33XX),Thanks,
Vaibhav