Add device tree data for AM33XX devices
Subsystems (3)
v5 cover Add device tree data for AM33XX devices
Add pinctrl and d_can device tree data to AM33XX family of devices. First two patches add support for pinctrl DT data and third one adds dcan DT data.
Reason behind combining these patches is to apply cleanly on linux-omap tree, because these are sequential patches.
These patches were tested on AM335x-Bone, AM335x-EVM and based on linux-omap:master with this patch
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg74393.html
d_can:
Changes from v4:
- Incorporated Tony's comments on v4
* Converted all hex numbers to lower-case.
- Updated C_CAN bindings documentation according to recent changes.
Changes from v3:
- Removed d_can1 node from am335x-evm.dts file. Instance one of CAN (d_can1) is available on AM335x-EVM only under a specific CPLD mode selection. am335x-evm.dts does not support this mode so remove the d_can1 node.
- Dropped d_can pinmux settings patch, above comment applies here as well.
Changes from v2:
- Incorporated Vaibhav H's comments on v2
* Added dcan0 instances to am33xx.dtsi file
Changes from v1:
- These two patches separated from c_can DT support patch series.
pinctrl:
Changes from v4:
- Incorporated Tony's comments on v4
* Converted all hex numbers to lower-case.
- Added pinctrl api to leds-gpio driver to configure led pins to GPIO mode.
Changes from v3:
- Updated the reg length based on latest AM335x TRM.
Changes from v2:
- user led pinmux comments updated according to Tony's comment.
Changes from v1:
- Rebased the patches based on latest pinctrl-single driver
AnilKumar Ch (5):
arm/dts: AM33XX: Add basic pinctrl device tree data arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone arm/dts: AM33XX: Add D_CAN device tree data
leds: leds-gpio: adopt pinctrl support
of: Modify c_can binding documentation
.../devicetree/bindings/net/can/c_can.txt | 25 +++++++++--- arch/arm/boot/dts/am335x-bone.dts | 41 ++++++++++++++++++++ arch/arm/boot/dts/am33xx.dtsi | 27 +++++++++++++ drivers/leds/leds-gpio.c | 31 +++++++++++---- 4 files changed, 112 insertions(+), 12 deletions(-)
Signature · 1 line
1.7.9.5
PATCH v5 1/5 arm/dts: AM33XX: Add basic pinctrl device tree data
Adds basic pinctrl device tree data for AM33XX family of devices. This patch is based on the pinctrl-single driver.
--- arch/arm/boot/dts/am33xx.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/arm/boot/dts/am33xx.dtsi +9 -0
@@ -40,6 +40,15 @@ }; }; + am3358_pinmux: pinmux at 44e10800 { + compatible = "pinctrl-single"; + reg = <0x44e10800 0x0238>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-single,register-width = <32>; + pinctrl-single,function-mask = <0x7f>; + }; + /* * XXX: Use a flat representation of the AM33XX interconnect. * The real AM33XX interconnect network is quite complex.Since
Signature · 1 line
1.7.9.5
PATCH v5 1/5 arm/dts: AM33XX: Add basic pinctrl device tree data
Quoted 15 lines · AnilKumar Ch
Adds basic pinctrl device tree data for AM33XX family of devices. This patch is based on the pinctrl-single driver.
Signed-off-by AnilKumar Ch <[email protected]>--- arch/arm/boot/dts/am33xx.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+)arch/arm/boot/dts/am33xx.dtsi +0
-0@@ -40,6 +40,15 @@ }; };
arch/arm/boot/dts/am33xx.dtsi line 51
Quoted 10 lines
arch/arm/boot/dts/am33xx.dtsi +9
-0+ am3358_pinmux: pinmux at 44e10800 { + compatible = "pinctrl-single"; + reg = <0x44e10800 0x0238>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-single,register-width = <32>; + pinctrl-single,function-mask = <0x7f>; + }; +
Is this controller the same for all am33xx? If so, please use am33xx_pinmux naming. Note that some padconf registers may not be listed for all the variants, but the registers may still be there for all the variants. So a generic entry is a better choice here as otherwise you'l need to include am33xx.dtsi into am3358.dtsi.
Regards,
Tony
PATCH v5 1/5 arm/dts: AM33XX: Add basic pinctrl device tree data
Quoted 17 lines · Tony Lindgren
Quoted 16 lines · AnilKumar Ch
Adds basic pinctrl device tree data for AM33XX family of devices. This patch is based on the pinctrl-single driver.
Signed-off-by AnilKumar Ch <[email protected]>--- arch/arm/boot/dts/am33xx.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+)arch/arm/boot/dts/am33xx.dtsi +0
-0@@ -40,6 +40,15 @@ }; };
Quoted 17 lines
arch/arm/boot/dts/am33xx.dtsi line 51
Quoted 9 lines
arch/arm/boot/dts/am33xx.dtsi +9
-0+ am3358_pinmux: pinmux at 44e10800 { + compatible = "pinctrl-single"; + reg = <0x44e10800 0x0238>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-single,register-width = <32>; + pinctrl-single,function-mask = <0x7f>; + }; +Is this controller the same for all am33xx? If so, please use
am33xx_pinmuxnaming. Note that some padconf registers may not be listed for all the variants, but the registers may still be there for all the variants. So a generic entry is a better choice here as otherwise you'l need to includeam33xx.dtsiintoam3358.dtsi.
Controller is same for all am33xx devices, I will spin a patch by renaming to am33xx_****
Thanks
AnilKumar
PATCH v5 2/5 arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
In reply to AnilKumar ChAdds GPIO pinctrl nodes to am3358_pinmux master node to control user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
--- arch/arm/boot/dts/am335x-bone.dts | 41 +++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
arch/arm/boot/dts/am335x-bone.dts +41 -0
@@ -18,11 +18,52 @@ reg = <0x80000000 0x10000000>; /* 256 MB */ }; + am3358_pinmux: pinmux at 44e10800 { + userled_pins: pinmux_userled_pins { + pinctrl-single,pins = < + 0x54 0x7 /* gpmc_a5.gpio1_21, OUTPUT | MODE7 */ + 0x58 0x17 /* gpmc_a6.gpio1_22, OUTPUT_PULLUP | MODE7 */ + 0x5c 0x7 /* gpmc_a7.gpio1_23, OUTPUT | MODE7 */ + 0x60 0x17 /* gpmc_a8.gpio1_24, OUTPUT_PULLUP | MODE7 */ + >; + }; + }; + ocp { uart1: serial at 44e09000 { status = "okay"; }; + gpio-leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&userled_pins>; + + led0 { + label = "status:green:user0"; + gpios = <&gpio2 21 0>; + default-state = "off"; + }; + + led1 { + label = "status:green:user1"; + gpios = <&gpio2 22 0>; + default-state = "off"; + }; + + led2 { + label = "status:green:user2"; + gpios = <&gpio2 23 0>; + default-state = "off"; + }; + + led3 { + label = "status:green:user3"; + gpios = <&gpio2 24 0>; + default-state = "off"; + }; + }; + i2c1: i2c at 44e0b000 { status = "okay"; clock-frequency = <400000>;
Signature · 1 line
1.7.9.5
PATCH v5 3/5 arm/dts: AM33XX: Add D_CAN device tree data
In reply to AnilKumar ChAdd Bosch D_CAN controller device tree data to AM33XX dtsi file by adding d_can device nodes with all the necessary parameters.
--- arch/arm/boot/dts/am33xx.dtsi | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
arch/arm/boot/dts/am33xx.dtsi +18 -0
@@ -177,5 +177,23 @@ compatible = "ti,omap3-wdt"; ti,hwmods = "wd_timer2"; }; + + dcan0: d_can at 481cc000 { + compatible = "bosch,d_can"; + ti,hwmods = "d_can0"; + reg = <0x481cc000 0x2000>; + interrupts = <52>; + interrupt-parent = <&intc>; + status = "disabled"; + }; + + dcan1: d_can at 481d0000 { + compatible = "bosch,d_can"; + ti,hwmods = "d_can1"; + reg = <0x481d0000 0x2000>; + interrupts = <55>; + interrupt-parent = <&intc>; + status = "disabled"; + }; }; };
Signature · 1 line
1.7.9.5
PATCH v5 4/5 leds: leds-gpio: adopt pinctrl support
In reply to AnilKumar ChAdopt pinctrl support to leds-gpio driver, based on the device pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO mode.
--- drivers/leds/leds-gpio.c | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-)
drivers/leds/leds-gpio.c +24 -7
@@ -20,6 +20,7 @@#include <linux/slab.h> #include <linux/workqueue.h> #include <linux/module.h> +#include <linux/pinctrl/consumer.h> struct gpio_led_data {struct led_classdev cdev;
@@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct platform_device *pdev) {struct gpio_led_platform_data *pdata = pdev->dev.platform_data;struct gpio_leds_priv *priv; -int i, ret =0 ; +struct pinctrl *pinctrl; +int i =0 ; +int ret =0 ; + + pinctrl =devm_pinctrl_get_select_default (&pdev->dev); +if (IS_ERR (pinctrl)) { +return PTR_ERR (pinctrl); + }if (pdata && pdata->num_leds) { priv =devm_kzalloc (&pdev->dev,sizeof_gpio_leds_priv (pdata->num_leds),GFP_KERNEL ); -if (!priv) -return -ENOMEM ; +if (!priv) { + ret = -ENOMEM ; + goto err_pctrl_put; + } priv->num_leds = pdata->num_leds;for (i =0 ; i < priv->num_leds; i++) {
@@ -254,18 +264,25 @@ static int __devinit gpio_led_probe(struct platform_device *pdev)/* On failure: unwind the led creations */ for (i = i -1 ; i >=0 ; i--)delete_gpio_led (&priv->leds[i]); -return ret; + goto err_pctrl_put; } } }else { priv =gpio_leds_create_of (pdev); -if (!priv) -return -ENODEV ; +if (!priv) { + ret = -ENODEV ; + goto err_del_gpio_led; + } }platform_set_drvdata (pdev, priv); -return 0 ; +err_pctrl_put: +pinctrl_put (pinctrl); +err_del_gpio_led: +while (--i >=0 ) +delete_gpio_led (&priv->leds[i]); +return ret; } static int __devexit gpio_led_remove(struct platform_device *pdev)
Signature · 1 line
1.7.9.5
PATCH 4/5 leds: leds-gpio: adopt pinctrl support
Quoted 24 lines · AnilKumar Ch
Adopt pinctrl support to leds-gpio driver, based on the device pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO mode.
Signed-off-by AnilKumar Ch <[email protected]>--- drivers/leds/leds-gpio.c | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-)drivers/leds/leds-gpio.c +1
-0@@ -20,6 +20,7 @@#include <linux/slab.h> #include <linux/workqueue.h> #include <linux/module.h> +#include <linux/pinctrl/consumer.h> struct gpio_led_data {struct led_classdev cdev;@@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct platform_device *pdev) {struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
drivers/leds/leds-gpio.c static int __devinit gpio_led_probe(struct platform_device *pdev) · line 247
Quoted 10 lines
drivers/leds/leds-gpio.c +8
-1struct gpio_leds_priv *priv; -int i, ret =0 ; +struct pinctrl *pinctrl; +int i =0 ; +int ret =0 ; + + pinctrl =devm_pinctrl_get_select_default (&pdev->dev); +if (IS_ERR (pinctrl)) { +return PTR_ERR (pinctrl); + }
I think you need to just print out a warning here as most systems don't have the pinctrl implemented. And some people just do static pinmuxing in the bootloader.
Regards,
Tony
PATCH v5 4/5 leds: leds-gpio: adopt pinctrl support
Hi Tony,
Thanks for the review,
Quoted 31 lines · Tony Lindgren
Quoted 30 lines · AnilKumar Ch
Adopt pinctrl support to leds-gpio driver, based on the device pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO mode.
Signed-off-by AnilKumar Ch <[email protected]>--- drivers/leds/leds-gpio.c | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-)drivers/leds/leds-gpio.c +5
-1@@ -20,6 +20,7 @@#include <linux/slab.h> #include <linux/workqueue.h> #include <linux/module.h> +#include <linux/pinctrl/consumer.h> struct gpio_led_data {struct led_classdev cdev;@@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct platform_device *pdev) {struct gpio_led_platform_data *pdata = pdev->dev.platform_data;struct gpio_leds_priv *priv; -int i, ret =0 ; +struct pinctrl *pinctrl; +int i =0 ; +int ret =0 ; +
Quoted 9 lines
drivers/leds/leds-gpio.c static int __devinit gpio_led_probe(struct platform_device *pdev) · line 247
Quoted 4 lines
drivers/leds/leds-gpio.c +4
-0+ pinctrl =devm_pinctrl_get_select_default (&pdev->dev); +if (IS_ERR (pinctrl)) { +return PTR_ERR (pinctrl); + }I think you need to just print out a warning here as most systems don't have the pinctrl implemented. And some people just do static pinmuxing in the bootloader.
Yes, that is better approach I will fix this in my next version. I will separate out this patch from the series because these changes are leds-gpio driver specific which are different from DT data (pinctrl and d_can).
Thanks
AnilKumar
PATCH v5 5/5 of: Modify c_can binding documentation
In reply to AnilKumar ChModify c_can binding documentation according to recent review comments on device tree data addition patches.
--- .../devicetree/bindings/net/can/c_can.txt | 25 ++++++++++++++++---- 1 file changed, 20 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/net/can/c_can.txt +20 -5
@@ -8,6 +8,8 @@ Required properties: registers map - interrupts : property with a value describing the interrupt number +- status : describes the node status either "disabled" or + "okay" Optional properties: - interrupt-parent : The parent interrupt controller
@@ -20,18 +22,31 @@ Future plan is to migrate hwmod data base contents into device tree blob so that, all the required data will be used from device tree dts file. -Examples: +Example: - d_can at 481D0000 { +Step1: SoC common .dtsi file + + d_can1: d_can at 481d0000 { compatible = "bosch,d_can"; - reg = <0x481D0000 0x1000>; - interrupts = <55 0x4>; + reg = <0x481d0000 0x2000>; + interrupts = <55>; interrupt-parent = <&intc>; + status = "disabled"; }; (or) - d_can at 481D0000 { + d_can1: d_can at 481d0000 { compatible = "bosch,d_can"; ti,hwmods = "d_can1"; + reg = <0x481d0000 0x2000>; + interrupts = <55>; + interrupt-parent = <&intc>; + status = "disabled"; + }; + +Step 2: board specific .dts file + + &dcan1 { + status = "okay"; };
Signature · 1 line
1.7.9.5
PATCH v5 5/5 of: Modify c_can binding documentation
Hi Marc,
Quoted 62 lines · Chimata
Modify
c_canbinding documentation according to recent review comments on device tree data addition patches.Signed-off-by AnilKumar Ch <[email protected]>--- .../devicetree/bindings/net/can/c_can.txt | 25 ++++++++++++++++---- 1 file changed, 20 insertions(+), 5 deletions(-)Documentation/devicetree/bindings/net/can/c_can.txt +20
-5@@ -8,6 +8,8 @@ Required properties: registers map - interrupts : property with a value describing the interrupt number +- status : describes the node status either "disabled" or + "okay" Optional properties: - interrupt-parent : The parent interrupt controller@@ -20,18 +22,31 @@ Future plan is to migrate hwmod data base contents into device tree blob so that, all the required data will be used from device tree dts file. -Examples: +Example: - d_can at 481D0000 { +Step1: SoC common .dtsi file + + d_can1: d_can at 481d0000 { compatible = "bosch,d_can"; - reg = <0x481D0000 0x1000>; - interrupts = <55 0x4>; + reg = <0x481d0000 0x2000>; + interrupts = <55>; interrupt-parent = <&intc>; + status = "disabled"; }; (or) - d_can at 481D0000 { + d_can1: d_can at 481d0000 { compatible = "bosch,d_can"; ti,hwmods = "d_can1"; + reg = <0x481d0000 0x2000>; + interrupts = <55>; + interrupt-parent = <&intc>; + status = "disabled"; + }; + +Step 2: board specific .dts file + + &dcan1 { + status = "okay"; };Signature · 1 line
1.7.9.5
Can you review this patch and push it to linux-can tree? Because initial version of this file c_can.txt is in linux-can tree.
Thanks
AnilKumar
PATCH 5/5 of: Modify c_can binding documentation
Quoted 4 lines · Chimata
Quoted 2 lines · Chimata
Modify
c_canbinding documentation according to recent review comments on device tree data addition patches.
Quoted 10 lines
Documentation/devicetree/bindings/net/can/c_can.txt Required properties: · line 12
Quoted 10 lines
Documentation/devicetree/bindings/net/can/c_can.txt +2
-0@@ -8,6 +8,8 @@ Required properties: registers map - interrupts : property with a value describing the interrupt number +- status : describes the node status either "disabled" or + "okay"
That's a standrd property that applies to any node, and doesn't describe data required by the device itself (as do regs/interrupts) by simply whether the node is activated; I'm not sure it's worth mentioning it in a device-specific binding.
A similar comment exists for the pre-existing description of interrupt-parent below.
Quoted 2 lines
Quoted 2 lines
Documentation/devicetree/bindings/net/can/c_can.txt +0
-0Optional properties: - interrupt-parent : The parent interrupt controller
PATCH v5 5/5 of: Modify c_can binding documentation
Hi Stephen,
Thanks for the review,
Quoted 21 lines · Stephen Warren
Quoted 4 lines · Chimata
Quoted 2 lines · Chimata
Modify
c_canbinding documentation according to recent review comments on device tree data addition patches.Quoted 10 lines
Documentation/devicetree/bindings/net/can/c_can.txt Required properties: · line 12
Quoted 10 lines
Documentation/devicetree/bindings/net/can/c_can.txt +2
-0@@ -8,6 +8,8 @@ Required properties: registers map - interrupts : property with a value describing the interrupt number +- status : describes the node status either "disabled" or + "okay"That's a standrd property that applies to any node, and doesn't describe data required by the device itself (as do regs/interrupts) by simply whether the node is activated; I'm not sure it's worth mentioning it in a device-specific binding.
Quoted 6 lines
A similar comment exists for the pre-existing description of interrupt-parent below.
Quoted 2 lines
Quoted 2 lines
Documentation/devicetree/bindings/net/can/c_can.txt +0
-0Optional properties: - interrupt-parent : The parent interrupt controller
Then, I will remove these properties from the doc.
Thanks
AnilKumar