[PATCH v2 0/4] Allwinner H6 RSB support

[PATCH v2 0/4] Allwinner H6 RSB support

[Samuel Holland]

The Allwinner H6 SoC contains an RSB controller. It is almost completely
undocumented, so it was missed when doing the initial SoC bringup.

This series adds the clock/reset, pin configuration, and device tree
node needed to use the RSB controller. Since RSB is faster, simpler, and
generally more reliable than the I2C controller IP in the SoC, switch to
using it where possible.

This was tested on an Orange Pi 3 and a Pine H64 model B. This series
does not switch the Pine H64 to use RSB, as doing so would prevent
accessing the external RTC that shares the I2C bus.

Changes v1->v2:
  - Put the new values at the end of the DT binding headers

Samuel Holland (4):
  clk: sunxi-ng: h6-r: Add R_APB2_RSB clock and reset
  pinctrl: sunxi: h6-r: Add s_rsb pin functions
  arm64: dts: allwinner: h6: Add RSB controller node
  arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   | 38 +++++++++----------
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 14 +++----
 .../dts/allwinner/sun50i-h6-orangepi.dtsi     | 22 +++++------
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 19 ++++++++++
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c        |  5 +++
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h        |  2 +-
 drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c   |  2 +
 include/dt-bindings/clock/sun50i-h6-r-ccu.h   |  2 +
 include/dt-bindings/reset/sun50i-h6-r-ccu.h   |  1 +
 9 files changed, 67 insertions(+), 38 deletions(-)

-- 
2.26.2

[PATCH v2 1/4] clk: sunxi-ng: h6-r: Add R_APB2_RSB clock and reset

[Samuel Holland]

While no information about the H6 RSB controller is included in the
datasheet or manual, the vendor BSP and power management blob both
reference the RSB clock parent and register address. These values were
verified by experimentation.

Since this clock/reset are added late, the specifier is added at the end
to maintain the existing DT binding. The code is kept in register order.

Signed-off-by: Samuel Holland <samuel@sholland.org>
---
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c      | 5 +++++
 drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h      | 2 +-
 include/dt-bindings/clock/sun50i-h6-r-ccu.h | 2 ++
 include/dt-bindings/reset/sun50i-h6-r-ccu.h | 1 +
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
index 50f8d1bc7046..56e351b513f3 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
@@ -91,6 +91,8 @@ static SUNXI_CCU_GATE(r_apb2_uart_clk,	"r-apb2-uart",	"r-apb2",
 		      0x18c, BIT(0), 0);
 static SUNXI_CCU_GATE(r_apb2_i2c_clk,	"r-apb2-i2c",	"r-apb2",
 		      0x19c, BIT(0), 0);
