[v2,2/2] arm64: dts: allwinner: Add SPC Glee 10.1 A64

From: Juan Carlos Gutiérrez Lavado <jcarlosgl96@proton.me>

Add support for the SPC Glee 10.1 tablet based on the Allwinner A64.
Describe the 2 GiB DRAM configuration, AXP803 PMIC, essential supplies,
microSD, UART, battery monitoring and USB peripheral port. Leave eMMC
and unverified peripherals disabled.

Include CPU operating points for frequency scaling and thermal cooling.
Enable the PMIC USB supply and connect it to the PHY for VBUS detection.
Keep the ALDO2 VCC-PL and ALDO3 VCC-PLL/AVCC supplies enabled, matching
the stock firmware and the measured 1.8 V and 3.0 V baseline settings.

Tested with kexec into Linux 7.3.0-rc1 without regulator_ignore_unused:
CPU frequency transitions, CPU cooling frequency cap, and USB supply
unplug/replug detection with SSH reconnection. Cold-boot validation of
this revision remains pending.

Signed-off-by: Juan Carlos Gutiérrez Lavado <jcarlosgl96@proton.me>
---
 arch/arm64/boot/dts/allwinner/Makefile             |   1 +
 .../boot/dts/allwinner/sun50i-a64-spc-glee.dts     | 143 +++++++++++++++++++++
 2 files changed, 144 insertions(+)
  

Hi,

thanks for taking the time to send this upstream!
Have you looked at the Pinetab .dts? That could serve as a guideline for 
the other peripherals. Typically many devices follow some Allwinner 
reference design, so are close to each other.

On 9/11/26 15:48, Juan Carlos Gutiérrez Lavado via B4 Relay wrote:
> From: Juan Carlos Gutiérrez Lavado <jcarlosgl96@proton.me>
> 
> Add support for the SPC Glee 10.1 tablet based on the Allwinner A64.
> Describe the 2 GiB DRAM configuration, AXP803 PMIC, essential supplies,
> microSD, UART, battery monitoring and USB peripheral port. Leave eMMC

why is that? eMMC should be very easy to enable: you just need to figure 
out if it's 1.8V or 3.3V, the speed (mode) in a BSP booted system should 
give you some clue.
> and unverified peripherals disabled.
> 
> Include CPU operating points for frequency scaling and thermal cooling.
> Enable the PMIC USB supply and connect it to the PHY for VBUS detection.
> Keep the ALDO2 VCC-PL and ALDO3 VCC-PLL/AVCC supplies enabled, matching
> the stock firmware and the measured 1.8 V and 3.0 V baseline settings.
> 
> Tested with kexec into Linux 7.3.0-rc1 without regulator_ignore_unused:
> CPU frequency transitions, CPU cooling frequency cap, and USB supply
> unplug/replug detection with SSH reconnection. Cold-boot validation of
> this revision remains pending.
> 
> Signed-off-by: Juan Carlos Gutiérrez Lavado <jcarlosgl96@proton.me>
> ---
>   arch/arm64/boot/dts/allwinner/Makefile             |   1 +
>   .../boot/dts/allwinner/sun50i-a64-spc-glee.dts     | 143 +++++++++++++++++++++
>   2 files changed, 144 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index aa21f58a4..cc6687b39 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-early-adopter.dtb
>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-spc-glee.dtb
>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h64-remix-mini-pc.dtb
>   dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-spc-glee.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-spc-glee.dts
> new file mode 100644
> index 000000000..0f8f37b14
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-spc-glee.dts
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2026 SPC Glee A64 Linux contributors
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +#include "sun50i-a64-cpu-opp.dtsi"
> +
> +/ {
> +	model = "SPC Glee 10.1 A64";
> +	compatible = "onspc,glee-10-1-a64", "allwinner,sun50i-a64";
> +	chassis-type = "tablet";
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory@40000000 {
> +		device_type = "memory";
> +		reg = <0x40000000 0x80000000>;
> +	};

Please no memory nodes, this is up to the bootloader (U-Boot) to detect 
and insert into the DTB.
> +};
> +
> +&cpu0 {
> +	cpu-supply = <&reg_dcdc2>;
> +};
> +
> +&cpu1 {
> +	cpu-supply = <&reg_dcdc2>;
> +};
> +
> +&cpu2 {
> +	cpu-supply = <&reg_dcdc2>;
> +};
> +
> +&cpu3 {
> +	cpu-supply = <&reg_dcdc2>;
> +};
> +
> +&mmc0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc0_pins>;
> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_dcdc1>;
> +	broken-cd;
> +	bus-width = <4>;
> +	max-frequency = <25000000>;

Why is this? This would limit the SD card to just 12.5 MB/s, half of 
what it can do at High-Speed mode (at 3.3V).
If it can do 50 MHz (~25MB/s at 4 bits), you wouldn't need to enter a 
max frequency at all, as the 3.3V I/O supply would limit the frequency 
to that anyway.

> +	status = "okay";
> +};
> +
> +&r_rsb {
> +	status = "okay";
> +
> +	axp803: pmic@3a3 {
> +		compatible = "x-powers,axp803";
> +		reg = <0x3a3>;
> +		interrupt-parent = <&r_intc>;
> +		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_LOW>;
> +	};
> +};
> +
> +#include "axp803.dtsi"
> +
> +&axp_adc {
> +	status = "okay";
> +};
> +
> +&battery_power_supply {
> +	status = "okay";
> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "vcc-pl";
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3000000>;
> +	regulator-max-microvolt = <3000000>;
> +	regulator-name = "vcc-pll-avcc";
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1000000>;
> +	regulator-max-microvolt = <1300000>;
> +	regulator-name = "vdd-cpux";
> +};
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1500000>;
> +	regulator-max-microvolt = <1500000>;
> +	regulator-name = "vcc-dram";
> +};
> +
> +&reg_dcdc6 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_fldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-cpus";
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pb_pins>;
> +	status = "okay";
> +};
> +
> +&usb_otg {
> +	dr_mode = "peripheral";

Is that really peripheral only? I guess it can do OTG, right? You hint 
at that above in the commit message. You would just need to specify 
usb0_id_det-gpios in the usbphy node below. If you are lucky, the BSP's 
/sys/kernel/debug/gpio would give you a hint which GPIO it is.

Cheers,
Andre

> +	status = "okay";
> +};
> +
> +&usb_power_supply {
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	usb0_vbus_power-supply = <&usb_power_supply>;
> +	status = "okay";
> +};
>
  

Hi Andre,

Thanks for the detailed review.

I have looked at the PineTab DTS and the other A64 reference boards. They are useful guides for the remaining peripherals, and I will use them when preparing the next revision.

You are right about the memory node. I will remove it and leave memory discovery to U-Boot.

The eMMC was left disabled because I had not yet verified its supply voltage and operating mode from a BSP boot. I will inspect the BSP MMC configuration and runtime state, then enable it once the voltage and timing are confirmed.

The 25 MHz SD limit was conservative while high-speed operation was still unverified. I will test the 3.3 V high-speed configuration and remove the limit if the board is stable at 50 MHz.

USB has only been validated in peripheral mode so far. I will check the BSP GPIO/debug information for an ID-detect pin. If the hardware is wired for OTG, I will add the corresponding usb0_id_det-gpios configuration; otherwise I will keep peripheral mode and document the limitation.

I will incorporate these changes in the next revision.

Best regards,
Juan Carlos