Message ID | 20211011125301.3440033-1-adrian.ratiu@collabora.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | arm64: defconfig: enable regulator to fix mt8173 regression | expand |
On 11/10/2021 13:53, Adrian Ratiu wrote: > A regression was introduced on some mediatek boards starting with > v5.15-rc1 in commit 109fd20601e2b ("arm64: dts: mediatek: mt8173: > Add domain supply for mfg_async") which effectively changed the > regulator from the always-on dummy to DA9211 without explicitely > enabling it, causing failures like the these caught by KernelCI > on Hana Chromebooks [1]: > > mtk-power-controller 10006000.syscon:power-controller: supply domain not found, using dummy regulator > mtu3 11271000.usb: supply vbus not found, using dummy regulator > xhci-mtk 11270000.usb: supply vbus not found, using dummy regulator > > There might be another bug linking these power domains in the > mediatek PM driver, but that is a separate issue wich needs > addressing, for now just fix the obvious regression due to the > new regulator requirement. > > [1] https://github.com/kernelci/kernelci-project/issues/66 > Reported-by: "kernelci.org bot" <bot@kernelci.org> > Cc: Guillaume Tucker <guillaume.tucker@collabora.com> > Suggested-by: Enric Balletbo Serra <eballetbo@gmail.com> > Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Tested-by: "kernelci.org bot" <bot@kernelci.org> https://staging.kernelci.org/test/plan/id/616945b4043bf9aafba6c453/ Thanks, Guillaume > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 156d96afbbfc..4901cc1213bb 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -616,6 +616,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_REGULATOR_AXP20X=y > CONFIG_REGULATOR_BD718XX=y > CONFIG_REGULATOR_BD9571MWV=y > +CONFIG_REGULATOR_DA9211=y > CONFIG_REGULATOR_FAN53555=y > CONFIG_REGULATOR_GPIO=y > CONFIG_REGULATOR_HI6421V530=y >
Il 11/10/21 14:53, Adrian Ratiu ha scritto: > A regression was introduced on some mediatek boards starting with > v5.15-rc1 in commit 109fd20601e2b ("arm64: dts: mediatek: mt8173: > Add domain supply for mfg_async") which effectively changed the > regulator from the always-on dummy to DA9211 without explicitely > enabling it, causing failures like the these caught by KernelCI > on Hana Chromebooks [1]: > > mtk-power-controller 10006000.syscon:power-controller: supply domain not found, using dummy regulator > mtu3 11271000.usb: supply vbus not found, using dummy regulator > xhci-mtk 11270000.usb: supply vbus not found, using dummy regulator > > There might be another bug linking these power domains in the > mediatek PM driver, but that is a separate issue wich needs > addressing, for now just fix the obvious regression due to the > new regulator requirement. > > [1] https://github.com/kernelci/kernelci-project/issues/66 > Reported-by: "kernelci.org bot" <bot@kernelci.org> > Cc: Guillaume Tucker <guillaume.tucker@collabora.com> > Suggested-by: Enric Balletbo Serra <eballetbo@gmail.com> > Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 156d96afbbfc..4901cc1213bb 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -616,6 +616,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_REGULATOR_AXP20X=y > CONFIG_REGULATOR_BD718XX=y > CONFIG_REGULATOR_BD9571MWV=y > +CONFIG_REGULATOR_DA9211=y > CONFIG_REGULATOR_FAN53555=y > CONFIG_REGULATOR_GPIO=y > CONFIG_REGULATOR_HI6421V530=y > Hello, I've been able to get a working Hana boot, with USB probed as early as possible, as well solving that KernelCI failure (as now also the usb network works fine again). My proposal here, for which I have a patch that's almost ready, would be to enable this regulator driver as a module instead (since Hana is the only device that's using it), avoiding to increase the kernel image size for everyone. Before pointing out my solution, let's first point out what's going on: In mt8173.dtsi, we have a power-controller node (mediatek,mt8173-power-controller), under which all of the SoC's power domain nodes are defined. In this node, we have both SCPD_DOMAIN_SUPPLY domains and "regular" ones. The difference between SCPD domains and the others is that the first ones require a parent regulator, while the latter don't (power is supplied from some .. internal supply? - either way, no parent vreg necessary/declared). As a note, for now, the only two MediaTek SoCs that have a SCPD supply are MT8173 and MT8183... and nothing else, as the others, including the newer ones seem to have no such supplies (the only newer one upstream is MT8192 and has none). My solution was to split the power-controller node in two: 1. spm: power-controller@0 - contains all of the non-SCPD power domains 2. spm_scpd: power-controller@1 - contains the SCPD power domains. This made me able to get a full boot without usb/usb-eth issues while enabling this regulator as a module; this also requires us to change the mediatek,power-controller.yaml binding to allow multiple instances of that driver, which is anyway already permitted by the mtk-pm-domains driver itself. Hence, this question comes up: how should we proceed? should we... a. enable this regulator driver as module and split the power-controller in two; or b. keep this commit enabling this driver built-in and still split the power-controller nodes; or c. just enable this driver as built-in and not care about declaring two power controller nodes? Can you please give us an advice? Thank you, - Angelo
Il 19/10/21 16:38, AngeloGioacchino Del Regno ha scritto: > Il 11/10/21 14:53, Adrian Ratiu ha scritto: >> A regression was introduced on some mediatek boards starting with >> v5.15-rc1 in commit 109fd20601e2b ("arm64: dts: mediatek: mt8173: >> Add domain supply for mfg_async") which effectively changed the >> regulator from the always-on dummy to DA9211 without explicitely >> enabling it, causing failures like the these caught by KernelCI >> on Hana Chromebooks [1]: >> >> mtk-power-controller 10006000.syscon:power-controller: supply domain not found, >> using dummy regulator >> mtu3 11271000.usb: supply vbus not found, using dummy regulator >> xhci-mtk 11270000.usb: supply vbus not found, using dummy regulator >> >> There might be another bug linking these power domains in the >> mediatek PM driver, but that is a separate issue wich needs >> addressing, for now just fix the obvious regression due to the >> new regulator requirement. >> >> [1] https://github.com/kernelci/kernelci-project/issues/66 >> Reported-by: "kernelci.org bot" <bot@kernelci.org> >> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> >> Suggested-by: Enric Balletbo Serra <eballetbo@gmail.com> >> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> >> --- >> arch/arm64/configs/defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >> index 156d96afbbfc..4901cc1213bb 100644 >> --- a/arch/arm64/configs/defconfig >> +++ b/arch/arm64/configs/defconfig >> @@ -616,6 +616,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y >> CONFIG_REGULATOR_AXP20X=y >> CONFIG_REGULATOR_BD718XX=y >> CONFIG_REGULATOR_BD9571MWV=y >> +CONFIG_REGULATOR_DA9211=y >> CONFIG_REGULATOR_FAN53555=y >> CONFIG_REGULATOR_GPIO=y >> CONFIG_REGULATOR_HI6421V530=y >> > > Hello, > > I've been able to get a working Hana boot, with USB probed as early as possible, as > well solving that KernelCI failure (as now also the usb network works fine again). > > My proposal here, for which I have a patch that's almost ready, would be to enable > this regulator driver as a module instead (since Hana is the only device that's > using it), avoiding to increase the kernel image size for everyone. > > > Before pointing out my solution, let's first point out what's going on: > > In mt8173.dtsi, we have a power-controller node (mediatek,mt8173-power-controller), > under which all of the SoC's power domain nodes are defined. In this node, we have > both SCPD_DOMAIN_SUPPLY domains and "regular" ones. > > The difference between SCPD domains and the others is that the first ones require a > parent regulator, while the latter don't (power is supplied from some .. internal > supply? - either way, no parent vreg necessary/declared). > As a note, for now, the only two MediaTek SoCs that have a SCPD supply are MT8173 > and MT8183... and nothing else, as the others, including the newer ones seem to > have no such supplies (the only newer one upstream is MT8192 and has none). > > > My solution was to split the power-controller node in two: > 1. spm: power-controller@0 - contains all of the non-SCPD power domains > 2. spm_scpd: power-controller@1 - contains the SCPD power domains. > > This made me able to get a full boot without usb/usb-eth issues while enabling this > regulator as a module; this also requires us to change the > mediatek,power-controller.yaml binding to allow multiple instances of that driver, > which is anyway already permitted by the mtk-pm-domains driver itself. > > > Hence, this question comes up: how should we proceed? should we... > a. enable this regulator driver as module and split the power-controller in two; or > b. keep this commit enabling this driver built-in and still split the > power-controller nodes; or > c. just enable this driver as built-in and not care about declaring two power > controller nodes? > > Can you please give us an advice? > > Thank you, > - Angelo After a discussion on this topic, we chose to pursue option B, as enabling this regulator fixes a very bad regression. Splitting the power-controller nodes does require a bit of time due to some more research that has to be done on that topic. Adrian will follow with a v2 of this patch, adding a Fixes tag. Thanks everyone, - Angelo
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 156d96afbbfc..4901cc1213bb 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -616,6 +616,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_AXP20X=y CONFIG_REGULATOR_BD718XX=y CONFIG_REGULATOR_BD9571MWV=y +CONFIG_REGULATOR_DA9211=y CONFIG_REGULATOR_FAN53555=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_HI6421V530=y
A regression was introduced on some mediatek boards starting with v5.15-rc1 in commit 109fd20601e2b ("arm64: dts: mediatek: mt8173: Add domain supply for mfg_async") which effectively changed the regulator from the always-on dummy to DA9211 without explicitely enabling it, causing failures like the these caught by KernelCI on Hana Chromebooks [1]: mtk-power-controller 10006000.syscon:power-controller: supply domain not found, using dummy regulator mtu3 11271000.usb: supply vbus not found, using dummy regulator xhci-mtk 11270000.usb: supply vbus not found, using dummy regulator There might be another bug linking these power domains in the mediatek PM driver, but that is a separate issue wich needs addressing, for now just fix the obvious regression due to the new regulator requirement. [1] https://github.com/kernelci/kernelci-project/issues/66 Reported-by: "kernelci.org bot" <bot@kernelci.org> Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Suggested-by: Enric Balletbo Serra <eballetbo@gmail.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)