+static SUNXI_CCU_GATE(r_apb2_rsb_clk,	"r-apb2-rsb",	"r-apb2",
+		      0x1bc, BIT(0), 0);
 static SUNXI_CCU_GATE(r_apb1_ir_clk,	"r-apb1-ir",	"r-apb1",
 		      0x1cc, BIT(0), 0);
 static SUNXI_CCU_GATE(r_apb1_w1_clk,	"r-apb1-w1",	"r-apb1",
@@ -130,6 +132,7 @@ static struct ccu_common *sun50i_h6_r_ccu_clks[] = {
 	&r_apb1_pwm_clk.common,
 	&r_apb2_uart_clk.common,
 	&r_apb2_i2c_clk.common,
+	&r_apb2_rsb_clk.common,
 	&r_apb1_ir_clk.common,
 	&r_apb1_w1_clk.common,
 	&ir_clk.common,
@@ -147,6 +150,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
 		[CLK_R_APB1_PWM]	= &r_apb1_pwm_clk.common.hw,
 		[CLK_R_APB2_UART]	= &r_apb2_uart_clk.common.hw,
 		[CLK_R_APB2_I2C]	= &r_apb2_i2c_clk.common.hw,
+		[CLK_R_APB2_RSB]	= &r_apb2_rsb_clk.common.hw,
 		[CLK_R_APB1_IR]		= &r_apb1_ir_clk.common.hw,
 		[CLK_R_APB1_W1]		= &r_apb1_w1_clk.common.hw,
 		[CLK_IR]		= &ir_clk.common.hw,
@@ -161,6 +165,7 @@ static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
 	[RST_R_APB1_PWM]	=  { 0x13c, BIT(16) },
 	[RST_R_APB2_UART]	=  { 0x18c, BIT(16) },
 	[RST_R_APB2_I2C]	=  { 0x19c, BIT(16) },
+	[RST_R_APB2_RSB]	=  { 0x1bc, BIT(16) },
 	[RST_R_APB1_IR]		=  { 0x1cc, BIT(16) },
 	[RST_R_APB1_W1]		=  { 0x1ec, BIT(16) },
 };
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
index 782117dc0b28..7e290b840803 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
@@ -14,6 +14,6 @@
 
 #define CLK_R_APB2	3
 
-#define CLK_NUMBER	(CLK_W1 + 1)
+#define CLK_NUMBER	(CLK_R_APB2_RSB + 1)
 
 #endif /* _CCU_SUN50I_H6_R_H */
diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
index 76136132a13e..890368d252c4 100644
--- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
+++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
@@ -21,4 +21,6 @@
 #define CLK_IR			11
 #define CLK_W1			12
 
+#define CLK_R_APB2_RSB		13
+
 #endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
diff --git a/include/dt-bindings/reset/sun50i-h6-r-ccu.h b/include/dt-bindings/reset/sun50i-h6-r-ccu.h
index 01c84dba49a4..7950e799c76d 100644
--- a/include/dt-bindings/reset/sun50i-h6-r-ccu.h
+++ b/include/dt-bindings/reset/sun50i-h6-r-ccu.h
@@ -13,5 +13,6 @@
 #define RST_R_APB2_I2C		4
 #define RST_R_APB1_IR		5
 #define RST_R_APB1_W1		6
+#define RST_R_APB2_RSB		7
 
 #endif /* _DT_BINDINGS_RST_SUN50I_H6_R_CCU_H_ */
-- 
2.26.2

[PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions

[Samuel Holland]

As there is an RSB controller in the H6 SoC, there should be some pin
configuration for it. While no such configuration is documented, the
"s_i2c" pins are suspiciously on the "alternate" function 3, with no
primary function 2 given. This suggests the primary function for these
pins is actually RSB, and that is indeed the case.

Add the "s_rsb" pin functions so the RSB controller can be used.

Signed-off-by: Samuel Holland <samuel@sholland.org>
---
 drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c
index 4557e18d5989..c7d90c44e87a 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c
@@ -24,11 +24,13 @@ static const struct sunxi_desc_pin sun50i_h6_r_pins[] = {
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_rsb"),		/* SCK */
 		  SUNXI_FUNCTION(0x3, "s_i2c"),		/* SCK */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* PL_EINT0 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_rsb"),		/* SDA */
 		  SUNXI_FUNCTION(0x3, "s_i2c"),		/* SDA */
 		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),	/* PL_EINT1 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
-- 
2.26.2

Re: [linux-sunxi] [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions

[Chen-Yu Tsai]

On Sun, Jan 3, 2021 at 6:00 PM Samuel Holland <samuel@sholland.org> wrote:
>
> As there is an RSB controller in the H6 SoC, there should be some pin
> configuration for it. While no such configuration is documented, the
> "s_i2c" pins are suspiciously on the "alternate" function 3, with no
> primary function 2 given. This suggests the primary function for these
> pins is actually RSB, and that is indeed the case.
>
> Add the "s_rsb" pin functions so the RSB controller can be used.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>

Acked-by: Chen-Yu Tsai <wens@csie.org>

Re: [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions

[Linus Walleij]

On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland <samuel@sholland.org> wrote:

> As there is an RSB controller in the H6 SoC, there should be some pin
> configuration for it. While no such configuration is documented, the
> "s_i2c" pins are suspiciously on the "alternate" function 3, with no
> primary function 2 given. This suggests the primary function for these
> pins is actually RSB, and that is indeed the case.
>
> Add the "s_rsb" pin functions so the RSB controller can be used.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>

Is it OK if I just apply this patch to the pinctrl tree?

Yours,
Linus Walleij

Re: [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions

[Chen-Yu Tsai]

On Wed, Jan 6, 2021 at 6:35 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland <samuel@sholland.org> wrote:
>
> > As there is an RSB controller in the H6 SoC, there should be some pin
> > configuration for it. While no such configuration is documented, the
> > "s_i2c" pins are suspiciously on the "alternate" function 3, with no
> > primary function 2 given. This suggests the primary function for these
> > pins is actually RSB, and that is indeed the case.
> >
> > Add the "s_rsb" pin functions so the RSB controller can be used.
> >
> > Signed-off-by: Samuel Holland <samuel@sholland.org>
>
> Is it OK if I just apply this patch to the pinctrl tree?

Please do.

Thanks
ChenYu

Re: [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions

[Linus Walleij]

On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland <samuel@sholland.org> wrote:

> As there is an RSB controller in the H6 SoC, there should be some pin
> configuration for it. While no such configuration is documented, the
> "s_i2c" pins are suspiciously on the "alternate" function 3, with no
> primary function 2 given. This suggests the primary function for these
> pins is actually RSB, and that is indeed the case.
>
> Add the "s_rsb" pin functions so the RSB controller can be used.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>

This patch applied to the pinctrl tree.

Yours,
Linus Walleij

[PATCH v2 3/4] arm64: dts: allwinner: h6: Add RSB controller node

[Samuel Holland]

The H6 SoC contains an undocumented but fully functional RSB controller.
Add support for it. The MMIO register address matches other SoCs of the
same generation, and the IRQ matches a hole in the documented IRQ list.

Signed-off-by: Samuel Holland <samuel@sholland.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 8a62a9fbe347..b043beea8e6e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -949,6 +949,11 @@ r_ir_rx_pin: r-ir-rx-pin {
 				pins = "PL9";
 				function = "s_cir_rx";
 			};
+
+			r_rsb_pins: r-rsb-pins {
+				pins = "PL0", "PL1";
+				function = "s_rsb";
+			};
 		};
 
 		r_ir: ir@7040000 {
@@ -979,6 +984,20 @@ r_i2c: i2c@7081400 {
 			#size-cells = <0>;
 		};
 
+		r_rsb: rsb@7083000 {
+			compatible = "allwinner,sun8i-a23-rsb";
+			reg = <0x07083000 0x400>;
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&r_ccu CLK_R_APB2_RSB>;
+			clock-frequency = <3000000>;
+			resets = <&r_ccu RST_R_APB2_RSB>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&r_rsb_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		ths: thermal-sensor@5070400 {
 			compatible = "allwinner,sun50i-h6-ths";
 			reg = <0x05070400 0x100>;
-- 
2.26.2

[PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Samuel Holland]

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(-)

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 = <&reg_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 = <&reg_aldo1>;
+	 */
+	vcc-pm-supply = <&reg_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 = <&reg_aldo1>;
-	 */
-	vcc-pm-supply = <&reg_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 = <&reg_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 = <&reg_aldo1>;
 };
 
-&r_i2c {
+&r_ir {
+	status = "okay";
+};
+
+&r_pio {
+	vcc-pm-supply = <&reg_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 = <&reg_bldo3>;
-};
-
 &rtc {
 	clocks = <&ext_osc32k>;
 };
-- 
2.26.2

Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[André Przywara]

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?

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 = <&reg_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 = <&reg_aldo1>;
> +	 */
> +	vcc-pm-supply = <&reg_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 = <&reg_aldo1>;
> -	 */
> -	vcc-pm-supply = <&reg_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 = <&reg_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 = <&reg_aldo1>;
>  };
>  
> -&r_i2c {
> +&r_ir {
> +	status = "okay";
> +};
> +
> +&r_pio {
> +	vcc-pm-supply = <&reg_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 = <&reg_bldo3>;
> -};
> -
>  &rtc {
>  	clocks = <&ext_osc32k>;
>  };
> 

Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Samuel Holland]

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 = <&reg_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 = <&reg_aldo1>;
>> +	 */
>> +	vcc-pm-supply = <&reg_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 = <&reg_aldo1>;
>> -	 */
>> -	vcc-pm-supply = <&reg_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 = <&reg_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 = <&reg_aldo1>;
>>  };
>>  
>> -&r_i2c {
>> +&r_ir {
>> +	status = "okay";
>> +};
>> +
>> +&r_pio {
>> +	vcc-pm-supply = <&reg_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 = <&reg_bldo3>;
>> -};
>> -
>>  &rtc {
>>  	clocks = <&ext_osc32k>;
>>  };
>>
> 

Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Chen-Yu Tsai]

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

Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Samuel Holland]

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
> 

Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Chen-Yu Tsai]

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.

Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Chen-Yu Tsai]

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.

Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [linux-sunxi] [PATCH v2 0/4] Allwinner H6 RSB support

