| Message ID | 1386899355-17379-6-git-send-email-troy.kisky@boundarydevices.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: > Don't use 0x80000000 to get default pad settings. What is the rationale behind this change please? Can you explain more in detail? > Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> > --- > arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi > b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi index be899d3..b548647 100644 > --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi > +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi > @@ -114,13 +114,13 @@ > imx6q-sabrelite { > pinctrl_hog: hoggrp { > fsl,pins = < > -/* uSDHC4 CD */ MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000 > -/* spi-nor CS */ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000 > -/* otg power en */ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000 > -/* ethernet phy reset */ MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x80000000 > -/* USDHC3 CD */ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000 > -/* USDHC3 WP */ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0 > -/* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x80000000 > +/* uSDHC4 CD */ MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x1b0b0 > +/* spi-nor CS */ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x1b0b0 > +/* otg power en */ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0 > +/* ethernet phy reset */ MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x000b0 > +/* USDHC3 CD */ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1b0b0 > +/* USDHC3 WP */ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0 > +/* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x000b0 > > >; > > }; Best regards, Marek Vasut
On 12/13/2013 4:48 AM, Marek Vasut wrote: > On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: >> Don't use 0x80000000 to get default pad settings. > What is the rationale behind this change please? Can you explain more in detail? > No real need, but I thought relying on what the boot loader did or did not do was discouraged? What is the value in not explicitly setting the pad registers? Btw, I need to rebase series on your patch anyway so omitting this patch would be easy. Thanks Troy
On Friday, December 13, 2013 at 07:42:25 PM, Troy Kisky wrote: > On 12/13/2013 4:48 AM, Marek Vasut wrote: > > On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: > >> Don't use 0x80000000 to get default pad settings. > > > > What is the rationale behind this change please? Can you explain more in > > detail? > > No real need, but I thought relying on what the boot loader did or did > not do > was discouraged? Full ACK on this, we do not rely on bootloader configuration (though these two should be in-line). > What is the value in not explicitly setting the pad registers? My question was in the direction of "why do you need to change the pin configuration values from the current ones?". This is what I want to understand. > Btw, I need to rebase series on your patch anyway so omitting this patch > would be easy. I am not saying to omit it, please do not misunderstand me. I am just wondering why the change from 0x80000000 to 0x1b0b0 . Best regards, Marek Vasut
On 12/13/2013 2:50 PM, Marek Vasut wrote: > On Friday, December 13, 2013 at 07:42:25 PM, Troy Kisky wrote: >> On 12/13/2013 4:48 AM, Marek Vasut wrote: >>> On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: >>>> Don't use 0x80000000 to get default pad settings. >>> What is the rationale behind this change please? Can you explain more in >>> detail? >> No real need, but I thought relying on what the boot loader did or did >> not do >> was discouraged? > Full ACK on this, we do not rely on bootloader configuration (though these two > should be in-line). > >> What is the value in not explicitly setting the pad registers? > My question was in the direction of "why do you need to change the pin > configuration values from the current ones?". This is what I want to understand. > >> Btw, I need to rebase series on your patch anyway so omitting this patch >> would be easy. > I am not saying to omit it, please do not misunderstand me. I am just wondering > why the change from 0x80000000 to 0x1b0b0 . > > Best regards, > Marek Vasut > O.K., I'll change the commit log to say exact what is changing, since it is very hard to tell from the patch. I should have done that without needing the prompt :-) Thanks Troy
On Saturday, December 14, 2013 at 02:44:53 AM, Troy Kisky wrote: > On 12/13/2013 2:50 PM, Marek Vasut wrote: > > On Friday, December 13, 2013 at 07:42:25 PM, Troy Kisky wrote: > >> On 12/13/2013 4:48 AM, Marek Vasut wrote: > >>> On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: > >>>> Don't use 0x80000000 to get default pad settings. > >>> > >>> What is the rationale behind this change please? Can you explain more > >>> in detail? > >> > >> No real need, but I thought relying on what the boot loader did or did > >> not do > >> was discouraged? > > > > Full ACK on this, we do not rely on bootloader configuration (though > > these two should be in-line). > > > >> What is the value in not explicitly setting the pad registers? > > > > My question was in the direction of "why do you need to change the pin > > configuration values from the current ones?". This is what I want to > > understand. > > > >> Btw, I need to rebase series on your patch anyway so omitting this patch > >> would be easy. > > > > I am not saying to omit it, please do not misunderstand me. I am just > > wondering why the change from 0x80000000 to 0x1b0b0 . > > > > Best regards, > > Marek Vasut > > O.K., I'll change the commit log to say exact what is changing, since it > is very hard to tell > from the patch. I should have done that without needing the prompt :-) I am trying to understand what happens here hardware-wise. Is the signal on the pins better with this change or what ? Best regards, Marek Vasut
On Fri, Dec 13, 2013 at 10:50:29PM +0100, Marek Vasut wrote: > On Friday, December 13, 2013 at 07:42:25 PM, Troy Kisky wrote: > > On 12/13/2013 4:48 AM, Marek Vasut wrote: > > > On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: > > >> Don't use 0x80000000 to get default pad settings. > > > > > > What is the rationale behind this change please? Can you explain more in > > > detail? > > > > No real need, but I thought relying on what the boot loader did or did > > not do > > was discouraged? > > Full ACK on this, we do not rely on bootloader configuration (though these two > should be in-line). > > > What is the value in not explicitly setting the pad registers? > > My question was in the direction of "why do you need to change the pin > configuration values from the current ones?". This is what I want to understand. > > > Btw, I need to rebase series on your patch anyway so omitting this patch > > would be easy. > > I am not saying to omit it, please do not misunderstand me. I am just wondering > why the change from 0x80000000 to 0x1b0b0 . Per Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt, Bits used for CONFIG: NO_PAD_CTL(1 << 31): indicate this pin does not need config. 0x80000000 tells pinctrl driver to not touch pad config register at all. In that case, the configuration of the pad will be what boot loader configures or just the reset value. Explicitly putting a proper pad config value instead of 0x80000000 should be something we encourage. Shawn
On Saturday, December 14, 2013 at 02:29:07 PM, Shawn Guo wrote: > On Fri, Dec 13, 2013 at 10:50:29PM +0100, Marek Vasut wrote: > > On Friday, December 13, 2013 at 07:42:25 PM, Troy Kisky wrote: > > > On 12/13/2013 4:48 AM, Marek Vasut wrote: > > > > On Friday, December 13, 2013 at 02:49:09 AM, Troy Kisky wrote: > > > >> Don't use 0x80000000 to get default pad settings. > > > > > > > > What is the rationale behind this change please? Can you explain more > > > > in detail? > > > > > > No real need, but I thought relying on what the boot loader did or did > > > not do > > > was discouraged? > > > > Full ACK on this, we do not rely on bootloader configuration (though > > these two should be in-line). > > > > > What is the value in not explicitly setting the pad registers? > > > > My question was in the direction of "why do you need to change the pin > > configuration values from the current ones?". This is what I want to > > understand. > > > > > Btw, I need to rebase series on your patch anyway so omitting this > > > patch would be easy. > > > > I am not saying to omit it, please do not misunderstand me. I am just > > wondering why the change from 0x80000000 to 0x1b0b0 . > > Per Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt, > > Bits used for CONFIG: > NO_PAD_CTL(1 << 31): indicate this pin does not need config. > > 0x80000000 tells pinctrl driver to not touch pad config register at all. > In that case, the configuration of the pad will be what boot loader > configures or just the reset value. > > Explicitly putting a proper pad config value instead of 0x80000000 > should be something we encourage. Gotcha, thanks! Best regards, Marek Vasut
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi index be899d3..b548647 100644 --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi @@ -114,13 +114,13 @@ imx6q-sabrelite { pinctrl_hog: hoggrp { fsl,pins = < -/* uSDHC4 CD */ MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x80000000 -/* spi-nor CS */ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x80000000 -/* otg power en */ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000 -/* ethernet phy reset */ MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x80000000 -/* USDHC3 CD */ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x80000000 -/* USDHC3 WP */ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0 -/* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x80000000 +/* uSDHC4 CD */ MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x1b0b0 +/* spi-nor CS */ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x1b0b0 +/* otg power en */ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0 +/* ethernet phy reset */ MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x000b0 +/* USDHC3 CD */ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1b0b0 +/* USDHC3 WP */ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0 +/* SGTL5000 sys_mclk */ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x000b0 >; };
Don't use 0x80000000 to get default pad settings. Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> --- arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)