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

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

[Markus Pargmann]

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

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
 arch/arm/boot/dts/imx25.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index e4d3aecc4ed2..677f81d9dcd5 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -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";
-- 
2.1.4

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

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

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
 arch/arm/boot/dts/imx25-karo-tx25.dts | 84 +++++++++++++++++++----------------
 1 file changed, 45 insertions(+), 39 deletions(-)

diff --git a/arch/arm/boot/dts/imx25-karo-tx25.dts b/arch/arm/boot/dts/imx25-karo-tx25.dts
index 9b31faa96377..11344fb27727 100644
--- a/arch/arm/boot/dts/imx25-karo-tx25.dts
+++ b/arch/arm/boot/dts/imx25-karo-tx25.dts
@@ -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
+			>;
+		};
 	};
 };
 
-- 
2.1.4

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

[Uwe Kleine-König]

Hello,

[Cc += Lothar Wa?mann]

On Tue, Mar 24, 2015 at 03:09:07PM +0100, Markus Pargmann wrote:
> 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.

> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
>  arch/arm/boot/dts/imx25-karo-tx25.dts | 84 +++++++++++++++++++----------------
>  1 file changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx25-karo-tx25.dts b/arch/arm/boot/dts/imx25-karo-tx25.dts
> index 9b31faa96377..11344fb27727 100644
> --- a/arch/arm/boot/dts/imx25-karo-tx25.dts
> +++ b/arch/arm/boot/dts/imx25-karo-tx25.dts
> @@ -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 {
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

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

[Markus Pargmann]

Hi,

On Tue, Mar 24, 2015 at 08:50:46PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> [Cc += Lothar Wa?mann]
> 
> On Tue, Mar 24, 2015 at 03:09:07PM +0100, Markus Pargmann wrote:
> > 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.
> 
> > Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> > ---
> >  arch/arm/boot/dts/imx25-karo-tx25.dts | 84 +++++++++++++++++++----------------
> >  1 file changed, 45 insertions(+), 39 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/imx25-karo-tx25.dts b/arch/arm/boot/dts/imx25-karo-tx25.dts
> > index 9b31faa96377..11344fb27727 100644
> > --- a/arch/arm/boot/dts/imx25-karo-tx25.dts
> > +++ b/arch/arm/boot/dts/imx25-karo-tx25.dts
> > @@ -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 {
> 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.

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

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

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

[Uwe Kleine-König]

Hello Markus,

On Wed, Mar 25, 2015 at 12:02:37PM +0100, Markus Pargmann wrote:
> On Tue, Mar 24, 2015 at 08:50:46PM +0100, Uwe Kleine-K?nig wrote:
> > 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

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

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

[Markus Pargmann]

Hi,

On Wed, Mar 25, 2015 at 12:09:02PM +0100, Uwe Kleine-K?nig wrote:
> Hello Markus,
> 
> On Wed, Mar 25, 2015 at 12:02:37PM +0100, Markus Pargmann wrote:
> > On Tue, Mar 24, 2015 at 08:50:46PM +0100, Uwe Kleine-K?nig wrote:
> > > 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

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

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