| Message ID | 1427206147-19365-2-git-send-email-mpa@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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 + >; + }; }; };
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(-)