| Message ID | 20210103100007.32867-5-samuel@sholland.org |
|---|---|
| State | Accepted |
| Commit | 531fdbeedeb89bd32018a35c6e137765c9cc9e97 |
| Headers | show |
| Series | Allwinner H6 RSB support | expand |
On 1/4/21 4:54 AM, André Przywara wrote: > On 03/01/2021 10:00, Samuel Holland wrote: >> On boards where the only peripheral connected to PL0/PL1 is an X-Powers >> PMIC, configure the connection to use the RSB bus rather than the I2C >> bus. Compared to the I2C controller that shares the pins, the RSB >> controller allows a higher bus frequency, and it is more CPU-efficient. > > But is it really necessary to change the DTs for those boards in this > way? It means those newer DTs now become incompatible with older > kernels, and I don't know if those reasons above really justify this. > > I understand that we officially don't care about "newer DTs on older > kernels", but do we really need to break this deliberately, for no > pressing reasons? That's a reasonable concern. I am fine if you want to delay or drop patch 4. Cheers, Samuel > Cheers, > Andre > > P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > just want to avoid breaking existing ones. > >> Signed-off-by: Samuel Holland <samuel@sholland.org> >> --- >> .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 38 +++++++++---------- >> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 14 +++---- >> .../dts/allwinner/sun50i-h6-orangepi.dtsi | 22 +++++------ >> 3 files changed, 37 insertions(+), 37 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts >> index 7c9dbde645b5..3452add30cc4 100644 >> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts >> @@ -150,12 +150,28 @@ &pio { >> vcc-pg-supply = <®_aldo1>; >> }; >> >> -&r_i2c { >> +&r_ir { >> + linux,rc-map-name = "rc-beelink-gs1"; >> + status = "okay"; >> +}; >> + >> +&r_pio { >> + /* >> + * FIXME: We can't add that supply for now since it would >> + * create a circular dependency between pinctrl, the regulator >> + * and the RSB Bus. >> + * >> + * vcc-pl-supply = <®_aldo1>; >> + */ >> + vcc-pm-supply = <®_aldo1>; >> +}; >> + >> +&r_rsb { >> status = "okay"; >> >> - axp805: pmic@36 { >> + axp805: pmic@745 { >> compatible = "x-powers,axp805", "x-powers,axp806"; >> - reg = <0x36>; >> + reg = <0x745>; >> interrupt-parent = <&r_intc>; >> interrupts = <0 IRQ_TYPE_LEVEL_LOW>; >> interrupt-controller; >> @@ -273,22 +289,6 @@ sw { >> }; >> }; >> >> -&r_ir { >> - linux,rc-map-name = "rc-beelink-gs1"; >> - status = "okay"; >> -}; >> - >> -&r_pio { >> - /* >> - * PL0 and PL1 are used for PMIC I2C >> - * don't enable the pl-supply else >> - * it will fail at boot >> - * >> - * vcc-pl-supply = <®_aldo1>; >> - */ >> - vcc-pm-supply = <®_aldo1>; >> -}; >> - >> &rtc { >> clocks = <&ext_osc32k>; >> }; >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts >> index 15c9dd8c4479..16702293ac0b 100644 >> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts >> @@ -175,12 +175,16 @@ &pio { >> vcc-pg-supply = <®_vcc_wifi_io>; >> }; >> >> -&r_i2c { >> +&r_ir { >> + status = "okay"; >> +}; >> + >> +&r_rsb { >> status = "okay"; >> >> - axp805: pmic@36 { >> + axp805: pmic@745 { >> compatible = "x-powers,axp805", "x-powers,axp806"; >> - reg = <0x36>; >> + reg = <0x745>; >> interrupt-parent = <&r_intc>; >> interrupts = <0 IRQ_TYPE_LEVEL_LOW>; >> interrupt-controller; >> @@ -291,10 +295,6 @@ sw { >> }; >> }; >> >> -&r_ir { >> - status = "okay"; >> -}; >> - >> &rtc { >> clocks = <&ext_osc32k>; >> }; >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi >> index ebc120a9232f..23e3cb2ffd8d 100644 >> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi >> @@ -112,12 +112,20 @@ &pio { >> vcc-pg-supply = <®_aldo1>; >> }; >> >> -&r_i2c { >> +&r_ir { >> + status = "okay"; >> +}; >> + >> +&r_pio { >> + vcc-pm-supply = <®_bldo3>; >> +}; >> + >> +&r_rsb { >> status = "okay"; >> >> - axp805: pmic@36 { >> + axp805: pmic@745 { >> compatible = "x-powers,axp805", "x-powers,axp806"; >> - reg = <0x36>; >> + reg = <0x745>; >> interrupt-parent = <&r_intc>; >> interrupts = <0 IRQ_TYPE_LEVEL_LOW>; >> interrupt-controller; >> @@ -232,14 +240,6 @@ sw { >> }; >> }; >> >> -&r_ir { >> - status = "okay"; >> -}; >> - >> -&r_pio { >> - vcc-pm-supply = <®_bldo3>; >> -}; >> - >> &rtc { >> clocks = <&ext_osc32k>; >> }; >> >
On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote: > On 03/01/2021 10:00, Samuel Holland wrote: > > On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > PMIC, configure the connection to use the RSB bus rather than the I2C > > bus. Compared to the I2C controller that shares the pins, the RSB > > controller allows a higher bus frequency, and it is more CPU-efficient. > > But is it really necessary to change the DTs for those boards in this > way? It means those newer DTs now become incompatible with older > kernels, and I don't know if those reasons above really justify this. > > I understand that we officially don't care about "newer DTs on older > kernels", but do we really need to break this deliberately, for no > pressing reasons? > > P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > just want to avoid breaking existing ones. Doing so would also introduce some inconsistencies, one more thing to consider during reviews, and would require more testing effort. I'm not sure that stretching our - already fairly sparse - resources thin would be very wise here, especially for something that we don't have to do and for a setup that isn't really used that much. Maxime
On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@cerno.tech> wrote: > > On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote: > > On 03/01/2021 10:00, Samuel Holland wrote: > > > On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > > PMIC, configure the connection to use the RSB bus rather than the I2C > > > bus. Compared to the I2C controller that shares the pins, the RSB > > > controller allows a higher bus frequency, and it is more CPU-efficient. > > > > But is it really necessary to change the DTs for those boards in this > > way? It means those newer DTs now become incompatible with older > > kernels, and I don't know if those reasons above really justify this. > > > > I understand that we officially don't care about "newer DTs on older > > kernels", but do we really need to break this deliberately, for no > > pressing reasons? > > > > P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > > just want to avoid breaking existing ones. > > Doing so would also introduce some inconsistencies, one more thing to > consider during reviews, and would require more testing effort. > > I'm not sure that stretching our - already fairly sparse - resources > thin would be very wise here, especially for something that we don't > have to do and for a setup that isn't really used that much. As soon as some software component starts running RSB, (which I assume is what Samuel is planning to do in Crust?), there's a chance that it doesn't switch the chip back to I2C. And then Linux won't be able to access it. So I'm for keeping things consistent and converting all users to RSB. ChenYu
On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@cerno.tech> wrote: >> >> On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote: >>> On 03/01/2021 10:00, Samuel Holland wrote: >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers >>>> PMIC, configure the connection to use the RSB bus rather than the I2C >>>> bus. Compared to the I2C controller that shares the pins, the RSB >>>> controller allows a higher bus frequency, and it is more CPU-efficient. >>> >>> But is it really necessary to change the DTs for those boards in this >>> way? It means those newer DTs now become incompatible with older >>> kernels, and I don't know if those reasons above really justify this. >>> >>> I understand that we officially don't care about "newer DTs on older >>> kernels", but do we really need to break this deliberately, for no >>> pressing reasons? >>> >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, >>> just want to avoid breaking existing ones. >> >> Doing so would also introduce some inconsistencies, one more thing to >> consider during reviews, and would require more testing effort. >> >> I'm not sure that stretching our - already fairly sparse - resources >> thin would be very wise here, especially for something that we don't >> have to do and for a setup that isn't really used that much. > > As soon as some software component starts running RSB, (which I assume > is what Samuel is planning to do in Crust?), there's a chance that it > doesn't switch the chip back to I2C. And then Linux won't be able to > access it. Crust can handle either way via a config option, which currently defaults to I2C for H6. It must use the same selection as Linux, not only because of the PMIC mode, but also because of the pinctrl. TF-A is already converted to use RSB[1], and it does switch the PMIC back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is fine. However, Linux currently does not switch the PMIC back. So the most likely problem from this patch is that, with new Linux + old TF-A, TF-A will be unable to power down the board or access regulators after an SoC reset. I expect there will be a TF-A release between now and when 5.12 hits stable, but people tend not upgrade their U-Boot/TF-A very often. We could solve this by having the Linux RSB driver switch all child devices back to I2C in .shutdown, or by dropping this patch and only using RSB for new boards (which would also address Andre's concern). Cheers, Samuel [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > So I'm for keeping things consistent and converting all users to RSB. > > > ChenYu >
On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland <samuel@sholland.org> wrote: > > On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@cerno.tech> wrote: > >> > >> On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote: > >>> On 03/01/2021 10:00, Samuel Holland wrote: > >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers > >>>> PMIC, configure the connection to use the RSB bus rather than the I2C > >>>> bus. Compared to the I2C controller that shares the pins, the RSB > >>>> controller allows a higher bus frequency, and it is more CPU-efficient. > >>> > >>> But is it really necessary to change the DTs for those boards in this > >>> way? It means those newer DTs now become incompatible with older > >>> kernels, and I don't know if those reasons above really justify this. > >>> > >>> I understand that we officially don't care about "newer DTs on older > >>> kernels", but do we really need to break this deliberately, for no > >>> pressing reasons? > >>> > >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > >>> just want to avoid breaking existing ones. > >> > >> Doing so would also introduce some inconsistencies, one more thing to > >> consider during reviews, and would require more testing effort. > >> > >> I'm not sure that stretching our - already fairly sparse - resources > >> thin would be very wise here, especially for something that we don't > >> have to do and for a setup that isn't really used that much. > > > > As soon as some software component starts running RSB, (which I assume > > is what Samuel is planning to do in Crust?), there's a chance that it > > doesn't switch the chip back to I2C. And then Linux won't be able to > > access it. > > Crust can handle either way via a config option, which currently > defaults to I2C for H6. It must use the same selection as Linux, not > only because of the PMIC mode, but also because of the pinctrl. Could Crust be made to also handle pinctrl? > TF-A is already converted to use RSB[1], and it does switch the PMIC > back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is > fine. However, Linux currently does not switch the PMIC back. So the > most likely problem from this patch is that, with new Linux + old TF-A, > TF-A will be unable to power down the board or access regulators after > an SoC reset. > > I expect there will be a TF-A release between now and when 5.12 hits > stable, but people tend not upgrade their U-Boot/TF-A very often. > > We could solve this by having the Linux RSB driver switch all child > devices back to I2C in .shutdown, or by dropping this patch and only > using RSB for new boards (which would also address Andre's concern). This will work for most cases, except in a kernel panic or IIRC direct reboot using sysrq. So it's not robust as we'd like it to be. ChenYu > Cheers, > Samuel > > [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 > [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > > > So I'm for keeping things consistent and converting all users to RSB. > > > > > > ChenYu > > > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.
On Wed, Jan 13, 2021 at 5:16 PM Chen-Yu Tsai <wens@csie.org> wrote: > > On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland <samuel@sholland.org> wrote: > > > > On 1/6/21 5:38 AM, Chen-Yu Tsai wrote: > > > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@cerno.tech> wrote: > > >> > > >> On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote: > > >>> On 03/01/2021 10:00, Samuel Holland wrote: > > >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers > > >>>> PMIC, configure the connection to use the RSB bus rather than the I2C > > >>>> bus. Compared to the I2C controller that shares the pins, the RSB > > >>>> controller allows a higher bus frequency, and it is more CPU-efficient. > > >>> > > >>> But is it really necessary to change the DTs for those boards in this > > >>> way? It means those newer DTs now become incompatible with older > > >>> kernels, and I don't know if those reasons above really justify this. > > >>> > > >>> I understand that we officially don't care about "newer DTs on older > > >>> kernels", but do we really need to break this deliberately, for no > > >>> pressing reasons? > > >>> > > >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs, > > >>> just want to avoid breaking existing ones. > > >> > > >> Doing so would also introduce some inconsistencies, one more thing to > > >> consider during reviews, and would require more testing effort. > > >> > > >> I'm not sure that stretching our - already fairly sparse - resources > > >> thin would be very wise here, especially for something that we don't > > >> have to do and for a setup that isn't really used that much. > > > > > > As soon as some software component starts running RSB, (which I assume > > > is what Samuel is planning to do in Crust?), there's a chance that it > > > doesn't switch the chip back to I2C. And then Linux won't be able to > > > access it. > > > > Crust can handle either way via a config option, which currently > > defaults to I2C for H6. It must use the same selection as Linux, not > > only because of the PMIC mode, but also because of the pinctrl. > > Could Crust be made to also handle pinctrl? > > > TF-A is already converted to use RSB[1], and it does switch the PMIC > > back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is > > fine. However, Linux currently does not switch the PMIC back. So the > > most likely problem from this patch is that, with new Linux + old TF-A, > > TF-A will be unable to power down the board or access regulators after > > an SoC reset. > > > > I expect there will be a TF-A release between now and when 5.12 hits > > stable, but people tend not upgrade their U-Boot/TF-A very often. > > > > We could solve this by having the Linux RSB driver switch all child > > devices back to I2C in .shutdown, or by dropping this patch and only > > using RSB for new boards (which would also address Andre's concern). > > This will work for most cases, except in a kernel panic or IIRC direct > reboot using sysrq. So it's not robust as we'd like it to be. I also wonder what would happen when there are multiple RSB devices, and we switch them back to I2C one by one. It's not like there's an option to switch all of them back at the same time, unlike switching from I2C to RSB. The A80 and A83T are the platforms that would be affected. So I merged the previous patch, i.e. changes to the .dtsi, but I think we should delay this one by a release. That would give us more time to think about it, and let users upgrade U-Boot/TF-A. ChenYu > ChenYu > > > Cheers, > > Samuel > > > > [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576 > > [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575 > > > > > So I'm for keeping things consistent and converting all users to RSB. > > > > > > > > > ChenYu > > > > > > > -- > > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com. > > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.
On Sun, Jan 03, 2021 at 04:00:07AM -0600, Samuel Holland wrote: > On boards where the only peripheral connected to PL0/PL1 is an X-Powers > PMIC, configure the connection to use the RSB bus rather than the I2C > bus. Compared to the I2C controller that shares the pins, the RSB > controller allows a higher bus frequency, and it is more CPU-efficient. > > Signed-off-by: Samuel Holland <samuel@sholland.org> Applied, thanks Maxime
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts index 7c9dbde645b5..3452add30cc4 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts @@ -150,12 +150,28 @@ &pio { vcc-pg-supply = <®_aldo1>; }; -&r_i2c { +&r_ir { + linux,rc-map-name = "rc-beelink-gs1"; + status = "okay"; +}; + +&r_pio { + /* + * FIXME: We can't add that supply for now since it would + * create a circular dependency between pinctrl, the regulator + * and the RSB Bus. + * + * vcc-pl-supply = <®_aldo1>; + */ + vcc-pm-supply = <®_aldo1>; +}; + +&r_rsb { status = "okay"; - axp805: pmic@36 { + axp805: pmic@745 { compatible = "x-powers,axp805", "x-powers,axp806"; - reg = <0x36>; + reg = <0x745>; interrupt-parent = <&r_intc>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; @@ -273,22 +289,6 @@ sw { }; }; -&r_ir { - linux,rc-map-name = "rc-beelink-gs1"; - status = "okay"; -}; - -&r_pio { - /* - * PL0 and PL1 are used for PMIC I2C - * don't enable the pl-supply else - * it will fail at boot - * - * vcc-pl-supply = <®_aldo1>; - */ - vcc-pm-supply = <®_aldo1>; -}; - &rtc { clocks = <&ext_osc32k>; }; diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts index 15c9dd8c4479..16702293ac0b 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts @@ -175,12 +175,16 @@ &pio { vcc-pg-supply = <®_vcc_wifi_io>; }; -&r_i2c { +&r_ir { + status = "okay"; +}; + +&r_rsb { status = "okay"; - axp805: pmic@36 { + axp805: pmic@745 { compatible = "x-powers,axp805", "x-powers,axp806"; - reg = <0x36>; + reg = <0x745>; interrupt-parent = <&r_intc>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; @@ -291,10 +295,6 @@ sw { }; }; -&r_ir { - status = "okay"; -}; - &rtc { clocks = <&ext_osc32k>; }; diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi index ebc120a9232f..23e3cb2ffd8d 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi @@ -112,12 +112,20 @@ &pio { vcc-pg-supply = <®_aldo1>; }; -&r_i2c { +&r_ir { + status = "okay"; +}; + +&r_pio { + vcc-pm-supply = <®_bldo3>; +}; + +&r_rsb { status = "okay"; - axp805: pmic@36 { + axp805: pmic@745 { compatible = "x-powers,axp805", "x-powers,axp806"; - reg = <0x36>; + reg = <0x745>; interrupt-parent = <&r_intc>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; @@ -232,14 +240,6 @@ sw { }; }; -&r_ir { - status = "okay"; -}; - -&r_pio { - vcc-pm-supply = <®_bldo3>; -}; - &rtc { clocks = <&ext_osc32k>; };
On boards where the only peripheral connected to PL0/PL1 is an X-Powers PMIC, configure the connection to use the RSB bus rather than the I2C bus. Compared to the I2C controller that shares the pins, the RSB controller allows a higher bus frequency, and it is more CPU-efficient. Signed-off-by: Samuel Holland <samuel@sholland.org> --- .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 38 +++++++++---------- .../dts/allwinner/sun50i-h6-orangepi-3.dts | 14 +++---- .../dts/allwinner/sun50i-h6-orangepi.dtsi | 22 +++++------ 3 files changed, 37 insertions(+), 37 deletions(-)