| Message ID | CAOMZO5D2E_G4ySUnj=yadziSunwMBSVZs-Rw=EvNybFKs2iD3w@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hello Fabio, On Tue, Jul 12, 2016 at 03:32:54PM -0300, Fabio Estevam wrote: > On Tue, Jul 12, 2016 at 12:15 PM, Fabio Estevam <festevam@gmail.com> wrote: > > > I will try to get access to a mx25pdk and will confirm soon. Thanks > > Please find attached the patch after reading all the PAD_CTL > registers. Feel free to submit it as part of your series. > From a2b9e24841909868803576c68c2d2b064a00d4a9 Mon Sep 17 00:00:00 2001 > From: Fabio Estevam <fabio.estevam@nxp.com> > Date: Tue, 12 Jul 2016 15:19:02 -0300 > Subject: [PATCH] ARM: dts: imx25-pdk: Explicitly setup PAD config in dts > > When passing 0x80000000 as the PAD_CTL config value, the kernel does > not touch the PAD_CTL egisters and use the value that comes from the > bootloader. > > Instead of relying on the bootloader it is better to have the kernel > to explicitly configure the PAD_CTL registers. > > Modified each 0x80000000 occurrance by reading the real PAD_CTL > registers values in the bootloader and putting in the dts. > > Also tested by booting the resulting dtb. > > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> > --- > arch/arm/boot/dts/imx25-pdk.dts | 58 ++++++++++++++++++++--------------------- > 1 file changed, 29 insertions(+), 29 deletions(-) > > diff --git a/arch/arm/boot/dts/imx25-pdk.dts b/arch/arm/boot/dts/imx25-pdk.dts > index 7029210..e997e2b 100644 > --- a/arch/arm/boot/dts/imx25-pdk.dts > +++ b/arch/arm/boot/dts/imx25-pdk.dts > @@ -159,56 +159,56 @@ > fsl,pins = < > MX25_PAD_GPIO_A__CAN1_TX 0x0 > MX25_PAD_GPIO_B__CAN1_RX 0x0 > - MX25_PAD_D14__GPIO_4_6 0x80000000 > + MX25_PAD_D14__GPIO_4_6 0xa1 > >; > }; > > pinctrl_esdhc1: esdhc1grp { > fsl,pins = < > - MX25_PAD_SD1_CMD__SD1_CMD 0x80000000 > - MX25_PAD_SD1_CLK__SD1_CLK 0x80000000 > - MX25_PAD_SD1_DATA0__SD1_DATA0 0x80000000 > - MX25_PAD_SD1_DATA1__SD1_DATA1 0x80000000 > - MX25_PAD_SD1_DATA2__SD1_DATA2 0x80000000 > - MX25_PAD_SD1_DATA3__SD1_DATA3 0x80000000 > - MX25_PAD_A14__GPIO_2_0 0x80000000 > - MX25_PAD_A15__GPIO_2_1 0x80000000 > + MX25_PAD_SD1_CMD__SD1_CMD 0xe1 > + MX25_PAD_SD1_CLK__SD1_CLK 0xd1 > + MX25_PAD_SD1_DATA0__SD1_DATA0 0xe1 > + MX25_PAD_SD1_DATA1__SD1_DATA1 0xd1 > + MX25_PAD_SD1_DATA2__SD1_DATA2 0xd1 > + MX25_PAD_SD1_DATA3__SD1_DATA3 0xe1 > + MX25_PAD_A14__GPIO_2_0 0x80 > + MX25_PAD_A15__GPIO_2_1 0x00 > >; > }; > > pinctrl_fec: fecgrp { > fsl,pins = < > - MX25_PAD_FEC_MDC__FEC_MDC 0x80000000 > + MX25_PAD_FEC_MDC__FEC_MDC 0x00 > MX25_PAD_FEC_MDIO__FEC_MDIO 0x400001e0 > - 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_TDATA0__FEC_TDATA0 0x00 > + MX25_PAD_FEC_TDATA1__FEC_TDATA1 0x00 > + MX25_PAD_FEC_TX_EN__FEC_TX_EN 0x00 > + MX25_PAD_FEC_RDATA0__FEC_RDATA0 0xc0 > + MX25_PAD_FEC_RDATA1__FEC_RDATA1 0xc0 > + MX25_PAD_FEC_RX_DV__FEC_RX_DV 0xc0 > MX25_PAD_FEC_TX_CLK__FEC_TX_CLK 0x1c0 > - MX25_PAD_A17__GPIO_2_3 0x80000000 > - MX25_PAD_D12__GPIO_4_8 0x80000000 > + MX25_PAD_A17__GPIO_2_3 0x00 > + MX25_PAD_D12__GPIO_4_8 0x00 > >; > }; > > pinctrl_i2c1: i2c1grp { > fsl,pins = < > - MX25_PAD_I2C1_CLK__I2C1_CLK 0x80000000 > - MX25_PAD_I2C1_DAT__I2C1_DAT 0x80000000 > + MX25_PAD_I2C1_CLK__I2C1_CLK 0xa8 > + MX25_PAD_I2C1_DAT__I2C1_DAT 0xa8 > >; > }; > > pinctrl_kpp: kppgrp { > fsl,pins = < > - MX25_PAD_KPP_ROW0__KPP_ROW0 0x80000000 > - MX25_PAD_KPP_ROW1__KPP_ROW1 0x80000000 > - MX25_PAD_KPP_ROW2__KPP_ROW2 0x80000000 > - MX25_PAD_KPP_ROW3__KPP_ROW3 0x80000000 > - MX25_PAD_KPP_COL0__KPP_COL0 0x80000000 > - MX25_PAD_KPP_COL1__KPP_COL1 0x80000000 > - MX25_PAD_KPP_COL2__KPP_COL2 0x80000000 > - MX25_PAD_KPP_COL3__KPP_COL3 0x80000000 > + MX25_PAD_KPP_ROW0__KPP_ROW0 0xa0 > + MX25_PAD_KPP_ROW1__KPP_ROW1 0xa0 > + MX25_PAD_KPP_ROW2__KPP_ROW2 0xe0 > + MX25_PAD_KPP_ROW3__KPP_ROW3 0xe0 > + MX25_PAD_KPP_COL0__KPP_COL0 0xa8 > + MX25_PAD_KPP_COL1__KPP_COL1 0xa8 > + MX25_PAD_KPP_COL2__KPP_COL2 0xa8 > + MX25_PAD_KPP_COL3__KPP_COL3 0xa8 > >; > }; > > @@ -244,7 +244,7 @@ > fsl,pins = < > MX25_PAD_UART1_RTS__UART1_RTS 0xe0 > MX25_PAD_UART1_CTS__UART1_CTS 0xe0 > - MX25_PAD_UART1_TXD__UART1_TXD 0x80000000 > + MX25_PAD_UART1_TXD__UART1_TXD 0x00 > MX25_PAD_UART1_RXD__UART1_RXD 0xc0 Are you sure here? According to the reference manual bit 0x40 of IOMUXC_SW_PAD_CTL_PAD_UART1_RXD isn't valid. And my i.mx25 based machine agrees: barebox@imx25:/ mw 0x43fac368 0xc0 barebox@imx25:/ md 0x43fac368+4 43fac368: 00000080 .... (This entry was fixed in my series to 0x80.) So you only checked the NO_PAD_CTL values, right? Best regards Uwe
Hi Uwe, On Tue, Jul 12, 2016 at 4:15 PM, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: >> @@ -244,7 +244,7 @@ >> fsl,pins = < >> MX25_PAD_UART1_RTS__UART1_RTS 0xe0 >> MX25_PAD_UART1_CTS__UART1_CTS 0xe0 >> - MX25_PAD_UART1_TXD__UART1_TXD 0x80000000 >> + MX25_PAD_UART1_TXD__UART1_TXD 0x00 >> MX25_PAD_UART1_RXD__UART1_RXD 0xc0 > > Are you sure here? According to the reference manual bit 0x40 of > IOMUXC_SW_PAD_CTL_PAD_UART1_RXD isn't valid. And my i.mx25 based machine > agrees: > > barebox@imx25:/ mw 0x43fac368 0xc0 > barebox@imx25:/ md 0x43fac368+4 > 43fac368: 00000080 Let me double check it when I get access to this board again. .... > > (This entry was fixed in my series to 0x80.) So you only checked the > NO_PAD_CTL values, right? Yes, I only checked the NO_PAD_CTL values.
On Tue, Jul 12, 2016 at 5:30 PM, Fabio Estevam <festevam@gmail.com> wrote: > Hi Uwe, > > On Tue, Jul 12, 2016 at 4:15 PM, Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > >>> @@ -244,7 +244,7 @@ >>> fsl,pins = < >>> MX25_PAD_UART1_RTS__UART1_RTS 0xe0 >>> MX25_PAD_UART1_CTS__UART1_CTS 0xe0 >>> - MX25_PAD_UART1_TXD__UART1_TXD 0x80000000 >>> + MX25_PAD_UART1_TXD__UART1_TXD 0x00 >>> MX25_PAD_UART1_RXD__UART1_RXD 0xc0 >> >> Are you sure here? According to the reference manual bit 0x40 of >> IOMUXC_SW_PAD_CTL_PAD_UART1_RXD isn't valid. And my i.mx25 based machine >> agrees: >> >> barebox@imx25:/ mw 0x43fac368 0xc0 >> barebox@imx25:/ md 0x43fac368+4 >> 43fac368: 00000080 > > Let me double check it when I get access to this board again. Sorry, I misread. You were referring to MX25_PAD_UART1_RXD__UART1_RXD, not MX25_PAD_UART1_TXD__UART1_TXD. I didn't touch MX25_PAD_UART1_RXD__UART1_RXD, so your series does the right thing for this pad (put it at 0x80).
Hello Fabio, On Tue, Jul 12, 2016 at 05:40:13PM -0300, Fabio Estevam wrote: > On Tue, Jul 12, 2016 at 5:30 PM, Fabio Estevam <festevam@gmail.com> wrote: > > On Tue, Jul 12, 2016 at 4:15 PM, Uwe Kleine-König > > <u.kleine-koenig@pengutronix.de> wrote: > > > >>> @@ -244,7 +244,7 @@ > >>> fsl,pins = < > >>> MX25_PAD_UART1_RTS__UART1_RTS 0xe0 > >>> MX25_PAD_UART1_CTS__UART1_CTS 0xe0 > >>> - MX25_PAD_UART1_TXD__UART1_TXD 0x80000000 > >>> + MX25_PAD_UART1_TXD__UART1_TXD 0x00 > >>> MX25_PAD_UART1_RXD__UART1_RXD 0xc0 > >> > >> Are you sure here? According to the reference manual bit 0x40 of > >> IOMUXC_SW_PAD_CTL_PAD_UART1_RXD isn't valid. And my i.mx25 based machine > >> agrees: > >> > >> barebox@imx25:/ mw 0x43fac368 0xc0 > >> barebox@imx25:/ md 0x43fac368+4 > >> 43fac368: 00000080 > > > > Let me double check it when I get access to this board again. > > Sorry, I misread. > > You were referring to MX25_PAD_UART1_RXD__UART1_RXD, not > MX25_PAD_UART1_TXD__UART1_TXD. > > I didn't touch MX25_PAD_UART1_RXD__UART1_RXD, so your series does the > right thing for this pad (put it at 0x80). OK. Which U-Boot did you test? Mainline or the vendor variant? Can you provide the output of md 0x43fac000+0x584 in U-Boot (which for sure has a different syntax that I don't know) and from Linux memtool md 0x43fac000+0x584 (or whatever different tool you prefer to do the same). Best regards Uwe
Hi Uwe, On Wed, Jul 13, 2016 at 3:25 AM, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Which U-Boot did you test? Mainline or the vendor variant? U-boot mainline. > Can you provide the output of > > md 0x43fac000+0x584 > > in U-Boot (which for sure has a different syntax that I don't know) and > from Linux > > memtool md 0x43fac000+0x584 > > (or whatever different tool you prefer to do the same). Sure, I will run such tests when I get access to the board again tomorrow.
Hi Uwe, On Wed, Jul 13, 2016 at 3:25 AM, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Which U-Boot did you test? Mainline or the vendor variant? > > Can you provide the output of > > md 0x43fac000+0x584 Here it goes: => md.l 0x43fac584 1 43fac584: 00000000 .... > > in U-Boot (which for sure has a different syntax that I don't know) and > from Linux > > memtool md 0x43fac000+0x584 The memtool utility version I have is broken for mx25, so I can't dump this register easily in Linux. Regards, Fabio Estevam
Hello Fabio, On Thu, Jul 14, 2016 at 02:04:14PM -0300, Fabio Estevam wrote: > On Wed, Jul 13, 2016 at 3:25 AM, Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > > Which U-Boot did you test? Mainline or the vendor variant? I assume the vendor variant, because your patch doesn't match what I saw in U-Boot mainline. > > Can you provide the output of > > > > md 0x43fac000+0x584 > > Here it goes: > => md.l 0x43fac584 1 > 43fac584: 00000000 .... I guess your tool (U-Boot?) would generate the output I want with: md.l 0x43fac000 353 (i.e. 353 32bit words, that are all the iomux registers) > > in U-Boot (which for sure has a different syntax that I don't know) and > > from Linux > > > > memtool md 0x43fac000+0x584 > > The memtool utility version I have is broken for mx25, so I can't dump > this register easily in Linux. Which version do you have? How is it broken? Did you configure AIPS to allow non-privileged access to the peripherals? Our internal documentation tells you have to set (in the boot loader) the following registers to 0: 0x43f00020 0x43f00024 0x43f00028 0x43f0002c 0x43f00040 0x43f00044 0x43f00048 0x43f0004c 0x43f00050 After that memtool works fine for me in Linux. Best regards Uwe
Hi Uwe, On Thu, Jul 14, 2016 at 3:34 PM, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > I assume the vendor variant, because your patch doesn't match what I saw > in U-Boot mainline. I am running U-boot 2016.07 from mainline. > I guess your tool (U-Boot?) would generate the output I want with: > > md.l 0x43fac000 353 > > (i.e. 353 32bit words, that are all the iomux registers) Here it goes: => md.l 0x43fac000 0x161 43fac000: 00000000 00000000 00000000 00000000 ................ 43fac010: 00000000 00000015 00000000 00000015 ................ 43fac020: 00000000 00000000 00000000 00000000 ................ 43fac030: 00000000 00000000 00000000 00000000 ................ 43fac040: 00000000 00000000 00000000 00000000 ................ 43fac050: 00000000 00000000 00000000 00000000 ................ 43fac060: 00000000 00000000 00000000 00000000 ................ 43fac070: 00000000 00000000 00000000 00000000 ................ 43fac080: 00000000 00000000 00000000 00000000 ................ 43fac090: 00000000 00000005 00000000 00000000 ................ 43fac0a0: 00000000 00000000 00000000 00000000 ................ 43fac0b0: 00000000 00000000 00000000 00000000 ................ 43fac0c0: 00000000 00000000 00000000 00000000 ................ 43fac0d0: 00000000 00000000 00000000 00000000 ................ 43fac0e0: 00000000 00000000 00000000 00000000 ................ 43fac0f0: 00000000 00000000 00000000 00000000 ................ 43fac100: 00000000 00000000 00000000 00000000 ................ 43fac110: 00000000 00000000 00000000 00000000 ................ 43fac120: 00000000 00000000 00000000 00000000 ................ 43fac130: 00000000 00000000 00000000 00000000 ................ 43fac140: 00000000 00000000 00000000 00000000 ................ 43fac150: 00000010 00000010 00000000 00000000 ................ 43fac160: 00000000 00000000 00000000 00000000 ................ 43fac170: 00000010 00000010 00000010 00000010 ................ 43fac180: 00000000 00000000 00000000 00000005 ................ 43fac190: 00000010 00000010 00000010 00000010 ................ 43fac1a0: 00000010 00000010 00000000 00000000 ................ 43fac1b0: 00000000 00000000 00000000 00000000 ................ 43fac1c0: 00000000 00000000 00000010 00000010 ................ 43fac1d0: 00000010 00000010 00000010 00000010 ................ 43fac1e0: 00000010 00000010 00000010 00000000 ................ 43fac1f0: 00000000 00000000 00000000 00000000 ................ 43fac200: 00000000 00000000 00000000 00000000 ................ 43fac210: 00000000 00000000 00000000 00000000 ................ 43fac220: 00000000 00000000 00000000 00000080 ................ 43fac230: 00000080 00000000 00000000 00000000 ................ 43fac240: 00000000 00000000 00000000 00000000 ................ 43fac250: 00000000 00000000 00000000 00000000 ................ 43fac260: 00000000 00002001 00002001 00000001 ..... ... ...... 43fac270: 00002080 00000000 00000000 00000080 . .............. 43fac280: 000000a1 000000a1 000000a1 00000000 ................ 43fac290: 00000021 000000a1 000000a1 000000a1 !............... 43fac2a0: 00000000 00000000 00000000 00000000 ................ 43fac2b0: 00000000 00000000 00000000 00000000 ................ 43fac2c0: 00000060 00000060 00000060 00000060 `...`...`...`... 43fac2d0: 00000060 00000060 00000060 00000060 `...`...`...`... 43fac2e0: 00000060 00000160 00000060 00000060 `...`...`...`... 43fac2f0: 00000060 00000060 00000020 00000060 `...`... ...`... 43fac300: 00000060 00000060 00000061 00000060 `...`...a...`... 43fac310: 00000060 000000c0 000000a1 000000a0 `............... 43fac320: 000001a1 000000a0 000000a0 000001a0 ................ 43fac330: 000000a0 000000a0 00000061 000000a0 ........a....... 43fac340: 000000a0 000001a0 000000a8 000000a8 ................ 43fac350: 000000a0 000000a0 000000e0 000000a0 ................ 43fac360: 000000a0 000000a0 000000a0 00000000 ................ 43fac370: 00000000 000000e0 000000e0 00000060 ............`... 43fac380: 000000e1 00000060 000000e1 000000d1 ....`........... 43fac390: 000000e1 000000d1 000000d1 000000e1 ................ 43fac3a0: 000000a0 000000a0 000000e0 000000e0 ................ 43fac3b0: 000000a8 000000a8 000000a8 000000a8 ................ 43fac3c0: 00000000 000001f0 00000000 00000000 ................ 43fac3d0: 00000000 000000c0 000000c0 000000c0 ................ 43fac3e0: 000001c0 00000062 00000002 00000000 ....b........... 43fac3f0: 00000040 000000c0 000000c0 00000020 @........... ... 43fac400: 000000a8 00000020 00000000 00000080 .... ........... 43fac410: 00000080 00000004 00000000 00000000 ................ 43fac420: 00000000 00000002 00000000 00000002 ................ 43fac430: 00000002 00000000 00000000 00000002 ................ 43fac440: 00000000 00000000 00000000 00000000 ................ 43fac450: 00000000 00001000 00000000 00000000 ................ 43fac460: 00000000 00000000 00000000 00000000 ................ 43fac470: 00000000 00000000 00000000 00000000 ................ 43fac480: 00000000 00000000 00000000 00000000 ................ 43fac490: 00000000 00000000 00000000 00000000 ................ 43fac4a0: 00000000 00000000 00000000 00000000 ................ 43fac4b0: 00000000 00000000 00000000 00000000 ................ 43fac4c0: 00000000 00000000 00000000 00000000 ................ 43fac4d0: 00000000 00000000 00000000 00000000 ................ 43fac4e0: 00000000 00000000 00000000 00000000 ................ 43fac4f0: 00000000 00000000 00000000 00000000 ................ 43fac500: 00000000 00000000 00000000 00000000 ................ 43fac510: 00000000 00000000 00000000 00000000 ................ 43fac520: 00000000 00000000 00000000 00000000 ................ 43fac530: 00000000 00000000 00000000 00000000 ................ 43fac540: 00000000 00000000 00000000 00000000 ................ 43fac550: 00000000 00000000 00000000 00000000 ................ 43fac560: 00000000 00000000 00000000 00000000 ................ 43fac570: 00000000 00000000 00000000 00000000 ................ 43fac580: 00000000 >> The memtool utility version I have is broken for mx25, so I can't dump >> this register easily in Linux. > > Which version do you have? How is it broken? Did you configure AIPS to The problem is that all IOMUX registers were returning the same incorrect values with memtool on mx25. > allow non-privileged access to the peripherals? Our internal > documentation tells you have to set (in the boot loader) the following > registers to 0: > > 0x43f00020 0x43f00024 0x43f00028 0x43f0002c > 0x43f00040 0x43f00044 0x43f00048 0x43f0004c 0x43f00050 > > After that memtool works fine for me in Linux. I will give this a try, thanks.
Hello Fabio, On Thu, Jul 14, 2016 at 04:16:59PM -0300, Fabio Estevam wrote: > I am running U-boot 2016.07 from mainline. hmm, ok. > > I guess your tool (U-Boot?) would generate the output I want with: > > > > md.l 0x43fac000 353 > > > > (i.e. 353 32bit words, that are all the iomux registers) > > Here it goes: > > [...] Thanks, will take a look. > >> The memtool utility version I have is broken for mx25, so I can't dump > >> this register easily in Linux. > > > > Which version do you have? How is it broken? Did you configure AIPS to > > The problem is that all IOMUX registers were returning the same > incorrect values with memtool on mx25. Yeah, that's the effect when the AIPS access control registers are not setup correctly. Best regards Uwe
From a2b9e24841909868803576c68c2d2b064a00d4a9 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam@nxp.com> Date: Tue, 12 Jul 2016 15:19:02 -0300 Subject: [PATCH] ARM: dts: imx25-pdk: Explicitly setup PAD config in dts When passing 0x80000000 as the PAD_CTL config value, the kernel does not touch the PAD_CTL egisters and use the value that comes from the bootloader. Instead of relying on the bootloader it is better to have the kernel to explicitly configure the PAD_CTL registers. Modified each 0x80000000 occurrance by reading the real PAD_CTL registers values in the bootloader and putting in the dts. Also tested by booting the resulting dtb. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> --- arch/arm/boot/dts/imx25-pdk.dts | 58 ++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/arch/arm/boot/dts/imx25-pdk.dts b/arch/arm/boot/dts/imx25-pdk.dts index 7029210..e997e2b 100644 --- a/arch/arm/boot/dts/imx25-pdk.dts +++ b/arch/arm/boot/dts/imx25-pdk.dts @@ -159,56 +159,56 @@ fsl,pins = < MX25_PAD_GPIO_A__CAN1_TX 0x0 MX25_PAD_GPIO_B__CAN1_RX 0x0 - MX25_PAD_D14__GPIO_4_6 0x80000000 + MX25_PAD_D14__GPIO_4_6 0xa1 >; }; pinctrl_esdhc1: esdhc1grp { fsl,pins = < - MX25_PAD_SD1_CMD__SD1_CMD 0x80000000 - MX25_PAD_SD1_CLK__SD1_CLK 0x80000000 - MX25_PAD_SD1_DATA0__SD1_DATA0 0x80000000 - MX25_PAD_SD1_DATA1__SD1_DATA1 0x80000000 - MX25_PAD_SD1_DATA2__SD1_DATA2 0x80000000 - MX25_PAD_SD1_DATA3__SD1_DATA3 0x80000000 - MX25_PAD_A14__GPIO_2_0 0x80000000 - MX25_PAD_A15__GPIO_2_1 0x80000000 + MX25_PAD_SD1_CMD__SD1_CMD 0xe1 + MX25_PAD_SD1_CLK__SD1_CLK 0xd1 + MX25_PAD_SD1_DATA0__SD1_DATA0 0xe1 + MX25_PAD_SD1_DATA1__SD1_DATA1 0xd1 + MX25_PAD_SD1_DATA2__SD1_DATA2 0xd1 + MX25_PAD_SD1_DATA3__SD1_DATA3 0xe1 + MX25_PAD_A14__GPIO_2_0 0x80 + MX25_PAD_A15__GPIO_2_1 0x00 >; }; pinctrl_fec: fecgrp { fsl,pins = < - MX25_PAD_FEC_MDC__FEC_MDC 0x80000000 + MX25_PAD_FEC_MDC__FEC_MDC 0x00 MX25_PAD_FEC_MDIO__FEC_MDIO 0x400001e0 - 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_TDATA0__FEC_TDATA0 0x00 + MX25_PAD_FEC_TDATA1__FEC_TDATA1 0x00 + MX25_PAD_FEC_TX_EN__FEC_TX_EN 0x00 + MX25_PAD_FEC_RDATA0__FEC_RDATA0 0xc0 + MX25_PAD_FEC_RDATA1__FEC_RDATA1 0xc0 + MX25_PAD_FEC_RX_DV__FEC_RX_DV 0xc0 MX25_PAD_FEC_TX_CLK__FEC_TX_CLK 0x1c0 - MX25_PAD_A17__GPIO_2_3 0x80000000 - MX25_PAD_D12__GPIO_4_8 0x80000000 + MX25_PAD_A17__GPIO_2_3 0x00 + MX25_PAD_D12__GPIO_4_8 0x00 >; }; pinctrl_i2c1: i2c1grp { fsl,pins = < - MX25_PAD_I2C1_CLK__I2C1_CLK 0x80000000 - MX25_PAD_I2C1_DAT__I2C1_DAT 0x80000000 + MX25_PAD_I2C1_CLK__I2C1_CLK 0xa8 + MX25_PAD_I2C1_DAT__I2C1_DAT 0xa8 >; }; pinctrl_kpp: kppgrp { fsl,pins = < - MX25_PAD_KPP_ROW0__KPP_ROW0 0x80000000 - MX25_PAD_KPP_ROW1__KPP_ROW1 0x80000000 - MX25_PAD_KPP_ROW2__KPP_ROW2 0x80000000 - MX25_PAD_KPP_ROW3__KPP_ROW3 0x80000000 - MX25_PAD_KPP_COL0__KPP_COL0 0x80000000 - MX25_PAD_KPP_COL1__KPP_COL1 0x80000000 - MX25_PAD_KPP_COL2__KPP_COL2 0x80000000 - MX25_PAD_KPP_COL3__KPP_COL3 0x80000000 + MX25_PAD_KPP_ROW0__KPP_ROW0 0xa0 + MX25_PAD_KPP_ROW1__KPP_ROW1 0xa0 + MX25_PAD_KPP_ROW2__KPP_ROW2 0xe0 + MX25_PAD_KPP_ROW3__KPP_ROW3 0xe0 + MX25_PAD_KPP_COL0__KPP_COL0 0xa8 + MX25_PAD_KPP_COL1__KPP_COL1 0xa8 + MX25_PAD_KPP_COL2__KPP_COL2 0xa8 + MX25_PAD_KPP_COL3__KPP_COL3 0xa8 >; }; @@ -244,7 +244,7 @@ fsl,pins = < MX25_PAD_UART1_RTS__UART1_RTS 0xe0 MX25_PAD_UART1_CTS__UART1_CTS 0xe0 - MX25_PAD_UART1_TXD__UART1_TXD 0x80000000 + MX25_PAD_UART1_TXD__UART1_TXD 0x00 MX25_PAD_UART1_RXD__UART1_RXD 0xc0 >; }; -- 1.9.1
Hi Uwe, On Tue, Jul 12, 2016 at 12:15 PM, Fabio Estevam <festevam@gmail.com> wrote: > I will try to get access to a mx25pdk and will confirm soon. Thanks Please find attached the patch after reading all the PAD_CTL registers. Feel free to submit it as part of your series.