[PATCH 0/3] Add Anbernic RG-Nano

[PATCH 0/3] Add Anbernic RG-Nano

[Chris Morgan]

From: Chris Morgan <macromorgan@hotmail.com>

Add support for the Anbernic RG-Nano handheld gaming device

Chris Morgan (3):
  arm: dts: sun8i: V3s: Add pinctrl for pwm
  dt-binding: arm: sunxi: add Anbernic RG-Nano
  ARM: dts: sunxi: add support for Anbernic RG-Nano

 .../devicetree/bindings/arm/sunxi.yaml        |   5 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/sun8i-v3s-anbernic-rg-nano.dts   | 209 ++++++++++++++++++
 arch/arm/boot/dts/sun8i-v3s.dtsi              |   7 +
 4 files changed, 222 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts

-- 
2.34.1

[PATCH 1/3] arm: dts: sun8i: V3s: Add pinctrl for pwm

[Chris Morgan]

From: Chris Morgan <macromorgan@hotmail.com>

Add a default pinctrl for the pwm function.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index b001251644f7..e5977524abe2 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -414,6 +414,11 @@ mmc1_pins: mmc1-pins {
 				bias-pull-up;
 			};
 
+			pwm_pins: pwm-pins {
+				pins = "PB4";
+				function = "pwm0";
+			};
+
 			spi0_pins: spi0-pins {
 				pins = "PC0", "PC1", "PC2", "PC3";
 				function = "spi0";
@@ -441,6 +446,8 @@ pwm: pwm@1c21400 {
 				     "allwinner,sun7i-a20-pwm";
 			reg = <0x01c21400 0xc>;
 			clocks = <&osc24M>;
+			pinctrl-0 = <&pwm_pins>;
+			pinctrl-names = "default";
 			#pwm-cells = <3>;
 			status = "disabled";
 		};
-- 
2.34.1

Re: [PATCH 1/3] arm: dts: sun8i: V3s: Add pinctrl for pwm

[Andre Przywara]

On Tue, 20 Jun 2023 15:00:20 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:

Hi Chris,

thanks for taking care of upstreaming, cute little device.

> From: Chris Morgan <macromorgan@hotmail.com>
> 
> Add a default pinctrl for the pwm function.
> 
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>


> ---
>  arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index b001251644f7..e5977524abe2 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -414,6 +414,11 @@ mmc1_pins: mmc1-pins {
>  				bias-pull-up;
>  			};
>  
> +			pwm_pins: pwm-pins {
> +				pins = "PB4";
> +				function = "pwm0";
> +			};
> +
>  			spi0_pins: spi0-pins {
>  				pins = "PC0", "PC1", "PC2", "PC3";
>  				function = "spi0";
> @@ -441,6 +446,8 @@ pwm: pwm@1c21400 {
>  				     "allwinner,sun7i-a20-pwm";
>  			reg = <0x01c21400 0xc>;
>  			clocks = <&osc24M>;
> +			pinctrl-0 = <&pwm_pins>;
> +			pinctrl-names = "default";

How is this supposed to work with multiple channels? There is PWM1 on
PB5. If one wants to potentially use that, we would need to add a
reference to those pins here as well, and they would all be muxed to
PWM upon the PWM controller probing?

So while I see that it's the only output pin for PWM0, this might still
need to go into the board .dts, alongside the status = "okay"; line. So
each board would specify exactly the pins it needs (PWM0 only, PWM1
only, both or none).

Otherwise I compared this against the manual and Linux pinctrl driver,
it all matches up.

Cheers,
Andre

>  			#pwm-cells = <3>;
>  			status = "disabled";
>  		};

Re: [PATCH 1/3] arm: dts: sun8i: V3s: Add pinctrl for pwm

[Icenowy Zheng]

在 2023-06-21星期三的 00:50 +0100，Andre Przywara写道：
> On Tue, 20 Jun 2023 15:00:20 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
> 
> Hi Chris,
> 
> thanks for taking care of upstreaming, cute little device.
> 
> > From: Chris Morgan <macromorgan@hotmail.com>
> > 
> > Add a default pinctrl for the pwm function.
> > 
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> 
> 
> > ---
> >  arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > index b001251644f7..e5977524abe2 100644
> > --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > @@ -414,6 +414,11 @@ mmc1_pins: mmc1-pins {
> >                                 bias-pull-up;
> >                         };
> >  
> > +                       pwm_pins: pwm-pins {
> > +                               pins = "PB4";
> > +                               function = "pwm0";
> > +                       };
> > +
> >                         spi0_pins: spi0-pins {
> >                                 pins = "PC0", "PC1", "PC2", "PC3";
> >                                 function = "spi0";
> > @@ -441,6 +446,8 @@ pwm: pwm@1c21400 {
> >                                      "allwinner,sun7i-a20-pwm";
> >                         reg = <0x01c21400 0xc>;
> >                         clocks = <&osc24M>;
> > +                       pinctrl-0 = <&pwm_pins>;
> > +                       pinctrl-names = "default";
> 
> How is this supposed to work with multiple channels? There is PWM1 on
> PB5. If one wants to potentially use that, we would need to add a
> reference to those pins here as well, and they would all be muxed to
> PWM upon the PWM controller probing?
> 
> So while I see that it's the only output pin for PWM0, this might
> still
> need to go into the board .dts, alongside the status = "okay"; line.
> So
> each board would specify exactly the pins it needs (PWM0 only, PWM1
> only, both or none).

Maybe we should have two PWM pinctrl nodes, pwm0_pins and pwm1_pins,
and then enable the controller (with the pinctrl property) in
individual board DTs.

> 
> Otherwise I compared this against the manual and Linux pinctrl
> driver,
> it all matches up.
> 
> Cheers,
> Andre
> 
> >                         #pwm-cells = <3>;
> >                         status = "disabled";
> >                 };
> 

Re: [PATCH 1/3] arm: dts: sun8i: V3s: Add pinctrl for pwm

[Andre Przywara]

On Sat, 24 Jun 2023 12:57:49 +0800
Icenowy Zheng <uwu@icenowy.me> wrote:

> 在 2023-06-21星期三的 00:50 +0100，Andre Przywara写道：
> > On Tue, 20 Jun 2023 15:00:20 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
> > 
> > Hi Chris,
> > 
> > thanks for taking care of upstreaming, cute little device.
> >   
> > > From: Chris Morgan <macromorgan@hotmail.com>
> > > 
> > > Add a default pinctrl for the pwm function.
> > > 
> > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>  
> > 
> >   
> > > ---
> > >  arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > index b001251644f7..e5977524abe2 100644
> > > --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > @@ -414,6 +414,11 @@ mmc1_pins: mmc1-pins {
> > >                                 bias-pull-up;
> > >                         };
> > >  
> > > +                       pwm_pins: pwm-pins {
> > > +                               pins = "PB4";
> > > +                               function = "pwm0";
> > > +                       };
> > > +
> > >                         spi0_pins: spi0-pins {
> > >                                 pins = "PC0", "PC1", "PC2", "PC3";
> > >                                 function = "spi0";
> > > @@ -441,6 +446,8 @@ pwm: pwm@1c21400 {
> > >                                      "allwinner,sun7i-a20-pwm";
> > >                         reg = <0x01c21400 0xc>;
> > >                         clocks = <&osc24M>;
> > > +                       pinctrl-0 = <&pwm_pins>;
> > > +                       pinctrl-names = "default";  
> > 
> > How is this supposed to work with multiple channels? There is PWM1 on
> > PB5. If one wants to potentially use that, we would need to add a
> > reference to those pins here as well, and they would all be muxed to
> > PWM upon the PWM controller probing?
> > 
> > So while I see that it's the only output pin for PWM0, this might
> > still
> > need to go into the board .dts, alongside the status = "okay"; line.
> > So
> > each board would specify exactly the pins it needs (PWM0 only, PWM1
> > only, both or none).  
> 
> Maybe we should have two PWM pinctrl nodes, pwm0_pins and pwm1_pins,
> and then enable the controller (with the pinctrl property) in
> individual board DTs.

Yes, that's what I meant: keep the pinctrl node in the .dtsi here, but move
the pinctrl *properties* to each board's .dts.

Cheers,
Andre

> > Otherwise I compared this against the manual and Linux pinctrl
> > driver,
> > it all matches up.
> > 
> > Cheers,
> > Andre
> >   
> > >                         #pwm-cells = <3>;
> > >                         status = "disabled";
> > >                 };  
> >   
> 

Re: [PATCH 1/3] arm: dts: sun8i: V3s: Add pinctrl for pwm

[Chris Morgan]

On Mon, Jun 26, 2023 at 09:50:05AM +0100, Andre Przywara wrote:
> On Sat, 24 Jun 2023 12:57:49 +0800
> Icenowy Zheng <uwu@icenowy.me> wrote:
> 
> > 在 2023-06-21星期三的 00:50 +0100，Andre Przywara写道：
> > > On Tue, 20 Jun 2023 15:00:20 -0500
> > > Chris Morgan <macroalpha82@gmail.com> wrote:
> > > 
> > > Hi Chris,
> > > 
> > > thanks for taking care of upstreaming, cute little device.
> > >   
> > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > > 
> > > > Add a default pinctrl for the pwm function.
> > > > 
> > > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>  
> > > 
> > >   
> > > > ---
> > > >  arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > > b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > > index b001251644f7..e5977524abe2 100644
> > > > --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > > +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > > > @@ -414,6 +414,11 @@ mmc1_pins: mmc1-pins {
> > > >                                 bias-pull-up;
> > > >                         };
> > > >  
> > > > +                       pwm_pins: pwm-pins {
> > > > +                               pins = "PB4";
> > > > +                               function = "pwm0";
> > > > +                       };
> > > > +
> > > >                         spi0_pins: spi0-pins {
> > > >                                 pins = "PC0", "PC1", "PC2", "PC3";
> > > >                                 function = "spi0";
> > > > @@ -441,6 +446,8 @@ pwm: pwm@1c21400 {
> > > >                                      "allwinner,sun7i-a20-pwm";
> > > >                         reg = <0x01c21400 0xc>;
> > > >                         clocks = <&osc24M>;
> > > > +                       pinctrl-0 = <&pwm_pins>;
> > > > +                       pinctrl-names = "default";  
> > > 
> > > How is this supposed to work with multiple channels? There is PWM1 on
> > > PB5. If one wants to potentially use that, we would need to add a
> > > reference to those pins here as well, and they would all be muxed to
> > > PWM upon the PWM controller probing?
> > > 
> > > So while I see that it's the only output pin for PWM0, this might
> > > still
> > > need to go into the board .dts, alongside the status = "okay"; line.
> > > So
> > > each board would specify exactly the pins it needs (PWM0 only, PWM1
> > > only, both or none).  
> > 
> > Maybe we should have two PWM pinctrl nodes, pwm0_pins and pwm1_pins,
> > and then enable the controller (with the pinctrl property) in
> > individual board DTs.
> 
> Yes, that's what I meant: keep the pinctrl node in the .dtsi here, but move
> the pinctrl *properties* to each board's .dts.
> 
> Cheers,
> Andre

Okay, I'll add a pwm0 and pwm1 option. Thank you.

> 
> > > Otherwise I compared this against the manual and Linux pinctrl
> > > driver,
> > > it all matches up.
> > > 
> > > Cheers,
> > > Andre
> > >   
> > > >                         #pwm-cells = <3>;
> > > >                         status = "disabled";
> > > >                 };  
> > >   
> > 
> 

[PATCH 2/3] dt-binding: arm: sunxi: add Anbernic RG-Nano

[Chris Morgan]

From: Chris Morgan <macromorgan@hotmail.com>

The Anbernic RG-Nano is a portable handheld console from Anbernic which
uses the Allwinner V3s SoC.

Add the board to the list of known board strings.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 013821f4a7b8..a886f8390857 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -56,6 +56,11 @@ properties:
           - const: amarula,a64-relic
           - const: allwinner,sun50i-a64
 
+      - description: Anbernic RG-Nano
+        items:
+          - const: anbernic,rg-nano
+          - const: allwinner,sun8i-v3s
+
       - description: Auxtek T003 A10s HDMI TV Stick
         items:
           - const: allwinner,auxtek-t003
-- 
2.34.1

Re: [PATCH 2/3] dt-binding: arm: sunxi: add Anbernic RG-Nano

[Krzysztof Kozlowski]

On 20/06/2023 22:00, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
> 
> The Anbernic RG-Nano is a portable handheld console from Anbernic which
> uses the Allwinner V3s SoC.

Subject: dt-bindings, not dt-binding


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>


Best regards,
Krzysztof

Re: [PATCH 2/3] dt-binding: arm: sunxi: add Anbernic RG-Nano

[Andre Przywara]

On Tue, 20 Jun 2023 15:00:21 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:

Hi,

> From: Chris Morgan <macromorgan@hotmail.com>
> 
> The Anbernic RG-Nano is a portable handheld console from Anbernic which
> uses the Allwinner V3s SoC.
> 
> Add the board to the list of known board strings.
> 
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>

Apart from that nit-pick about the subject prefix that Krzysztof
mentioned, this looks alright:

Reviewed-by: Andre Przywara <andre.przywara@arm.com>

Cheers,
Andre

> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index 013821f4a7b8..a886f8390857 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -56,6 +56,11 @@ properties:
>            - const: amarula,a64-relic
>            - const: allwinner,sun50i-a64
>  
> +      - description: Anbernic RG-Nano
> +        items:
> +          - const: anbernic,rg-nano
> +          - const: allwinner,sun8i-v3s
> +
>        - description: Auxtek T003 A10s HDMI TV Stick
>          items:
>            - const: allwinner,auxtek-t003

[PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Chris Morgan]

From: Chris Morgan <macromorgan@hotmail.com>

The Anbernic RG-Nano is a small portable game device based on the
Allwinner V3s SoC. It has GPIO buttons on the face and side for
input, a single mono speaker, a 240x240 SPI controlled display,
and a USB-C OTG port for power. The SoC includes 64MB of RAM and
an SD card slot for booting.

The SPI display is currently unsupported, as it will either require
a new tinydrm driver or changes to the staging fbtft driver to support.
I plan on working on a tinydrm driver to properly support it. There
also may be a missing mux in the audio path that must be discovered and
defined before audio will be fully working (internal speaker does not
work yet, external headphones untested).

Working:
- SDMMC
- Buttons
- Charging/battery/PMIC

Not working:
- Display
- Audio

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/sun8i-v3s-anbernic-rg-nano.dts   | 209 ++++++++++++++++++
 2 files changed, 210 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 59829fc90315..31418b594222 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1414,6 +1414,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
 	sun8i-t113s-mangopi-mq-r-t113.dtb \
 	sun8i-t3-cqa3t-bv3.dtb \
 	sun8i-v3-sl631-imx179.dtb \
+	sun8i-v3s-anbernic-rg-nano.dtb \
 	sun8i-v3s-licheepi-zero.dtb \
 	sun8i-v3s-licheepi-zero-dock.dtb \
 	sun8i-v40-bananapi-m2-berry.dtb
diff --git a/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
new file mode 100644
index 000000000000..ead315e8fc38
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include "sun8i-v3s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+/ {
+	model = "Anbernic RG Nano";
+	compatible = "anbernic,rg-nano", "allwinner,sun8i-v3s";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 0 40000 1>;
+		brightness-levels = <0 1 2 3 8 14 21 32 46 60 80 100>;
+		default-brightness-level = <11>;
+		power-supply = <&reg_vcc5v0>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio_keys: gpio-keys {
+		compatible = "gpio-keys";
+
+		button-a {
+			gpios = <&gpio_expander 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-A";
+			linux,code = <BTN_EAST>;
+		};
+
+		button-b {
+			gpios = <&gpio_expander 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-B";
+			linux,code = <BTN_SOUTH>;
+		};
+
+		button-down {
+			gpios = <&gpio_expander 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "DPAD-DOWN";
+			linux,code = <BTN_DPAD_DOWN>;
+		};
+
+		button-left {
+			gpios = <&gpio_expander 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "DPAD-LEFT";
+			linux,code = <BTN_DPAD_LEFT>;
+		};
+
+		button-right {
+			gpios = <&gpio_expander 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "DPAD-RIGHT";
+			linux,code = <BTN_DPAD_RIGHT>;
+		};
+
+		button-se {
+			gpios = <&gpio_expander 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-SELECT";
+			linux,code = <BTN_SELECT>;
+		};
+
+		button-st {
+			gpios = <&gpio_expander 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-START";
+			linux,code = <BTN_START>;
+		};
+
+		button-tl {
+			gpios = <&gpio_expander 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-L";
+			linux,code = <BTN_TL>;
+		};
+
+		button-tr {
+			gpios = <&gpio_expander 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-R";
+			linux,code = <BTN_TR>;
+		};
+
+		button-up {
+			gpios = <&gpio_expander 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "DPAD-UP";
+			linux,code = <BTN_DPAD_UP>;
+		};
+
+		button-x {
+			gpios = <&gpio_expander 11 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-X";
+			linux,code = <BTN_NORTH>;
+		};
+
+		button-y {
+			gpios = <&gpio_expander 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+			label = "BTN-Y";
+			linux,code = <BTN_WEST>;
+		};
+	};
+};
+
+&codec {
+	allwinner,audio-routing = "Headphone", "HP",
+				  "Headphone", "HPCOM",
+				  "MIC1", "Mic",
+				  "Mic", "HBIAS";
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+
+	gpio_expander: gpio@20 {
+		compatible = "nxp,pcal6416";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		interrupt-parent = <&pio>;
+		interrupts = <1 3 IRQ_TYPE_EDGE_BOTH>;
+	};
+
+	axp209: pmic@34 {
+		reg = <0x34>;
+		interrupt-parent = <&pio>;
+		interrupts = <1 5 IRQ_TYPE_EDGE_FALLING>;
+	};
+
+	pcf8563: rtc@51 {
+		compatible = "nxp,pcf8563";
+		reg = <0x51>;
+	};
+};
+
+#include "axp209.dtsi"
+
+&ac_power_supply {
+	status = "okay";
+};
+
+&battery_power_supply {
+	status = "okay";
+};
+
+&mmc0 {
+	broken-cd;
+	bus-width = <4>;
+	disable-wp;
+	vmmc-supply = <&reg_vcc3v3>;
+	vqmmc-supply = <&reg_vcc3v3>;
+	status = "okay";
+};
+
+&pwm {
+	status = "okay";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-max-microvolt = <1400000>;
+	regulator-min-microvolt = <1000000>;
+	regulator-name = "vdd-cpu-sys-ephy";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-max-microvolt = <3450000>;
+	regulator-min-microvolt = <3000000>;
+	regulator-name = "vcc-io-ephy-mcsi-usb";
+};
+
+&reg_ldo1 {
+	regulator-name = "vcc-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-max-microvolt = <3300000>;
+	regulator-min-microvolt = <2800000>;
+	regulator-name = "avcc-pll";
+};
+
+&spi0 {
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-0 = <&uart0_pb_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usb_power_supply {
+	status = "okay";
+};
+
+&usbphy {
+	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
-- 
2.34.1

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Andre Przywara]

On Tue, 20 Jun 2023 15:00:22 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:

Hi Chris,

thanks for sending this!
Is there some schematics for this somewhere? Or was this based on
information gathered from the stock firmware?

> From: Chris Morgan <macromorgan@hotmail.com>
> 
> The Anbernic RG-Nano is a small portable game device based on the
> Allwinner V3s SoC. It has GPIO buttons on the face and side for
> input, a single mono speaker, a 240x240 SPI controlled display,
> and a USB-C OTG port for power. The SoC includes 64MB of RAM and
> an SD card slot for booting.
> 
> The SPI display is currently unsupported, as it will either require
> a new tinydrm driver or changes to the staging fbtft driver to support.
> I plan on working on a tinydrm driver to properly support it. There
> also may be a missing mux in the audio path that must be discovered and
> defined before audio will be fully working (internal speaker does not
> work yet, external headphones untested).
> 
> Working:
> - SDMMC
> - Buttons
> - Charging/battery/PMIC
> 
> Not working:
> - Display
> - Audio
> 
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
>  arch/arm/boot/dts/Makefile                    |   1 +
>  .../boot/dts/sun8i-v3s-anbernic-rg-nano.dts   | 209 ++++++++++++++++++
>  2 files changed, 210 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 59829fc90315..31418b594222 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1414,6 +1414,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>  	sun8i-t113s-mangopi-mq-r-t113.dtb \
>  	sun8i-t3-cqa3t-bv3.dtb \
>  	sun8i-v3-sl631-imx179.dtb \
> +	sun8i-v3s-anbernic-rg-nano.dtb \
>  	sun8i-v3s-licheepi-zero.dtb \
>  	sun8i-v3s-licheepi-zero-dock.dtb \
>  	sun8i-v40-bananapi-m2-berry.dtb
> diff --git a/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> new file mode 100644
> index 000000000000..ead315e8fc38
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include "sun8i-v3s.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +/ {
> +	model = "Anbernic RG Nano";
> +	compatible = "anbernic,rg-nano", "allwinner,sun8i-v3s";
> +
> +	aliases {
> +		serial0 = &uart0;

Is that serial console actually usable, so are there pins or pads on the
PCB? Have you opened it up?

> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm 0 40000 1>;
> +		brightness-levels = <0 1 2 3 8 14 21 32 46 60 80 100>;
> +		default-brightness-level = <11>;
> +		power-supply = <&reg_vcc5v0>;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	gpio_keys: gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		button-a {
> +			gpios = <&gpio_expander 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-A";
> +			linux,code = <BTN_EAST>;
> +		};
> +
> +		button-b {
> +			gpios = <&gpio_expander 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-B";
> +			linux,code = <BTN_SOUTH>;
> +		};
> +
> +		button-down {
> +			gpios = <&gpio_expander 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "DPAD-DOWN";
> +			linux,code = <BTN_DPAD_DOWN>;
> +		};
> +
> +		button-left {
> +			gpios = <&gpio_expander 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "DPAD-LEFT";
> +			linux,code = <BTN_DPAD_LEFT>;
> +		};
> +
> +		button-right {
> +			gpios = <&gpio_expander 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "DPAD-RIGHT";
> +			linux,code = <BTN_DPAD_RIGHT>;
> +		};
> +
> +		button-se {
> +			gpios = <&gpio_expander 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-SELECT";
> +			linux,code = <BTN_SELECT>;
> +		};
> +
> +		button-st {
> +			gpios = <&gpio_expander 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-START";
> +			linux,code = <BTN_START>;
> +		};
> +
> +		button-tl {
> +			gpios = <&gpio_expander 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-L";
> +			linux,code = <BTN_TL>;
> +		};
> +
> +		button-tr {
> +			gpios = <&gpio_expander 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-R";
> +			linux,code = <BTN_TR>;
> +		};
> +
> +		button-up {
> +			gpios = <&gpio_expander 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "DPAD-UP";
> +			linux,code = <BTN_DPAD_UP>;
> +		};
> +
> +		button-x {
> +			gpios = <&gpio_expander 11 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-X";
> +			linux,code = <BTN_NORTH>;
> +		};
> +
> +		button-y {
> +			gpios = <&gpio_expander 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> +			label = "BTN-Y";
> +			linux,code = <BTN_WEST>;
> +		};
> +	};
> +};
> +
> +&codec {
> +	allwinner,audio-routing = "Headphone", "HP",
> +				  "Headphone", "HPCOM",
> +				  "MIC1", "Mic",
> +				  "Mic", "HBIAS";
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	status = "okay";
> +
> +	gpio_expander: gpio@20 {
> +		compatible = "nxp,pcal6416";
> +		reg = <0x20>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		interrupt-parent = <&pio>;
> +		interrupts = <1 3 IRQ_TYPE_EDGE_BOTH>;
> +	};
> +
> +	axp209: pmic@34 {
> +		reg = <0x34>;
> +		interrupt-parent = <&pio>;
> +		interrupts = <1 5 IRQ_TYPE_EDGE_FALLING>;
> +	};
> +
> +	pcf8563: rtc@51 {
> +		compatible = "nxp,pcf8563";
> +		reg = <0x51>;
> +	};
> +};
> +
> +#include "axp209.dtsi"
> +
> +&ac_power_supply {
> +	status = "okay";
> +};
> +
> +&battery_power_supply {
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	broken-cd;
> +	bus-width = <4>;
> +	disable-wp;
> +	vmmc-supply = <&reg_vcc3v3>;
> +	vqmmc-supply = <&reg_vcc3v3>;
> +	status = "okay";
> +};
> +
> +&pwm {
> +	status = "okay";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-max-microvolt = <1400000>;
> +	regulator-min-microvolt = <1000000>;

I think since it's not referenced anywhere, and it's always-on, it should
be just a single voltage, so the same value for both min and max. I guess
at least this voltage here needs to be fixed anyway, and it wouldn't
really work with a different value? Does the bootloader set something up
there, or is it the default value that's just kept?

> +	regulator-name = "vdd-cpu-sys-ephy";
> +};
> +
> +&reg_dcdc3 {
> +	regulator-always-on;
> +	regulator-max-microvolt = <3450000>;
> +	regulator-min-microvolt = <3000000>;

Same here, I guess: a single voltage.
If in doubt, you could pick the current voltage from
/sys/kernel/debug/regulator/regulator_summary and use that.

> +	regulator-name = "vcc-io-ephy-mcsi-usb";
> +};
> +
> +&reg_ldo1 {
> +	regulator-name = "vcc-rtc";
> +};
> +
> +&reg_ldo2 {
> +	regulator-always-on;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-min-microvolt = <2800000>;

same here.

> +	regulator-name = "avcc-pll";
> +};
> +
> +&spi0 {
> +	status = "okay";
> +};
> +
> +&uart0 {
> +	pinctrl-0 = <&uart0_pb_pins>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +};
> +
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
> +&usb_power_supply {
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> +	status = "okay";

So in the commit message you say "USB-C for power", but this here
describes a full featured USB port. So does that work? Can you use it as a
gadget, but also as a host?

Otherwise this looks alright to me.

Cheers,
Andre


> +};

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Chris Morgan]

On Wed, Jun 21, 2023 at 10:52:28AM +0100, Andre Przywara wrote:
> On Tue, 20 Jun 2023 15:00:22 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
> 
> Hi Chris,
> 
> thanks for sending this!
> Is there some schematics for this somewhere? Or was this based on
> information gathered from the stock firmware?
> 
> > From: Chris Morgan <macromorgan@hotmail.com>
> > 
> > The Anbernic RG-Nano is a small portable game device based on the
> > Allwinner V3s SoC. It has GPIO buttons on the face and side for
> > input, a single mono speaker, a 240x240 SPI controlled display,
> > and a USB-C OTG port for power. The SoC includes 64MB of RAM and
> > an SD card slot for booting.
> > 
> > The SPI display is currently unsupported, as it will either require
> > a new tinydrm driver or changes to the staging fbtft driver to support.
> > I plan on working on a tinydrm driver to properly support it. There
> > also may be a missing mux in the audio path that must be discovered and
> > defined before audio will be fully working (internal speaker does not
> > work yet, external headphones untested).
> > 
> > Working:
> > - SDMMC
> > - Buttons
> > - Charging/battery/PMIC
> > 
> > Not working:
> > - Display
> > - Audio
> > 
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > ---
> >  arch/arm/boot/dts/Makefile                    |   1 +
> >  .../boot/dts/sun8i-v3s-anbernic-rg-nano.dts   | 209 ++++++++++++++++++
> >  2 files changed, 210 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 59829fc90315..31418b594222 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -1414,6 +1414,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >  	sun8i-t113s-mangopi-mq-r-t113.dtb \
> >  	sun8i-t3-cqa3t-bv3.dtb \
> >  	sun8i-v3-sl631-imx179.dtb \
> > +	sun8i-v3s-anbernic-rg-nano.dtb \
> >  	sun8i-v3s-licheepi-zero.dtb \
> >  	sun8i-v3s-licheepi-zero-dock.dtb \
> >  	sun8i-v40-bananapi-m2-berry.dtb
> > diff --git a/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > new file mode 100644
> > index 000000000000..ead315e8fc38
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > @@ -0,0 +1,209 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +
> > +/dts-v1/;
> > +#include <dt-bindings/input/linux-event-codes.h>
> > +#include "sun8i-v3s.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +/ {
> > +	model = "Anbernic RG Nano";
> > +	compatible = "anbernic,rg-nano", "allwinner,sun8i-v3s";
> > +
> > +	aliases {
> > +		serial0 = &uart0;
> 
> Is that serial console actually usable, so are there pins or pads on the
> PCB? Have you opened it up?
> 

There are tx and rx pads exposed, and about a cm away a gnd pad also
exposed. Sadly I ripped the solder pad off of mine, so remaining
debugging is going on via ssh over USB gadget mode.

> > +	};
> > +
> > +	backlight: backlight {
> > +		compatible = "pwm-backlight";
> > +		pwms = <&pwm 0 40000 1>;
> > +		brightness-levels = <0 1 2 3 8 14 21 32 46 60 80 100>;
> > +		default-brightness-level = <11>;
> > +		power-supply = <&reg_vcc5v0>;
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:115200n8";
> > +	};
> > +
> > +	gpio_keys: gpio-keys {
> > +		compatible = "gpio-keys";
> > +
> > +		button-a {
> > +			gpios = <&gpio_expander 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-A";
> > +			linux,code = <BTN_EAST>;
> > +		};
> > +
> > +		button-b {
> > +			gpios = <&gpio_expander 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-B";
> > +			linux,code = <BTN_SOUTH>;
> > +		};
> > +
> > +		button-down {
> > +			gpios = <&gpio_expander 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "DPAD-DOWN";
> > +			linux,code = <BTN_DPAD_DOWN>;
> > +		};
> > +
> > +		button-left {
> > +			gpios = <&gpio_expander 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "DPAD-LEFT";
> > +			linux,code = <BTN_DPAD_LEFT>;
> > +		};
> > +
> > +		button-right {
> > +			gpios = <&gpio_expander 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "DPAD-RIGHT";
> > +			linux,code = <BTN_DPAD_RIGHT>;
> > +		};
> > +
> > +		button-se {
> > +			gpios = <&gpio_expander 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-SELECT";
> > +			linux,code = <BTN_SELECT>;
> > +		};
> > +
> > +		button-st {
> > +			gpios = <&gpio_expander 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-START";
> > +			linux,code = <BTN_START>;
> > +		};
> > +
> > +		button-tl {
> > +			gpios = <&gpio_expander 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-L";
> > +			linux,code = <BTN_TL>;
> > +		};
> > +
> > +		button-tr {
> > +			gpios = <&gpio_expander 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-R";
> > +			linux,code = <BTN_TR>;
> > +		};
> > +
> > +		button-up {
> > +			gpios = <&gpio_expander 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "DPAD-UP";
> > +			linux,code = <BTN_DPAD_UP>;
> > +		};
> > +
> > +		button-x {
> > +			gpios = <&gpio_expander 11 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-X";
> > +			linux,code = <BTN_NORTH>;
> > +		};
> > +
> > +		button-y {
> > +			gpios = <&gpio_expander 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > +			label = "BTN-Y";
> > +			linux,code = <BTN_WEST>;
> > +		};
> > +	};
> > +};
> > +
> > +&codec {
> > +	allwinner,audio-routing = "Headphone", "HP",
> > +				  "Headphone", "HPCOM",
> > +				  "MIC1", "Mic",
> > +				  "Mic", "HBIAS";
> > +	status = "okay";
> > +};
> > +
> > +&i2c0 {
> > +	status = "okay";
> > +
> > +	gpio_expander: gpio@20 {
> > +		compatible = "nxp,pcal6416";
> > +		reg = <0x20>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +		#interrupt-cells = <2>;
> > +		interrupt-controller;
> > +		interrupt-parent = <&pio>;
> > +		interrupts = <1 3 IRQ_TYPE_EDGE_BOTH>;
> > +	};
> > +
> > +	axp209: pmic@34 {
> > +		reg = <0x34>;
> > +		interrupt-parent = <&pio>;
> > +		interrupts = <1 5 IRQ_TYPE_EDGE_FALLING>;
> > +	};
> > +
> > +	pcf8563: rtc@51 {
> > +		compatible = "nxp,pcf8563";
> > +		reg = <0x51>;
> > +	};
> > +};
> > +
> > +#include "axp209.dtsi"
> > +
> > +&ac_power_supply {
> > +	status = "okay";
> > +};
> > +
> > +&battery_power_supply {
> > +	status = "okay";
> > +};
> > +
> > +&mmc0 {
> > +	broken-cd;
> > +	bus-width = <4>;
> > +	disable-wp;
> > +	vmmc-supply = <&reg_vcc3v3>;
> > +	vqmmc-supply = <&reg_vcc3v3>;
> > +	status = "okay";
> > +};
> > +
> > +&pwm {
> > +	status = "okay";
> > +};
> > +
> > +&reg_dcdc2 {
> > +	regulator-always-on;
> > +	regulator-max-microvolt = <1400000>;
> > +	regulator-min-microvolt = <1000000>;
> 
> I think since it's not referenced anywhere, and it's always-on, it should
> be just a single voltage, so the same value for both min and max. I guess
> at least this voltage here needs to be fixed anyway, and it wouldn't
> really work with a different value? Does the bootloader set something up
> there, or is it the default value that's just kept?

It's always on at 1.25v according to the schematic. I also plan to move
this devicetree to mainline U-Boot, so best to get it right here and
there. Do you think just setting 1250000 for min and max works then?

> 
> > +	regulator-name = "vdd-cpu-sys-ephy";
> > +};
> > +
> > +&reg_dcdc3 {
> > +	regulator-always-on;
> > +	regulator-max-microvolt = <3450000>;
> > +	regulator-min-microvolt = <3000000>;
> 
> Same here, I guess: a single voltage.
> If in doubt, you could pick the current voltage from
> /sys/kernel/debug/regulator/regulator_summary and use that.

This is a fixed 3.3v. Honestly I think this is output for the entire
"3.3v rail" if I'm reading the schematics right.

> 
> > +	regulator-name = "vcc-io-ephy-mcsi-usb";
> > +};
> > +
> > +&reg_ldo1 {
> > +	regulator-name = "vcc-rtc";

Here's one I could use some advice on actually. The existing driver
has a constraint holding this at 1.3v, however I need to run it at
3.3v since it's hooked up to an external RTC that needs 3.3v. Any
thoughts on how to tell the regulator "always be 1.3v, unless a
voltage is explicitly specified")?

> > +};
> > +
> > +&reg_ldo2 {
> > +	regulator-always-on;
> > +	regulator-max-microvolt = <3300000>;
> > +	regulator-min-microvolt = <2800000>;
> 
> same here.

Fixed 3.0v, again if I'm reading correctly.

> 
> > +	regulator-name = "avcc-pll";
> > +};
> > +
> > +&spi0 {
> > +	status = "okay";
> > +};
> > +
> > +&uart0 {
> > +	pinctrl-0 = <&uart0_pb_pins>;
> > +	pinctrl-names = "default";
> > +	status = "okay";
> > +};
> > +
> > +&usb_otg {
> > +	dr_mode = "otg";
> > +	status = "okay";
> > +};
> > +
> > +&usb_power_supply {
> > +	status = "okay";
> > +};
> > +
> > +&usbphy {
> > +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> > +	status = "okay";
> 
> So in the commit message you say "USB-C for power", but this here
> describes a full featured USB port. So does that work? Can you use it as a
> gadget, but also as a host?

Yes, it's an OTG port with the ID pin pulled to ground. I have it set
as a peripherial on mine so I can ssh via ethernet gadget (since I
broke my solder pads for serial), but it also acts as a host for the
included "USB audio dongle" which is just a simple USB DAC (and not
using any analog pins).

Also, I noticed that usb0_id_det-gpios is wrong, so I changed it.

> 
> Otherwise this looks alright to me.
> 
> Cheers,
> Andre
> 
> 
> > +};
> 

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Andre Przywara]

On Tue, 27 Jun 2023 12:49:05 -0500
Chris Morgan <macromorgan@hotmail.com> wrote:

Hi Chris,

> On Wed, Jun 21, 2023 at 10:52:28AM +0100, Andre Przywara wrote:
> > On Tue, 20 Jun 2023 15:00:22 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
> > 
> > Hi Chris,
> > 
> > thanks for sending this!
> > Is there some schematics for this somewhere? Or was this based on
> > information gathered from the stock firmware?
> >   
> > > From: Chris Morgan <macromorgan@hotmail.com>
> > > 
> > > The Anbernic RG-Nano is a small portable game device based on the
> > > Allwinner V3s SoC. It has GPIO buttons on the face and side for
> > > input, a single mono speaker, a 240x240 SPI controlled display,
> > > and a USB-C OTG port for power. The SoC includes 64MB of RAM and
> > > an SD card slot for booting.
> > > 
> > > The SPI display is currently unsupported, as it will either require
> > > a new tinydrm driver or changes to the staging fbtft driver to support.
> > > I plan on working on a tinydrm driver to properly support it. There
> > > also may be a missing mux in the audio path that must be discovered and
> > > defined before audio will be fully working (internal speaker does not
> > > work yet, external headphones untested).
> > > 
> > > Working:
> > > - SDMMC
> > > - Buttons
> > > - Charging/battery/PMIC
> > > 
> > > Not working:
> > > - Display
> > > - Audio
> > > 
> > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > > ---
> > >  arch/arm/boot/dts/Makefile                    |   1 +
> > >  .../boot/dts/sun8i-v3s-anbernic-rg-nano.dts   | 209 ++++++++++++++++++
> > >  2 files changed, 210 insertions(+)
> > >  create mode 100644 arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > > 
> > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > > index 59829fc90315..31418b594222 100644
> > > --- a/arch/arm/boot/dts/Makefile
> > > +++ b/arch/arm/boot/dts/Makefile
> > > @@ -1414,6 +1414,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> > >  	sun8i-t113s-mangopi-mq-r-t113.dtb \
> > >  	sun8i-t3-cqa3t-bv3.dtb \
> > >  	sun8i-v3-sl631-imx179.dtb \
> > > +	sun8i-v3s-anbernic-rg-nano.dtb \
> > >  	sun8i-v3s-licheepi-zero.dtb \
> > >  	sun8i-v3s-licheepi-zero-dock.dtb \
> > >  	sun8i-v40-bananapi-m2-berry.dtb
> > > diff --git a/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > > new file mode 100644
> > > index 000000000000..ead315e8fc38
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > > @@ -0,0 +1,209 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +
> > > +/dts-v1/;
> > > +#include <dt-bindings/input/linux-event-codes.h>
> > > +#include "sun8i-v3s.dtsi"
> > > +#include "sunxi-common-regulators.dtsi"
> > > +
> > > +/ {
> > > +	model = "Anbernic RG Nano";
> > > +	compatible = "anbernic,rg-nano", "allwinner,sun8i-v3s";
> > > +
> > > +	aliases {
> > > +		serial0 = &uart0;  
> > 
> > Is that serial console actually usable, so are there pins or pads on the
> > PCB? Have you opened it up?
> >   
> 
> There are tx and rx pads exposed, and about a cm away a gnd pad also
> exposed. Sadly I ripped the solder pad off of mine, so remaining
> debugging is going on via ssh over USB gadget mode.

Good, thanks, then it should be indeed in the DT.

> > > +	};
> > > +
> > > +	backlight: backlight {
> > > +		compatible = "pwm-backlight";
> > > +		pwms = <&pwm 0 40000 1>;
> > > +		brightness-levels = <0 1 2 3 8 14 21 32 46 60 80 100>;
> > > +		default-brightness-level = <11>;
> > > +		power-supply = <&reg_vcc5v0>;
> > > +	};
> > > +
> > > +	chosen {
> > > +		stdout-path = "serial0:115200n8";
> > > +	};
> > > +
> > > +	gpio_keys: gpio-keys {
> > > +		compatible = "gpio-keys";
> > > +
> > > +		button-a {
> > > +			gpios = <&gpio_expander 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-A";
> > > +			linux,code = <BTN_EAST>;
> > > +		};
> > > +
> > > +		button-b {
> > > +			gpios = <&gpio_expander 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-B";
> > > +			linux,code = <BTN_SOUTH>;
> > > +		};
> > > +
> > > +		button-down {
> > > +			gpios = <&gpio_expander 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "DPAD-DOWN";
> > > +			linux,code = <BTN_DPAD_DOWN>;
> > > +		};
> > > +
> > > +		button-left {
> > > +			gpios = <&gpio_expander 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "DPAD-LEFT";
> > > +			linux,code = <BTN_DPAD_LEFT>;
> > > +		};
> > > +
> > > +		button-right {
> > > +			gpios = <&gpio_expander 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "DPAD-RIGHT";
> > > +			linux,code = <BTN_DPAD_RIGHT>;
> > > +		};
> > > +
> > > +		button-se {
> > > +			gpios = <&gpio_expander 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-SELECT";
> > > +			linux,code = <BTN_SELECT>;
> > > +		};
> > > +
> > > +		button-st {
> > > +			gpios = <&gpio_expander 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-START";
> > > +			linux,code = <BTN_START>;
> > > +		};
> > > +
> > > +		button-tl {
> > > +			gpios = <&gpio_expander 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-L";
> > > +			linux,code = <BTN_TL>;
> > > +		};
> > > +
> > > +		button-tr {
> > > +			gpios = <&gpio_expander 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-R";
> > > +			linux,code = <BTN_TR>;
> > > +		};
> > > +
> > > +		button-up {
> > > +			gpios = <&gpio_expander 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "DPAD-UP";
> > > +			linux,code = <BTN_DPAD_UP>;
> > > +		};
> > > +
> > > +		button-x {
> > > +			gpios = <&gpio_expander 11 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-X";
> > > +			linux,code = <BTN_NORTH>;
> > > +		};
> > > +
> > > +		button-y {
> > > +			gpios = <&gpio_expander 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > +			label = "BTN-Y";
> > > +			linux,code = <BTN_WEST>;
> > > +		};
> > > +	};
> > > +};
> > > +
> > > +&codec {
> > > +	allwinner,audio-routing = "Headphone", "HP",
> > > +				  "Headphone", "HPCOM",
> > > +				  "MIC1", "Mic",
> > > +				  "Mic", "HBIAS";
> > > +	status = "okay";
> > > +};
> > > +
> > > +&i2c0 {
> > > +	status = "okay";
> > > +
> > > +	gpio_expander: gpio@20 {
> > > +		compatible = "nxp,pcal6416";
> > > +		reg = <0x20>;
> > > +		gpio-controller;
> > > +		#gpio-cells = <2>;
> > > +		#interrupt-cells = <2>;
> > > +		interrupt-controller;
> > > +		interrupt-parent = <&pio>;
> > > +		interrupts = <1 3 IRQ_TYPE_EDGE_BOTH>;
> > > +	};
> > > +
> > > +	axp209: pmic@34 {
> > > +		reg = <0x34>;
> > > +		interrupt-parent = <&pio>;
> > > +		interrupts = <1 5 IRQ_TYPE_EDGE_FALLING>;
> > > +	};
> > > +
> > > +	pcf8563: rtc@51 {
> > > +		compatible = "nxp,pcf8563";
> > > +		reg = <0x51>;
> > > +	};
> > > +};
> > > +
> > > +#include "axp209.dtsi"
> > > +
> > > +&ac_power_supply {
> > > +	status = "okay";
> > > +};
> > > +
> > > +&battery_power_supply {
> > > +	status = "okay";
> > > +};
> > > +
> > > +&mmc0 {
> > > +	broken-cd;
> > > +	bus-width = <4>;
> > > +	disable-wp;
> > > +	vmmc-supply = <&reg_vcc3v3>;
> > > +	vqmmc-supply = <&reg_vcc3v3>;
> > > +	status = "okay";
> > > +};
> > > +
> > > +&pwm {
> > > +	status = "okay";
> > > +};
> > > +
> > > +&reg_dcdc2 {
> > > +	regulator-always-on;
> > > +	regulator-max-microvolt = <1400000>;
> > > +	regulator-min-microvolt = <1000000>;  
> > 
> > I think since it's not referenced anywhere, and it's always-on, it should
> > be just a single voltage, so the same value for both min and max. I guess
> > at least this voltage here needs to be fixed anyway, and it wouldn't
> > really work with a different value? Does the bootloader set something up
> > there, or is it the default value that's just kept?  
> 
> It's always on at 1.25v according to the schematic. I also plan to move
> this devicetree to mainline U-Boot,

This will happen anyway: we only *copy* DTs from the kernel tree into
the U-Boot tree, minus some minor changes (for include paths, for
instance).

> so best to get it right here and
> there. Do you think just setting 1250000 for min and max works then?

Definitely, especially if the schematic says so, the DT should follow
this. Ranges are really only useful when the device attached requires
or supports this, for instance an SD card with voltage switching, or
the CPU supply. Since there is no reference to that regulator, there is
no device that could request a change, and the kernel has no clue what
to actually set it to, it just makes sure that it is in range. Where
does the range come from in the first place? Schematics or vendor
code/DT?

> > > +	regulator-name = "vdd-cpu-sys-ephy";
> > > +};
> > > +
> > > +&reg_dcdc3 {
> > > +	regulator-always-on;
> > > +	regulator-max-microvolt = <3450000>;
> > > +	regulator-min-microvolt = <3000000>;  
> > 
> > Same here, I guess: a single voltage.
> > If in doubt, you could pick the current voltage from
> > /sys/kernel/debug/regulator/regulator_summary and use that.  
> 
> This is a fixed 3.3v. Honestly I think this is output for the entire
> "3.3v rail" if I'm reading the schematics right.

Quite likely. The AXP209 datasheet mentions DRAM as the typical
application, but I think it's used here for the main 3.3V I/O rail.
Many devices work with 3.0V as well, but if the schematic says 3.3V,
we should go with this. Can you check the values when running the BSP
kernel?
 
> >   
> > > +	regulator-name = "vcc-io-ephy-mcsi-usb";
> > > +};
> > > +
> > > +&reg_ldo1 {
> > > +	regulator-name = "vcc-rtc";  
> 
> Here's one I could use some advice on actually. The existing driver
> has a constraint holding this at 1.3v, however I need to run it at
> 3.3v since it's hooked up to an external RTC that needs 3.3v. Any
> thoughts on how to tell the regulator "always be 1.3v, unless a
> voltage is explicitly specified")?

Well, that's one case that the driver doesn't really cover: this
regulator is always-on (by hardware) and has a fixed voltage. Which
one that is is set by the LDO1SET pin, so software has absolutely no
control over it. So any value you put in here is actually irrelevant.
However this is used to report the voltage, so we should relax the
driver code to also accept 3.3V.
What happens exactly when you put 3.3V in there? Does the whole driver
refuse to load, with an error message? Then I am tempted to put 1.3V in,
plus a comment about the problem.
If this is just a warning or non-fatal massage, we should use 3.3V.

And push for a driver fix in both cases.

> > > +};
> > > +
> > > +&reg_ldo2 {
> > > +	regulator-always-on;
> > > +	regulator-max-microvolt = <3300000>;
> > > +	regulator-min-microvolt = <2800000>;  
> > 
> > same here.  
> 
> Fixed 3.0v, again if I'm reading correctly.

3.0V sounds about right for a PLL supply, so yes: please use
min = max = 3.0V.

> >   
> > > +	regulator-name = "avcc-pll";
> > > +};
> > > +
> > > +&spi0 {
> > > +	status = "okay";
> > > +};
> > > +
> > > +&uart0 {
> > > +	pinctrl-0 = <&uart0_pb_pins>;
> > > +	pinctrl-names = "default";
> > > +	status = "okay";
> > > +};
> > > +
> > > +&usb_otg {
> > > +	dr_mode = "otg";
> > > +	status = "okay";
> > > +};
> > > +
> > > +&usb_power_supply {
> > > +	status = "okay";
> > > +};
> > > +
> > > +&usbphy {
> > > +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;

Where is this pin connected to, in the USB-C connector? One of the CC
pins?

> > > +	status = "okay";  
> > 
> > So in the commit message you say "USB-C for power", but this here
> > describes a full featured USB port. So does that work? Can you use it as a
> > gadget, but also as a host?  
> 
> Yes, it's an OTG port with the ID pin pulled to ground.

Do you mean both CC pins? IIRC this means it's hardwired as a
peripheral (UFP).

If I ignore the ID pin above, this looks like on the OrangePi Zero2 or
the MangoPi MQ-R. In those cases we put peripheral in the DT, as this
is what this connection seems to indicate. That *can* be used a host as
well, with the "right" cable, but it's not really a well supported
configuration, so we leave this up to people to change this locally,
should they really desire so.

Cheers,
Andre

> I have it set
> as a peripherial on mine so I can ssh via ethernet gadget (since I
> broke my solder pads for serial), but it also acts as a host for the
> included "USB audio dongle" which is just a simple USB DAC (and not
> using any analog pins).
> 
> Also, I noticed that usb0_id_det-gpios is wrong, so I changed it.
> 
> > 
> > Otherwise this looks alright to me.
> > 
> > Cheers,
> > Andre
> > 
> >   
> > > +};  
> >   
> 

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Chris Morgan]

