Skip to contentSkip to conversation

ARM: dts: imx25: Add #pwm-cells to pwm4

PATCH New Markus Pargmann 2 participants 6 messages Mar 24, 2015 – Mar 29, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/2 ARM: dts: imx25: Add #pwm-cells to pwm4

The property '#pwm-cells' is currently missing. It is not possible to use pwm4 without this property.

---
 arch/arm/boot/dts/imx25.dtsi | 1 +
 1 file changed, 1 insertion(+)
arch/arm/boot/dts/imx25.dtsi +1 -0
index e4d3aecc4ed2..677f81d9dcd5 100644
@@ -428,6 +428,7 @@
 
 			pwm4: pwm at 53fc8000 {
 				compatible = "fsl,imx25-pwm", "fsl,imx27-pwm";
+				#pwm-cells = <2>;
 				reg = <0x53fc8000 0x4000>;
 				clocks = <&clks 108>, <&clks 52>;
 				clock-names = "ipg", "per";
Signature · 1 line
2.1.4
#1 lore raw

PATCH 2/2 ARM: dts: imx25-karo-tx25: Fix pincontrol definition

The iomux group nodes have to be in a pinmux category as described in the devicetree binding documentation example. The current definitions are not parsed by imx25-pinctrl.

---
 arch/arm/boot/dts/imx25-karo-tx25.dts | 84 +++++++++++++++++++----------------
 1 file changed, 45 insertions(+), 39 deletions(-)
arch/arm/boot/dts/imx25-karo-tx25.dts +45 -39
index 9b31faa96377..11344fb27727 100644
@@ -42,49 +42,55 @@
 };
 
 &iomuxc {
-	pinctrl_uart1: uart1grp {
-		fsl,pins = <
-			MX25_PAD_UART1_TXD__UART1_TXD 0x80000000
-			MX25_PAD_UART1_RXD__UART1_RXD 0x80000000
-			MX25_PAD_UART1_CTS__UART1_CTS 0x80000000
-			MX25_PAD_UART1_RTS__UART1_RTS 0x80000000
-		>;
+	uart1 {
+		pinctrl_uart1: uart1grp {
+			fsl,pins = <
+				MX25_PAD_UART1_TXD__UART1_TXD 0x80000000
+				MX25_PAD_UART1_RXD__UART1_RXD 0x80000000
+				MX25_PAD_UART1_CTS__UART1_CTS 0x80000000
+				MX25_PAD_UART1_RTS__UART1_RTS 0x80000000
+			>;
+		};
 	};
 
-	pinctrl_fec: fecgrp {
-		fsl,pins = <
-			MX25_PAD_D11__GPIO_4_9		0x80000000 /* FEC PHY power on pin */
-			MX25_PAD_D13__GPIO_4_7		0x80000000 /* FEC reset */
-			MX25_PAD_FEC_MDC__FEC_MDC	0x80000000
-			MX25_PAD_FEC_MDIO__FEC_MDIO	0x80000000
-			MX25_PAD_FEC_TDATA0__FEC_TDATA0	0x80000000
-			MX25_PAD_FEC_TDATA1__FEC_TDATA1	0x80000000
-			MX25_PAD_FEC_TX_EN__FEC_TX_EN	0x80000000
-			MX25_PAD_FEC_RDATA0__FEC_RDATA0	0x80000000
-			MX25_PAD_FEC_RDATA1__FEC_RDATA1	0x80000000
-			MX25_PAD_FEC_RX_DV__FEC_RX_DV	0x80000000
-			MX25_PAD_FEC_TX_CLK__FEC_TX_CLK	0x80000000
-		>;
+	fec {
+		pinctrl_fec: fecgrp {
+			fsl,pins = <
+				MX25_PAD_D11__GPIO_4_9		0x80000000 /* FEC PHY power on pin */
+				MX25_PAD_D13__GPIO_4_7		0x80000000 /* FEC reset */
+				MX25_PAD_FEC_MDC__FEC_MDC	0x80000000
+				MX25_PAD_FEC_MDIO__FEC_MDIO	0x80000000
+				MX25_PAD_FEC_TDATA0__FEC_TDATA0	0x80000000
+				MX25_PAD_FEC_TDATA1__FEC_TDATA1	0x80000000
+				MX25_PAD_FEC_TX_EN__FEC_TX_EN	0x80000000
+				MX25_PAD_FEC_RDATA0__FEC_RDATA0	0x80000000
+				MX25_PAD_FEC_RDATA1__FEC_RDATA1	0x80000000
+				MX25_PAD_FEC_RX_DV__FEC_RX_DV	0x80000000
+				MX25_PAD_FEC_TX_CLK__FEC_TX_CLK	0x80000000
+			>;
+		};
 	};
 
-	pinctrl_nfc: nfcgrp {
-		fsl,pins = <
-			MX25_PAD_NF_CE0__NF_CE0		0x80000000
-			MX25_PAD_NFWE_B__NFWE_B		0x80000000
-			MX25_PAD_NFRE_B__NFRE_B		0x80000000
-			MX25_PAD_NFALE__NFALE		0x80000000
-			MX25_PAD_NFCLE__NFCLE		0x80000000
-			MX25_PAD_NFWP_B__NFWP_B		0x80000000
-			MX25_PAD_NFRB__NFRB		0x80000000
-			MX25_PAD_D7__D7			0x80000000
-			MX25_PAD_D6__D6			0x80000000
-			MX25_PAD_D5__D5			0x80000000
-			MX25_PAD_D4__D4			0x80000000
-			MX25_PAD_D3__D3			0x80000000
-			MX25_PAD_D2__D2			0x80000000
-			MX25_PAD_D1__D1			0x80000000
-			MX25_PAD_D0__D0			0x80000000
-		>;
+	nfc {
+		pinctrl_nfc: nfcgrp {
+			fsl,pins = <
+				MX25_PAD_NF_CE0__NF_CE0		0x80000000
+				MX25_PAD_NFWE_B__NFWE_B		0x80000000
+				MX25_PAD_NFRE_B__NFRE_B		0x80000000
+				MX25_PAD_NFALE__NFALE		0x80000000
+				MX25_PAD_NFCLE__NFCLE		0x80000000
+				MX25_PAD_NFWP_B__NFWP_B		0x80000000
+				MX25_PAD_NFRB__NFRB		0x80000000
+				MX25_PAD_D7__D7			0x80000000
+				MX25_PAD_D6__D6			0x80000000
+				MX25_PAD_D5__D5			0x80000000
+				MX25_PAD_D4__D4			0x80000000
+				MX25_PAD_D3__D3			0x80000000
+				MX25_PAD_D2__D2			0x80000000
+				MX25_PAD_D1__D1			0x80000000
+				MX25_PAD_D0__D0			0x80000000
+			>;
+		};
 	};
 };
 
Signature · 1 line
2.1.4
#2 lore raw

PATCH 2/2 ARM: dts: imx25-karo-tx25: Fix pincontrol definition

Hello,

[Cc += Lothar Wa?mann]

Quoted 3 lines · Markus Pargmann

The iomux group nodes have to be in a pinmux category as described in the devicetree binding documentation example. The current definitions are not parsed by imx25-pinctrl.

I remember having noticed that problem, too, some time ago, but forgot to fix/report it.

Quoted 11 lines
---
 arch/arm/boot/dts/imx25-karo-tx25.dts | 84 +++++++++++++++++++----------------
 1 file changed, 45 insertions(+), 39 deletions(-)
arch/arm/boot/dts/imx25-karo-tx25.dts +0 -0
index 9b31faa96377..11344fb27727 100644
@@ -42,49 +42,55 @@
 };

arch/arm/boot/dts/imx25-karo-tx25.dts line 45

Quoted 10 lines
arch/arm/boot/dts/imx25-karo-tx25.dts +1 -7
 
 &iomuxc {
-	pinctrl_uart1: uart1grp {
-		fsl,pins = <
-			MX25_PAD_UART1_TXD__UART1_TXD 0x80000000
-			MX25_PAD_UART1_RXD__UART1_RXD 0x80000000
-			MX25_PAD_UART1_CTS__UART1_CTS 0x80000000
-			MX25_PAD_UART1_RTS__UART1_RTS 0x80000000
-		>;
+	uart1 {

Some other machines (e.g. imx51-babbage) use a big group named after the machine for all pin groups. Would it be nice to have a uniform rule here?

I think this grouping is a relict from the time when we considered to list the groups in the imx$num.dtsi? I would prefer to "fix" the driver to work with the way imx25-karo-tx25 presents the pinmuxing because I don't see the motivation for this extra grouping. (So let us define the current method of imx25-karo-tx25 as the good one to follow if you ask me.)

Best regards
Uwe

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
#3 lore raw

PATCH 2/2 ARM: dts: imx25-karo-tx25: Fix pincontrol definition

Hi,

Quoted 23 lines · Uwe Kleine-K?nig

Hello,

[Cc += Lothar Wa?mann]

Quoted 3 lines · Markus Pargmann

The iomux group nodes have to be in a pinmux category as described in the devicetree binding documentation example. The current definitions are not parsed by imx25-pinctrl.

I remember having noticed that problem, too, some time ago, but forgot to fix/report it.

Quoted 12 lines
---
 arch/arm/boot/dts/imx25-karo-tx25.dts | 84 +++++++++++++++++++----------------
 1 file changed, 45 insertions(+), 39 deletions(-)
arch/arm/boot/dts/imx25-karo-tx25.dts +0 -0
index 9b31faa96377..11344fb27727 100644
@@ -42,49 +42,55 @@
 };
 
Quoted 12 lines

arch/arm/boot/dts/imx25-karo-tx25.dts line 45

Quoted 9 lines
arch/arm/boot/dts/imx25-karo-tx25.dts +1 -7
 &iomuxc {
-	pinctrl_uart1: uart1grp {
-		fsl,pins = <
-			MX25_PAD_UART1_TXD__UART1_TXD 0x80000000
-			MX25_PAD_UART1_RXD__UART1_RXD 0x80000000
-			MX25_PAD_UART1_CTS__UART1_CTS 0x80000000
-			MX25_PAD_UART1_RTS__UART1_RTS 0x80000000
-		>;
+	uart1 {

Some other machines (e.g. imx51-babbage) use a big group named after the machine for all pin groups. Would it be nice to have a uniform rule here?

Oh yes, the majority seems to use this naming scheme now. I will change it.

Quoted 7 lines

I think this grouping is a relict from the time when we considered to list the groups in the imx$num.dtsi? I would prefer to "fix" the driver to work with the way imx25-karo-tx25 presents the pinmuxing because I don't see the motivation for this extra grouping. (So let us define the current method of imx25-karo-tx25 as the good one to follow if you ask me.)

But the binding for the pinctrl unit is already defined. I am not sure about the policy for changing devicetree bindings. I thought it should be avoided?

Best regards,

Markus

Signature · 11 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150325/dab5eec7/attachment.sig>
#4 lore raw

PATCH 2/2 ARM: dts: imx25-karo-tx25: Fix pincontrol definition

Hello Markus,

Quoted 11 lines · Markus Pargmann
Quoted 6 lines · Uwe Kleine-K?nig

I think this grouping is a relict from the time when we considered to list the groups in the imx$num.dtsi? I would prefer to "fix" the driver to work with the way imx25-karo-tx25 presents the pinmuxing because I don't see the motivation for this extra grouping. (So let us define the current method of imx25-karo-tx25 as the good one to follow if you ask me.)

But the binding for the pinctrl unit is already defined. I am not sure about the policy for changing devicetree bindings. I thought it should be avoided?

Allowing more valid definitions shouldn't be a problem, should it? So don't rip out parsing groups within a namespace, just complement it with support for namespace-less groups

Best regards
Uwe

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
#5 lore raw

PATCH 2/2 ARM: dts: imx25-karo-tx25: Fix pincontrol definition

Hi,

Quoted 11 lines · Uwe Kleine-K?nig

Hello Markus,

Quoted 8 lines · Markus Pargmann
Quoted 6 lines · Uwe Kleine-K?nig

I think this grouping is a relict from the time when we considered to list the groups in the imx$num.dtsi? I would prefer to "fix" the driver to work with the way imx25-karo-tx25 presents the pinmuxing because I don't see the motivation for this extra grouping. (So let us define the current method of imx25-karo-tx25 as the good one to follow if you ask me.)

Quoted 6 lines
Quoted 3 lines

But the binding for the pinctrl unit is already defined. I am not sure about the policy for changing devicetree bindings. I thought it should be avoided?

Allowing more valid definitions shouldn't be a problem, should it? So don't rip out parsing groups within a namespace, just complement it with support for namespace-less groups

I have posted a patch that allows parsing the pinctrl device node without 'function' device nodes. So this patch can be dropped for the moment.

Best Regards,

Markus

Signature · 11 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150329/77f56a13/attachment.sig>