[Chen-Yu Tsai]

Hi,

On Sun, Jan 03, 2021 at 04:00:03AM -0600, Samuel Holland wrote:
> The Allwinner H6 SoC contains an RSB controller. It is almost completely
> undocumented, so it was missed when doing the initial SoC bringup.
> 
> This series adds the clock/reset, pin configuration, and device tree
> node needed to use the RSB controller. Since RSB is faster, simpler, and
> generally more reliable than the I2C controller IP in the SoC, switch to
> using it where possible.
> 
> This was tested on an Orange Pi 3 and a Pine H64 model B. This series
> does not switch the Pine H64 to use RSB, as doing so would prevent
> accessing the external RTC that shares the I2C bus.
> 
> Changes v1->v2:
>   - Put the new values at the end of the DT binding headers
> 
> Samuel Holland (4):
>   clk: sunxi-ng: h6-r: Add R_APB2_RSB clock and reset
>   pinctrl: sunxi: h6-r: Add s_rsb pin functions
>   arm64: dts: allwinner: h6: Add RSB controller node
>   arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

I queued up patches 1, 3, and 4 locally for v5.12. Obviously this won't
work unless the pinctrl patch is also queued up, so they won't be pushed
out until that happens.

Regarding patch 3, I replaced the clock and reset macros with raw
numbers to get rid of cross-tree dependencies. The following fix
will be posted for v5.12 later on during its RC cycle.

