[PATCH] arm64: dts: rockchip: fix USB regulator on ROCK64

[Peter Geis]

On Wed, Jan 4, 2023 at 6:52 PM Heiko Stübner <heiko at sntech.de> wrote:
>
> Am Donnerstag, 5. Januar 2023, 00:46:25 CET schrieb Peter Geis:
> > On Wed, Jan 4, 2023 at 3:55 PM Lorenz Brun <lorenz at brun.one> wrote:
> > >
> > > Currently the ROCK64 device tree specifies two regulators, vcc_host_5v
> > > and vcc_host1_5v for USB VBUS on the device. Both of those are however
> > > specified with RK_PA2 as the GPIO enabling them, causing the following
> > > error when booting:
> > >
> > >   rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
> > >   rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22
> > >   rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv  on device rockchip-pinctrl
> > >   reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back
> > >
> > > Looking at the schematic, there are in fact three USB regulators,
> > > vcc_host_5v, vcc_host1_5v and vcc_otg_v5. But the enable signal for all
> > > three is driven by Q2604 which is in turn driven by GPIO_A2/PA2.
> > >
> > > Since these three regulators are not controllable separately, I removed
> > > the second one which was causing the error and left a comment explaining
> > > that this regulator actually controls multiple rails.
> > >
> > > Signed-off-by: Lorenz Brun <lorenz at brun.one>
> > > ---
> > >  arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 14 +++-----------
> > >  1 file changed, 3 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> > > index f69a38f42d2d..bd82bc80444d 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
> > > @@ -37,6 +37,9 @@ vcc_sd: sdmmc-regulator {
> > >                 vin-supply = <&vcc_io>;
> > >         };
> > >
> > > +       // vcc_host_5v also controls the vcc_host1_5v and vcc_otg_5v rails
> > > +       // but there is only one common control signal (USB20_HOST_DRV) at
> > > +       // GPIO_A2
> > >         vcc_host_5v: vcc-host-5v-regulator {
> > >                 compatible = "regulator-fixed";
> > >                 gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
> > > @@ -48,17 +51,6 @@ vcc_host_5v: vcc-host-5v-regulator {
> > >                 vin-supply = <&vcc_sys>;
> > >         };
> > >
> > > -       vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
> > > -               compatible = "regulator-fixed";
> > > -               gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
> > > -               pinctrl-names = "default";
> > > -               pinctrl-0 = <&usb20_host_drv>;
> > > -               regulator-name = "vcc_host1_5v";
> > > -               regulator-always-on;
> > > -               regulator-boot-on;
> > > -               vin-supply = <&vcc_sys>;
> > > -       };
> >
> > Fixed-regulator supports multiple regulators sharing a gpio, the issue
> > is you have the pinctrl assigned multiple times which is not
> > supported. Simply removing the pinctrl from all but one of the
> > regulators will solve this issue.
>
> Hmm, but where is the advantage in that?
> I.e. fully representing the hardware would mean not only sharing the gpio
> but also the pinctrl on all fixed regulators.
>
> And with only one of them having the pinctrl, are we sure the regulator
> probed first will always be the same, or does the pinctrl setting may only
> come into effect once the 2nd or 3rd one probes?

It's a current limitation of the pinctrl driver unfortunately. On the
off chance the regulator that owns the pinctrl doesn't probe it never
gets applied, so it's important to assign it carefully. For instance
the best scenario is assigning it to a fixed-regulator that is only
fed by other fixed-regulators. That way a dependency issue doesn't
cause the pinctrl to not assign.

>
>