| Message ID | 20180921085948.26975-5-heiko@sntech.de |
|---|---|
| State | Accepted |
| Commit | e4d5fa3db0b9ad6551752f90b153d64706bbddef |
| Delegated to: | Philipp Tomsich |
| Headers | show |
| Series | rockchip: allow rk3188 to boot from mmc devices | expand |
> On 21.09.2018, at 10:59, Heiko Stuebner <heiko@sntech.de> wrote: > > It is good practice to make the setting of gpio-pinctrls explicitly in the > devicetree, and in this case even necessary. > Rockchip boards start with iomux settings set to gpio for most pins and > while the linux pinctrl driver also implicitly sets the gpio function if > a pin is requested as gpio that is not necessarily true for other drivers. > > The issue in question stems from uboot, where the sdmmc_pwr pin is set > to function 1 (sdmmc-power) by the bootrom when reading the 1st-stage > loader. The regulator controlled by the pin is active-low though, so > when the dwmmc hw-block sets its enabled bit, it actually disables the > regulator. By changing the pin back to gpio we fix that behaviour. > > [picked from the identical linux patch > https://patchwork.kernel.org/patch/10609253/] > Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
> It is good practice to make the setting of gpio-pinctrls explicitly in the > devicetree, and in this case even necessary. > Rockchip boards start with iomux settings set to gpio for most pins and > while the linux pinctrl driver also implicitly sets the gpio function if > a pin is requested as gpio that is not necessarily true for other drivers. > > The issue in question stems from uboot, where the sdmmc_pwr pin is set > to function 1 (sdmmc-power) by the bootrom when reading the 1st-stage > loader. The regulator controlled by the pin is active-low though, so > when the dwmmc hw-block sets its enabled bit, it actually disables the > regulator. By changing the pin back to gpio we fix that behaviour. > > [picked from the identical linux patch > https://patchwork.kernel.org/patch/10609253/] > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> > Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> > --- > arch/arm/dts/rk3188-radxarock.dts | 8 ++++++++ > 1 file changed, 8 insertions(+) > Applied to u-boot-rockchip, thanks!
diff --git a/arch/arm/dts/rk3188-radxarock.dts b/arch/arm/dts/rk3188-radxarock.dts index ac931e14af..61367126ba 100644 --- a/arch/arm/dts/rk3188-radxarock.dts +++ b/arch/arm/dts/rk3188-radxarock.dts @@ -104,6 +104,8 @@ regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&gpio3 1 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc_pwr>; startup-delay-us = <100000>; vin-supply = <&vcc_io>; }; @@ -334,6 +336,12 @@ }; }; + sd0 { + sdmmc_pwr: sdmmc-pwr { + rockchip,pins = <RK_GPIO3 1 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + usb { host_vbus_drv: host-vbus-drv { rockchip,pins = <0 3 RK_FUNC_GPIO &pcfg_pull_none>;
It is good practice to make the setting of gpio-pinctrls explicitly in the devicetree, and in this case even necessary. Rockchip boards start with iomux settings set to gpio for most pins and while the linux pinctrl driver also implicitly sets the gpio function if a pin is requested as gpio that is not necessarily true for other drivers. The issue in question stems from uboot, where the sdmmc_pwr pin is set to function 1 (sdmmc-power) by the bootrom when reading the 1st-stage loader. The regulator controlled by the pin is active-low though, so when the dwmmc hw-block sets its enabled bit, it actually disables the regulator. By changing the pin back to gpio we fix that behaviour. [picked from the identical linux patch https://patchwork.kernel.org/patch/10609253/] Signed-off-by: Heiko Stuebner <heiko@sntech.de> --- arch/arm/dts/rk3188-radxarock.dts | 8 ++++++++ 1 file changed, 8 insertions(+)