------------------------ >8 ------------------------

commit 0b4781666adc5e19c4d4fb4a2bff33883181cc39
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Mon Jan 4 16:19:17 2021 +0800

    arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices
    
    The macros for the clock and reset indices for the RSB hardware block
    were replaced with raw numbers when the RSB controller node was added.
    This was done to avoid cross-tree dependencies.
    
    Now that both the clk and DT changes have been merged, we can switch
    back to using the macros.
    
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index d897697849d6..b043beea8e6e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -988,9 +988,9 @@ r_rsb: rsb@7083000 {
 			compatible = "allwinner,sun8i-a23-rsb";
 			reg = <0x07083000 0x400>;
 			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&r_ccu 13>;
+			clocks = <&r_ccu CLK_R_APB2_RSB>;
 			clock-frequency = <3000000>;
-			resets = <&r_ccu 7>;
+			resets = <&r_ccu RST_R_APB2_RSB>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&r_rsb_pins>;
 			status = "disabled";
------------------------ >8 ------------------------

> 
>  .../dts/allwinner/sun50i-h6-beelink-gs1.dts   | 38 +++++++++----------
>  .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 14 +++----
>  .../dts/allwinner/sun50i-h6-orangepi.dtsi     | 22 +++++------
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 19 ++++++++++
>  drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c        |  5 +++
>  drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h        |  2 +-
>  drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c   |  2 +
>  include/dt-bindings/clock/sun50i-h6-r-ccu.h   |  2 +
>  include/dt-bindings/reset/sun50i-h6-r-ccu.h   |  1 +
>  9 files changed, 67 insertions(+), 38 deletions(-)
> 
> -- 
> 2.26.2
> 
> -- 
> 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/20210103100007.32867-1-samuel%40sholland.org.

Re: [PATCH v2 0/4] Allwinner H6 RSB support

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Sun, Jan 03, 2021 at 04:00:03AM -0600, Samuel Holland wrote:
> The Allwinner H6 SoC contains an RSB controller. It is almost completely
> undocumented, so it was missed when doing the initial SoC bringup.
> 
> This series adds the clock/reset, pin configuration, and device tree
> node needed to use the RSB controller. Since RSB is faster, simpler, and
> generally more reliable than the I2C controller IP in the SoC, switch to
> using it where possible.
> 
> This was tested on an Orange Pi 3 and a Pine H64 model B. This series
> does not switch the Pine H64 to use RSB, as doing so would prevent
> accessing the external RTC that shares the I2C bus.
> 
> Changes v1->v2:
>   - Put the new values at the end of the DT binding headers
> 
> Samuel Holland (4):
>   clk: sunxi-ng: h6-r: Add R_APB2_RSB clock and reset
>   pinctrl: sunxi: h6-r: Add s_rsb pin functions
>   arm64: dts: allwinner: h6: Add RSB controller node
>   arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

For the whole series,

Acked-by: Maxime Ripard <mripard@kernel.org>

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]