| Message ID | 20230213155833.1644366-7-frieder@fris.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Use correct LDO5 control registers for PCA9450 | expand |
On 2/13/23 16:58, Frieder Schrempf wrote: > From: Frieder Schrempf <frieder.schrempf@kontron.de> > > This fixes the LDO5 regulator handling of the pca9450 driver by > taking the status of the SD_VSEL into account to determine which > configuration register is used for the voltage setting. > > Even without this change there is no functional issue, as the code > for switching the voltage in sdhci.c currently switches both, the > VSELECT/SD_VSEL signal and the regulator voltage at the same time > and doesn't run into an invalid corner case. > > We should still make sure, that we always use the correct register > when controlling the regulator. At least in U-Boot this fixes an > actual bug where the wrong IO voltage is used. > > Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> I may have a kind-of obvious request, since we removed those SD_VSEL very recently from other boards, could you just revert all those patches and only fill in the SION bit in V2 on all those boards too ? That way, we fix the LDO5 regulator for everyone who used it before.
On 13.02.23 17:08, Marek Vasut wrote: > On 2/13/23 16:58, Frieder Schrempf wrote: >> From: Frieder Schrempf <frieder.schrempf@kontron.de> >> >> This fixes the LDO5 regulator handling of the pca9450 driver by >> taking the status of the SD_VSEL into account to determine which >> configuration register is used for the voltage setting. >> >> Even without this change there is no functional issue, as the code >> for switching the voltage in sdhci.c currently switches both, the >> VSELECT/SD_VSEL signal and the regulator voltage at the same time >> and doesn't run into an invalid corner case. >> >> We should still make sure, that we always use the correct register >> when controlling the regulator. At least in U-Boot this fixes an >> actual bug where the wrong IO voltage is used. >> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> > > I may have a kind-of obvious request, since we removed those SD_VSEL > very recently from other boards, could you just revert all those patches > and only fill in the SION bit in V2 on all those boards too ? That way, > we fix the LDO5 regulator for everyone who used it before. I thought about that, but as the SD_VSEL signal is controlling the LDO5, I found it more useful/correct to have the sd-vsel-gpios property inside the LDO5 regulator node. Therefore the old usage where sd-vsel-gpios was inside the PMIC node isn't compatible anymore.
Hi Frieder, thanks for the patch. On 23-02-13, Frieder Schrempf wrote: > From: Frieder Schrempf <frieder.schrempf@kontron.de> > > This fixes the LDO5 regulator handling of the pca9450 driver by > taking the status of the SD_VSEL into account to determine which > configuration register is used for the voltage setting. > > Even without this change there is no functional issue, as the code > for switching the voltage in sdhci.c currently switches both, the > VSELECT/SD_VSEL signal and the regulator voltage at the same time > and doesn't run into an invalid corner case. > > We should still make sure, that we always use the correct register > when controlling the regulator. At least in U-Boot this fixes an > actual bug where the wrong IO voltage is used. > > Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> > --- > arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 6 +++--- > arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 6 +++--- > arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 1 + > arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 1 + > 4 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts > index 8b16bd68576c..bdcd9cd843c7 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts > @@ -344,7 +344,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -357,7 +357,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -370,7 +370,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts > index a079322a3793..ba2a4491cf31 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts > @@ -321,7 +321,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -334,7 +334,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >; > }; > > @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 The VSELECT pin should be driven by the (u)sdhc core... > >; > }; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > index 5172883717d1..90daaf54e704 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > regulator-name = "NVCC_SD (LDO5)"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3300000>; > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be muxed as GPIO, which is not the case. So I think that u-boot have a bug within the (u)sdhc core. Regards, Marco > }; > }; > }; > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi > index 1f8326613ee9..7468a8aa771d 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi > @@ -195,6 +195,7 @@ reg_nvcc_sd: LDO5 { > regulator-name = "NVCC_SD (LDO5)"; > regulator-min-microvolt = <1800000>; > regulator-max-microvolt = <3300000>; > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > }; > }; > }; > -- > 2.39.1 > > >
On 13.02.23 17:15, Marco Felsch wrote: > Hi Frieder, > > thanks for the patch. > > On 23-02-13, Frieder Schrempf wrote: >> From: Frieder Schrempf <frieder.schrempf@kontron.de> >> >> This fixes the LDO5 regulator handling of the pca9450 driver by >> taking the status of the SD_VSEL into account to determine which >> configuration register is used for the voltage setting. >> >> Even without this change there is no functional issue, as the code >> for switching the voltage in sdhci.c currently switches both, the >> VSELECT/SD_VSEL signal and the regulator voltage at the same time >> and doesn't run into an invalid corner case. >> >> We should still make sure, that we always use the correct register >> when controlling the regulator. At least in U-Boot this fixes an >> actual bug where the wrong IO voltage is used. >> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> >> --- >> arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 6 +++--- >> arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 6 +++--- >> arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 1 + >> arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 1 + >> 4 files changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts >> index 8b16bd68576c..bdcd9cd843c7 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts >> @@ -344,7 +344,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -357,7 +357,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -370,7 +370,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> }; >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts >> index a079322a3793..ba2a4491cf31 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts >> @@ -321,7 +321,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -334,7 +334,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >> >; >> }; >> >> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > The VSELECT pin should be driven by the (u)sdhc core... > >> >; >> }; >> }; >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> index 5172883717d1..90daaf54e704 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >> regulator-name = "NVCC_SD (LDO5)"; >> regulator-min-microvolt = <1800000>; >> regulator-max-microvolt = <3300000>; >> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > muxed as GPIO, which is not the case. So I think that u-boot have a bug > within the (u)sdhc core. No, we don't mux the signal as GPIO. We still use the VSLECT mux option, but enable the SION bit, so we can read back the current state of the VSELECT signal via the GPIO.
On 2/13/23 17:15, Marco Felsch wrote: [...] >> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > The VSELECT pin should be driven by the (u)sdhc core... > >> >; >> }; >> }; >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> index 5172883717d1..90daaf54e704 100644 >> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >> regulator-name = "NVCC_SD (LDO5)"; >> regulator-min-microvolt = <1800000>; >> regulator-max-microvolt = <3300000>; >> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > muxed as GPIO, which is not the case. So I think that u-boot have a bug > within the (u)sdhc core. The trick here is that the VSELECT is operated by the usdhc block as a function pin, but the PMIC driver can read the current state of the VSELECT pin by reading out the GPIO block SR register. Since the IOMUX SION bit is set on the VSELECT pin, the state of the pin is reflected in the GPIO block SR register even if the pin is muxed as function pin.
Hi Marek, Frieder, On 23-02-13, Marek Vasut wrote: > On 2/13/23 17:15, Marco Felsch wrote: > > [...] > > > > @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > > > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > > > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > > > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > > > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > > > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > > > The VSELECT pin should be driven by the (u)sdhc core... > > > > > >; > > > }; > > > }; > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > index 5172883717d1..90daaf54e704 100644 > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > > > regulator-name = "NVCC_SD (LDO5)"; > > > regulator-min-microvolt = <1800000>; > > > regulator-max-microvolt = <3300000>; > > > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > > muxed as GPIO, which is not the case. So I think that u-boot have a bug > > within the (u)sdhc core. > > The trick here is that the VSELECT is operated by the usdhc block as a > function pin, but the PMIC driver can read the current state of the VSELECT > pin by reading out the GPIO block SR register. Since the IOMUX SION bit is > set on the VSELECT pin, the state of the pin is reflected in the GPIO block > SR register even if the pin is muxed as function pin. > Thanks for this explanation :) Why does the regulator driver need to know the current state of this pin? Since the voltage switching requires some cmd's before the actual voltage level switch. So this must be handled within the core. Also after checking the driver, adding the sd-vsel-gpios will request the specified gpio as output-high. Out of curiosity, what's the bug you triggering within U-Boot? Regards, Marco
On 2/13/23 20:56, Marco Felsch wrote: > Hi Marek, Frieder, Hi, > On 23-02-13, Marek Vasut wrote: >> On 2/13/23 17:15, Marco Felsch wrote: >> >> [...] >> >>>> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >>>> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >>>> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >>>> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >>>> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >>>> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >>> >>> The VSELECT pin should be driven by the (u)sdhc core... >>> >>>> >; >>>> }; >>>> }; >>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>> index 5172883717d1..90daaf54e704 100644 >>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >>>> regulator-name = "NVCC_SD (LDO5)"; >>>> regulator-min-microvolt = <1800000>; >>>> regulator-max-microvolt = <3300000>; >>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; >>> >>> and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be >>> muxed as GPIO, which is not the case. So I think that u-boot have a bug >>> within the (u)sdhc core. >> >> The trick here is that the VSELECT is operated by the usdhc block as a >> function pin, but the PMIC driver can read the current state of the VSELECT >> pin by reading out the GPIO block SR register. Since the IOMUX SION bit is >> set on the VSELECT pin, the state of the pin is reflected in the GPIO block >> SR register even if the pin is muxed as function pin. >> > > Thanks for this explanation :) Why does the regulator driver need to > know the current state of this pin? Because that regulator has an input pin which selects between two states of that regulator, L and H, and whatever L or H is depends on what is configured into the regulator via I2C. To correctly report the state of the regulator, you have to know the state of that input (selector) pin. > Since the voltage switching requires > some cmd's before the actual voltage level switch. So this must be > handled within the core. > > Also after checking the driver, adding the sd-vsel-gpios will request > the specified gpio as output-high. The GPIO would have to be requested as input, obviously. > Out of curiosity, what's the bug you > triggering within U-Boot? AFAICT the readback of the initial state of the regulator (see paragraph above), which affects Linux all the same.
Hi Frieder, On Mon, Feb 13, 2023 at 1:19 PM Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > No, we don't mux the signal as GPIO. We still use the VSLECT mux option, > but enable the SION bit, so we can read back the current state of the > VSELECT signal via the GPIO. Please include this explanation in the commit log.
On 23-02-13, Marek Vasut wrote: > On 2/13/23 20:56, Marco Felsch wrote: > > Hi Marek, Frieder, > > Hi, > > > On 23-02-13, Marek Vasut wrote: > > > On 2/13/23 17:15, Marco Felsch wrote: > > > > > > [...] > > > > > > > > @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > > > > > MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > > > > > MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > > > > > MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > > > > > - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > > > > > + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > > > > > > > > The VSELECT pin should be driven by the (u)sdhc core... > > > > > > > > > >; > > > > > }; > > > > > }; > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > > > index 5172883717d1..90daaf54e704 100644 > > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > > > > > @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > > > > > regulator-name = "NVCC_SD (LDO5)"; > > > > > regulator-min-microvolt = <1800000>; > > > > > regulator-max-microvolt = <3300000>; > > > > > + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > > > > > > > > and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > > > > muxed as GPIO, which is not the case. So I think that u-boot have a bug > > > > within the (u)sdhc core. > > > > > > The trick here is that the VSELECT is operated by the usdhc block as a > > > function pin, but the PMIC driver can read the current state of the VSELECT > > > pin by reading out the GPIO block SR register. Since the IOMUX SION bit is > > > set on the VSELECT pin, the state of the pin is reflected in the GPIO block > > > SR register even if the pin is muxed as function pin. > > > > > > > Thanks for this explanation :) Why does the regulator driver need to > > know the current state of this pin? > > Because that regulator has an input pin which selects between two states of > that regulator, L and H, and whatever L or H is depends on what is > configured into the regulator via I2C. To correctly report the state of the > regulator, you have to know the state of that input (selector) pin. > > > Since the voltage switching requires > > some cmd's before the actual voltage level switch. So this must be > > handled within the core. > > > > Also after checking the driver, adding the sd-vsel-gpios will request > > the specified gpio as output-high. > > The GPIO would have to be requested as input, obviously. But that isn't the case. According the driver comment they just want to make sure that this GPIO is high to ensure that the correct regulator config registers are used. > > Out of curiosity, what's the bug you > > triggering within U-Boot? > > AFAICT the readback of the initial state of the regulator (see paragraph > above), which affects Linux all the same. According the binding the driver should check this and apply the value to the corresponding L/H register but unfortunately this isn't the case yet. Does U-Boot handle this correctly? Regards, Marco
Hi Marco, On 14.02.23 09:10, Marco Felsch wrote: > On 23-02-13, Marek Vasut wrote: >> On 2/13/23 20:56, Marco Felsch wrote: >>> Hi Marek, Frieder, >> >> Hi, >> >>> On 23-02-13, Marek Vasut wrote: >>>> On 2/13/23 17:15, Marco Felsch wrote: >>>> >>>> [...] >>>> >>>>>> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 >>>>>> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 >>>>>> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 >>>>>> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 >>>>>> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 >>>>>> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >>>>> >>>>> The VSELECT pin should be driven by the (u)sdhc core... >>>>> >>>>>> >; >>>>>> }; >>>>>> }; >>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>>>> index 5172883717d1..90daaf54e704 100644 >>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi >>>>>> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { >>>>>> regulator-name = "NVCC_SD (LDO5)"; >>>>>> regulator-min-microvolt = <1800000>; >>>>>> regulator-max-microvolt = <3300000>; >>>>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; >>>>> >>>>> and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be >>>>> muxed as GPIO, which is not the case. So I think that u-boot have a bug >>>>> within the (u)sdhc core. >>>> >>>> The trick here is that the VSELECT is operated by the usdhc block as a >>>> function pin, but the PMIC driver can read the current state of the VSELECT >>>> pin by reading out the GPIO block SR register. Since the IOMUX SION bit is >>>> set on the VSELECT pin, the state of the pin is reflected in the GPIO block >>>> SR register even if the pin is muxed as function pin. >>>> >>> >>> Thanks for this explanation :) Why does the regulator driver need to >>> know the current state of this pin? >> >> Because that regulator has an input pin which selects between two states of >> that regulator, L and H, and whatever L or H is depends on what is >> configured into the regulator via I2C. To correctly report the state of the >> regulator, you have to know the state of that input (selector) pin. >> >>> Since the voltage switching requires >>> some cmd's before the actual voltage level switch. So this must be >>> handled within the core. >>> >>> Also after checking the driver, adding the sd-vsel-gpios will request >>> the specified gpio as output-high. >> >> The GPIO would have to be requested as input, obviously. > > But that isn't the case. According the driver comment they just want to > make sure that this GPIO is high to ensure that the correct regulator > config registers are used. It seems like you look at the wrong code. We previously had the sd-vsel-gpios used as you describe, as an output set to a fixed high level to make sure that the SD_VSEL state matches the driver using the H register. This code is reverted in patch 3 and patch 5 implements the sd-vsel-gpios as input as described by Marek. See: https://lore.kernel.org/lkml/20230213155833.1644366-4-frieder@fris.de/ https://lore.kernel.org/lkml/20230213155833.1644366-6-frieder@fris.de/ Sorry, my scripts didn't cc everyone for all patches, which is probably why you missed these changes. > >>> Out of curiosity, what's the bug you >>> triggering within U-Boot? >> >> AFAICT the readback of the initial state of the regulator (see paragraph >> above), which affects Linux all the same. > > According the binding the driver should check this and apply the value > to the corresponding L/H register but unfortunately this isn't the case > yet. Does U-Boot handle this correctly? See above. Thanks Frieder
On 23-02-14, Frieder Schrempf wrote: > Hi Marco, > > On 14.02.23 09:10, Marco Felsch wrote: > > On 23-02-13, Marek Vasut wrote: > >> On 2/13/23 20:56, Marco Felsch wrote: > >>> Hi Marek, Frieder, > >> > >> Hi, > >> > >>> On 23-02-13, Marek Vasut wrote: > >>>> On 2/13/23 17:15, Marco Felsch wrote: > >>>> > >>>> [...] > >>>> > >>>>>> @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 > >>>>>> MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 > >>>>>> MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 > >>>>>> MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 > >>>>>> - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 > >>>>>> + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 > >>>>> > >>>>> The VSELECT pin should be driven by the (u)sdhc core... > >>>>> > >>>>>> >; > >>>>>> }; > >>>>>> }; > >>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > >>>>>> index 5172883717d1..90daaf54e704 100644 > >>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > >>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi > >>>>>> @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { > >>>>>> regulator-name = "NVCC_SD (LDO5)"; > >>>>>> regulator-min-microvolt = <1800000>; > >>>>>> regulator-max-microvolt = <3300000>; > >>>>>> + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; > >>>>> > >>>>> and by using the sd-vsel-gpios property the IOMUXC_GPIO1_IO04 have to be > >>>>> muxed as GPIO, which is not the case. So I think that u-boot have a bug > >>>>> within the (u)sdhc core. > >>>> > >>>> The trick here is that the VSELECT is operated by the usdhc block as a > >>>> function pin, but the PMIC driver can read the current state of the VSELECT > >>>> pin by reading out the GPIO block SR register. Since the IOMUX SION bit is > >>>> set on the VSELECT pin, the state of the pin is reflected in the GPIO block > >>>> SR register even if the pin is muxed as function pin. > >>>> > >>> > >>> Thanks for this explanation :) Why does the regulator driver need to > >>> know the current state of this pin? > >> > >> Because that regulator has an input pin which selects between two states of > >> that regulator, L and H, and whatever L or H is depends on what is > >> configured into the regulator via I2C. To correctly report the state of the > >> regulator, you have to know the state of that input (selector) pin. > >> > >>> Since the voltage switching requires > >>> some cmd's before the actual voltage level switch. So this must be > >>> handled within the core. > >>> > >>> Also after checking the driver, adding the sd-vsel-gpios will request > >>> the specified gpio as output-high. > >> > >> The GPIO would have to be requested as input, obviously. > > > > But that isn't the case. According the driver comment they just want to > > make sure that this GPIO is high to ensure that the correct regulator > > config registers are used. > > It seems like you look at the wrong code. We previously had the > sd-vsel-gpios used as you describe, as an output set to a fixed high > level to make sure that the SD_VSEL state matches the driver using the H > register. This code is reverted in patch 3 and patch 5 implements the > sd-vsel-gpios as input as described by Marek. See: > > https://lore.kernel.org/lkml/20230213155833.1644366-4-frieder@fris.de/ > https://lore.kernel.org/lkml/20230213155833.1644366-6-frieder@fris.de/ > > Sorry, my scripts didn't cc everyone for all patches, which is probably > why you missed these changes. Ah okay this brings light into the dark :) Thanks for the pointers, just received the DT changes. Regards, Marco
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts index 8b16bd68576c..bdcd9cd843c7 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts @@ -344,7 +344,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -357,7 +357,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -370,7 +370,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; }; diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts index a079322a3793..ba2a4491cf31 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts @@ -321,7 +321,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -334,7 +334,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; @@ -347,7 +347,7 @@ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x400001d0 >; }; }; diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi index 5172883717d1..90daaf54e704 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi @@ -196,6 +196,7 @@ reg_nvcc_sd: LDO5 { regulator-name = "NVCC_SD (LDO5)"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; }; }; }; diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi index 1f8326613ee9..7468a8aa771d 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi @@ -195,6 +195,7 @@ reg_nvcc_sd: LDO5 { regulator-name = "NVCC_SD (LDO5)"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; + sd-vsel-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; }; }; };