On Thu, Jun 29, 2023 at 08:34:10PM +0100, Andre Przywara wrote:
> On Tue, 27 Jun 2023 12:49:05 -0500
> Chris Morgan <macromorgan@hotmail.com> wrote:
> 
> Hi Chris,
> 
> > On Wed, Jun 21, 2023 at 10:52:28AM +0100, Andre Przywara wrote:
> > > On Tue, 20 Jun 2023 15:00:22 -0500
> > > Chris Morgan <macroalpha82@gmail.com> wrote:
> > > 
> > > Hi Chris,
> > > 
> > > thanks for sending this!
> > > Is there some schematics for this somewhere? Or was this based on
> > > information gathered from the stock firmware?
> > >   
> > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > > 
> > > > The Anbernic RG-Nano is a small portable game device based on the
> > > > Allwinner V3s SoC. It has GPIO buttons on the face and side for
> > > > input, a single mono speaker, a 240x240 SPI controlled display,
> > > > and a USB-C OTG port for power. The SoC includes 64MB of RAM and
> > > > an SD card slot for booting.
> > > > 
> > > > The SPI display is currently unsupported, as it will either require
> > > > a new tinydrm driver or changes to the staging fbtft driver to support.
> > > > I plan on working on a tinydrm driver to properly support it. There
> > > > also may be a missing mux in the audio path that must be discovered and
> > > > defined before audio will be fully working (internal speaker does not
> > > > work yet, external headphones untested).
> > > > 
> > > > Working:
> > > > - SDMMC
> > > > - Buttons
> > > > - Charging/battery/PMIC
> > > > 
> > > > Not working:
> > > > - Display
> > > > - Audio
> > > > 
> > > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > > > ---
> > > >  arch/arm/boot/dts/Makefile                    |   1 +
> > > >  .../boot/dts/sun8i-v3s-anbernic-rg-nano.dts   | 209 ++++++++++++++++++
> > > >  2 files changed, 210 insertions(+)
> > > >  create mode 100644 arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > > > 
> > > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > > > index 59829fc90315..31418b594222 100644
> > > > --- a/arch/arm/boot/dts/Makefile
> > > > +++ b/arch/arm/boot/dts/Makefile
> > > > @@ -1414,6 +1414,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> > > >  	sun8i-t113s-mangopi-mq-r-t113.dtb \
> > > >  	sun8i-t3-cqa3t-bv3.dtb \
> > > >  	sun8i-v3-sl631-imx179.dtb \
> > > > +	sun8i-v3s-anbernic-rg-nano.dtb \
> > > >  	sun8i-v3s-licheepi-zero.dtb \
> > > >  	sun8i-v3s-licheepi-zero-dock.dtb \
> > > >  	sun8i-v40-bananapi-m2-berry.dtb
> > > > diff --git a/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > > > new file mode 100644
> > > > index 000000000000..ead315e8fc38
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/sun8i-v3s-anbernic-rg-nano.dts
> > > > @@ -0,0 +1,209 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > +
> > > > +/dts-v1/;
> > > > +#include <dt-bindings/input/linux-event-codes.h>
> > > > +#include "sun8i-v3s.dtsi"
> > > > +#include "sunxi-common-regulators.dtsi"
> > > > +
> > > > +/ {
> > > > +	model = "Anbernic RG Nano";
> > > > +	compatible = "anbernic,rg-nano", "allwinner,sun8i-v3s";
> > > > +
> > > > +	aliases {
> > > > +		serial0 = &uart0;  
> > > 
> > > Is that serial console actually usable, so are there pins or pads on the
> > > PCB? Have you opened it up?
> > >   
> > 
> > There are tx and rx pads exposed, and about a cm away a gnd pad also
> > exposed. Sadly I ripped the solder pad off of mine, so remaining
> > debugging is going on via ssh over USB gadget mode.
> 
> Good, thanks, then it should be indeed in the DT.
> 
> > > > +	};
> > > > +
> > > > +	backlight: backlight {
> > > > +		compatible = "pwm-backlight";
> > > > +		pwms = <&pwm 0 40000 1>;
> > > > +		brightness-levels = <0 1 2 3 8 14 21 32 46 60 80 100>;
> > > > +		default-brightness-level = <11>;
> > > > +		power-supply = <&reg_vcc5v0>;
> > > > +	};
> > > > +
> > > > +	chosen {
> > > > +		stdout-path = "serial0:115200n8";
> > > > +	};
> > > > +
> > > > +	gpio_keys: gpio-keys {
> > > > +		compatible = "gpio-keys";
> > > > +
> > > > +		button-a {
> > > > +			gpios = <&gpio_expander 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-A";
> > > > +			linux,code = <BTN_EAST>;
> > > > +		};
> > > > +
> > > > +		button-b {
> > > > +			gpios = <&gpio_expander 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-B";
> > > > +			linux,code = <BTN_SOUTH>;
> > > > +		};
> > > > +
> > > > +		button-down {
> > > > +			gpios = <&gpio_expander 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "DPAD-DOWN";
> > > > +			linux,code = <BTN_DPAD_DOWN>;
> > > > +		};
> > > > +
> > > > +		button-left {
> > > > +			gpios = <&gpio_expander 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "DPAD-LEFT";
> > > > +			linux,code = <BTN_DPAD_LEFT>;
> > > > +		};
> > > > +
> > > > +		button-right {
> > > > +			gpios = <&gpio_expander 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "DPAD-RIGHT";
> > > > +			linux,code = <BTN_DPAD_RIGHT>;
> > > > +		};
> > > > +
> > > > +		button-se {
> > > > +			gpios = <&gpio_expander 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-SELECT";
> > > > +			linux,code = <BTN_SELECT>;
> > > > +		};
> > > > +
> > > > +		button-st {
> > > > +			gpios = <&gpio_expander 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-START";
> > > > +			linux,code = <BTN_START>;
> > > > +		};
> > > > +
> > > > +		button-tl {
> > > > +			gpios = <&gpio_expander 2 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-L";
> > > > +			linux,code = <BTN_TL>;
> > > > +		};
> > > > +
> > > > +		button-tr {
> > > > +			gpios = <&gpio_expander 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-R";
> > > > +			linux,code = <BTN_TR>;
> > > > +		};
> > > > +
> > > > +		button-up {
> > > > +			gpios = <&gpio_expander 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "DPAD-UP";
> > > > +			linux,code = <BTN_DPAD_UP>;
> > > > +		};
> > > > +
> > > > +		button-x {
> > > > +			gpios = <&gpio_expander 11 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-X";
> > > > +			linux,code = <BTN_NORTH>;
> > > > +		};
> > > > +
> > > > +		button-y {
> > > > +			gpios = <&gpio_expander 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
> > > > +			label = "BTN-Y";
> > > > +			linux,code = <BTN_WEST>;
> > > > +		};
> > > > +	};
> > > > +};
> > > > +
> > > > +&codec {
> > > > +	allwinner,audio-routing = "Headphone", "HP",
> > > > +				  "Headphone", "HPCOM",
> > > > +				  "MIC1", "Mic",
> > > > +				  "Mic", "HBIAS";
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&i2c0 {
> > > > +	status = "okay";
> > > > +
> > > > +	gpio_expander: gpio@20 {
> > > > +		compatible = "nxp,pcal6416";
> > > > +		reg = <0x20>;
> > > > +		gpio-controller;
> > > > +		#gpio-cells = <2>;
> > > > +		#interrupt-cells = <2>;
> > > > +		interrupt-controller;
> > > > +		interrupt-parent = <&pio>;
> > > > +		interrupts = <1 3 IRQ_TYPE_EDGE_BOTH>;
> > > > +	};
> > > > +
> > > > +	axp209: pmic@34 {
> > > > +		reg = <0x34>;
> > > > +		interrupt-parent = <&pio>;
> > > > +		interrupts = <1 5 IRQ_TYPE_EDGE_FALLING>;
> > > > +	};
> > > > +
> > > > +	pcf8563: rtc@51 {
> > > > +		compatible = "nxp,pcf8563";
> > > > +		reg = <0x51>;
> > > > +	};
> > > > +};
> > > > +
> > > > +#include "axp209.dtsi"
> > > > +
> > > > +&ac_power_supply {
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&battery_power_supply {
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&mmc0 {
> > > > +	broken-cd;
> > > > +	bus-width = <4>;
> > > > +	disable-wp;
> > > > +	vmmc-supply = <&reg_vcc3v3>;
> > > > +	vqmmc-supply = <&reg_vcc3v3>;
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&pwm {
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&reg_dcdc2 {
> > > > +	regulator-always-on;
> > > > +	regulator-max-microvolt = <1400000>;
> > > > +	regulator-min-microvolt = <1000000>;  
> > > 
> > > I think since it's not referenced anywhere, and it's always-on, it should
> > > be just a single voltage, so the same value for both min and max. I guess
> > > at least this voltage here needs to be fixed anyway, and it wouldn't
> > > really work with a different value? Does the bootloader set something up
> > > there, or is it the default value that's just kept?  
> > 
> > It's always on at 1.25v according to the schematic. I also plan to move
> > this devicetree to mainline U-Boot,
> 
> This will happen anyway: we only *copy* DTs from the kernel tree into
> the U-Boot tree, minus some minor changes (for include paths, for
> instance).
> 
> > so best to get it right here and
> > there. Do you think just setting 1250000 for min and max works then?
> 
> Definitely, especially if the schematic says so, the DT should follow
> this. Ranges are really only useful when the device attached requires
> or supports this, for instance an SD card with voltage switching, or
> the CPU supply. Since there is no reference to that regulator, there is
> no device that could request a change, and the kernel has no clue what
> to actually set it to, it just makes sure that it is in range. Where
> does the range come from in the first place? Schematics or vendor
> code/DT?

The ranges come from the vendor code, the schematics have it hard coded.

> 
> > > > +	regulator-name = "vdd-cpu-sys-ephy";
> > > > +};
> > > > +
> > > > +&reg_dcdc3 {
> > > > +	regulator-always-on;
> > > > +	regulator-max-microvolt = <3450000>;
> > > > +	regulator-min-microvolt = <3000000>;  
> > > 
> > > Same here, I guess: a single voltage.
> > > If in doubt, you could pick the current voltage from
> > > /sys/kernel/debug/regulator/regulator_summary and use that.  
> > 
> > This is a fixed 3.3v. Honestly I think this is output for the entire
> > "3.3v rail" if I'm reading the schematics right.
> 
> Quite likely. The AXP209 datasheet mentions DRAM as the typical
> application, but I think it's used here for the main 3.3V I/O rail.
> Many devices work with 3.0V as well, but if the schematic says 3.3V,
> we should go with this. Can you check the values when running the BSP
> kernel?

Not currently unfortunately. I can't get the output because I no longer
have serial access on the device due to the solder pad I killed. The
schematics have this going to every 3.3v rail though, so I think that's
what this really should be.

>  
> > >   
> > > > +	regulator-name = "vcc-io-ephy-mcsi-usb";
> > > > +};
> > > > +
> > > > +&reg_ldo1 {
> > > > +	regulator-name = "vcc-rtc";  
> > 
> > Here's one I could use some advice on actually. The existing driver
> > has a constraint holding this at 1.3v, however I need to run it at
> > 3.3v since it's hooked up to an external RTC that needs 3.3v. Any
> > thoughts on how to tell the regulator "always be 1.3v, unless a
> > voltage is explicitly specified")?
> 
> Well, that's one case that the driver doesn't really cover: this
> regulator is always-on (by hardware) and has a fixed voltage. Which
> one that is is set by the LDO1SET pin, so software has absolutely no
> control over it. So any value you put in here is actually irrelevant.
> However this is used to report the voltage, so we should relax the
> driver code to also accept 3.3V.
> What happens exactly when you put 3.3V in there? Does the whole driver
> refuse to load, with an error message? Then I am tempted to put 1.3V in,
> plus a comment about the problem.
> If this is just a warning or non-fatal massage, we should use 3.3V.
> 
> And push for a driver fix in both cases.

It's set to vint which according to the axp209 datasheet means it's
3.3v.

When I put 3.3v in there this specific regulator doesn't probe. I get
the following in dmesg:

[    1.659577] ldo1: failed to apply 3000000-3000000uV constraint: -EINVAL
[    1.671718] axp20x-regulator axp20x-regulator: Failed to register ldo1
[    1.678418] axp20x-regulator: probe of axp20x-regulator failed with error -22
[    1.758489] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable.

So not only is the regulator failing to load, it seems to be causing
issues with the rtc. (Also, thinking I should disable the built-in
allwinner rtc since there is this external one, yes?).

> 
> > > > +};
> > > > +
> > > > +&reg_ldo2 {
> > > > +	regulator-always-on;
> > > > +	regulator-max-microvolt = <3300000>;
> > > > +	regulator-min-microvolt = <2800000>;  
> > > 
> > > same here.  
> > 
> > Fixed 3.0v, again if I'm reading correctly.
> 
> 3.0V sounds about right for a PLL supply, so yes: please use
> min = max = 3.0V.
> 
> > >   
> > > > +	regulator-name = "avcc-pll";
> > > > +};
> > > > +
> > > > +&spi0 {
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&uart0 {
> > > > +	pinctrl-0 = <&uart0_pb_pins>;
> > > > +	pinctrl-names = "default";
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&usb_otg {
> > > > +	dr_mode = "otg";
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&usb_power_supply {
> > > > +	status = "okay";
> > > > +};
> > > > +
> > > > +&usbphy {
> > > > +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> 
> Where is this pin connected to, in the USB-C connector? One of the CC
> pins?

None of the above. The vendor tree has this wrong and it's actually
connected to the speaker amplifier. I've corrected this in the next
version to be upstreamed and can confirm audio is 100% working now.

> 
> > > > +	status = "okay";  
> > > 
> > > So in the commit message you say "USB-C for power", but this here
> > > describes a full featured USB port. So does that work? Can you use it as a
> > > gadget, but also as a host?  
> > 
> > Yes, it's an OTG port with the ID pin pulled to ground.
> 
> Do you mean both CC pins? IIRC this means it's hardwired as a
> peripheral (UFP).
> 
> If I ignore the ID pin above, this looks like on the OrangePi Zero2 or
> the MangoPi MQ-R. In those cases we put peripheral in the DT, as this
> is what this connection seems to indicate. That *can* be used a host as
> well, with the "right" cable, but it's not really a well supported
> configuration, so we leave this up to people to change this locally,
> should they really desire so.

I... actually don't have schematics for this part. I'm working off of
the funkey schematics which this device is 99% a clone of, but this
device uses a USB-C connector whereas the Funkey S seems to use a
micro USB.  Sadly I'm flying blind here because not only do I not
have schematics but the BSP device tree is wrong. For now I can confirm
the port works perfectly fine as a peripheral port, however I know
the BSP also has it working as a host (since it came in the box
with a USB-C to analog dongle that is basically a USB sound card).
Hopefully once I get the screen working I can debug it a little easier
without serial.

I've made the necessary changes on the tree otherwise, and can update
the axp209 driver to remove the ldo1 constraint. The last piece I noticed
is a missing clock frequency/clock latency/operating points that dmesg
complains about. Should I add that to the parent sun8i-v3s.dtsi or this
device specific tree?

Thank you.

> 
> Cheers,
> Andre
> 
> > I have it set
> > as a peripherial on mine so I can ssh via ethernet gadget (since I
> > broke my solder pads for serial), but it also acts as a host for the
> > included "USB audio dongle" which is just a simple USB DAC (and not
> > using any analog pins).
> > 
> > Also, I noticed that usb0_id_det-gpios is wrong, so I changed it.
> > 
> > > 
> > > Otherwise this looks alright to me.
> > > 
> > > Cheers,
> > > Andre
> > > 
> > >   
> > > > +};  
> > >   
> > 
> 

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Maxime Ripard]

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

On Thu, Jun 29, 2023 at 08:34:10PM +0100, Andre Przywara wrote:
> > > > +&usbphy {
> > > > +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> 
> Where is this pin connected to, in the USB-C connector? One of the CC
> pins?
> 
> > > > +	status = "okay";  
> > > 
> > > So in the commit message you say "USB-C for power", but this here
> > > describes a full featured USB port. So does that work? Can you use it as a
> > > gadget, but also as a host?  
> > 
> > Yes, it's an OTG port with the ID pin pulled to ground.
> 
> Do you mean both CC pins? IIRC this means it's hardwired as a
> peripheral (UFP).
> 
> If I ignore the ID pin above, this looks like on the OrangePi Zero2 or
> the MangoPi MQ-R. In those cases we put peripheral in the DT, as this
> is what this connection seems to indicate. That *can* be used a host as
> well, with the "right" cable, but it's not really a well supported
> configuration, so we leave this up to people to change this locally,
> should they really desire so.

The ID pin above is exactly what makes "the right cable" works:
depending on the state of the ID pin the controller will act either as a
peripheral or a host. Dual-mode works just fine, so if the hardware
supports it there's no reason not to enable it.

Maxime

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

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Chris Morgan]

On Fri, Jun 30, 2023 at 10:16:35AM +0200, Maxime Ripard wrote:
> On Thu, Jun 29, 2023 at 08:34:10PM +0100, Andre Przywara wrote:
> > > > > +&usbphy {
> > > > > +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> > 
> > Where is this pin connected to, in the USB-C connector? One of the CC
> > pins?
> > 
> > > > > +	status = "okay";  
> > > > 
> > > > So in the commit message you say "USB-C for power", but this here
> > > > describes a full featured USB port. So does that work? Can you use it as a
> > > > gadget, but also as a host?  
> > > 
> > > Yes, it's an OTG port with the ID pin pulled to ground.
> > 
> > Do you mean both CC pins? IIRC this means it's hardwired as a
> > peripheral (UFP).
> > 
> > If I ignore the ID pin above, this looks like on the OrangePi Zero2 or
> > the MangoPi MQ-R. In those cases we put peripheral in the DT, as this
> > is what this connection seems to indicate. That *can* be used a host as
> > well, with the "right" cable, but it's not really a well supported
> > configuration, so we leave this up to people to change this locally,
> > should they really desire so.
> 
> The ID pin above is exactly what makes "the right cable" works:
> depending on the state of the ID pin the controller will act either as a
> peripheral or a host. Dual-mode works just fine, so if the hardware
> supports it there's no reason not to enable it.

Right, I'll have it as dr_mode = "otg".

Since I have neither schematics nor a proper devicetree I'll have to
expend some additional effort on this port, just as soon as I get the
panel working. :-)

> 
> Maxime

Re: [PATCH 3/3] ARM: dts: sunxi: add support for Anbernic RG-Nano

[Andre Przywara]

On Fri, 30 Jun 2023 10:16:35 +0200
Maxime Ripard <mripard@kernel.org> wrote:

Hi,

> On Thu, Jun 29, 2023 at 08:34:10PM +0100, Andre Przywara wrote:
> > > > > +&usbphy {
> > > > > +	usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;  
> > 
> > Where is this pin connected to, in the USB-C connector? One of the CC
> > pins?
> >   
> > > > > +	status = "okay";    
> > > > 
> > > > So in the commit message you say "USB-C for power", but this here
> > > > describes a full featured USB port. So does that work? Can you use it as a
> > > > gadget, but also as a host?    
> > > 
> > > Yes, it's an OTG port with the ID pin pulled to ground.  
> > 
> > Do you mean both CC pins? IIRC this means it's hardwired as a
> > peripheral (UFP).
> > 
> > If I ignore the ID pin above, this looks like on the OrangePi Zero2 or
> > the MangoPi MQ-R. In those cases we put peripheral in the DT, as this
> > is what this connection seems to indicate. That *can* be used a host as
> > well, with the "right" cable, but it's not really a well supported
> > configuration, so we leave this up to people to change this locally,
> > should they really desire so.  
> 
> The ID pin above is exactly what makes "the right cable" works:
> depending on the state of the ID pin the controller will act either as a
> peripheral or a host. Dual-mode works just fine, so if the hardware
> supports it there's no reason not to enable it.

Mmmh, I think that's correct for an USB micro-B socket, but this is a
USB type C one. I don't think USB type C role switching can be easily
implemented with just a single GPIO, probably not even with two purely
digital GPIOs, as you would need some more clever voltage detection
circuitry.
For a simple connection via a USB-2.0 A<->C cable this probably doesn't
matter (as nothing happens to the CC pins?), and a USB-C thumb drive
probably would work as well, but I doubt those boards can properly
detect that automatically.

Chris, can you check how many pins from the type C connector are
actually used on the board? Can you follow the traces? Does it just
pull CC1 and CC2 to GND, via a resistor? Or are those pins somehow
connected to the SoC, or even a separate USB-C controller chip? Maybe
also worth checking if the stock OS can detect hosts or devices attached
automatically.

I am not really familiar with the USB type C situation in those
simplified USB-2.0-only setups, so if anyone can shed some light on
this, I'd be grateful.

Cheers,
Andre