arm64: dts: qcom: add support for Xiaomi SDM636/SDM660 devices

Add device tree bindings for:
- Xiaomi Redmi Note 6 Pro (tulip) - SDM636
- Xiaomi Redmi Note 5 Pro (whyred) - SDM636
- Xiaomi Mi A2 (jasmine) - SDM660
- Xiaomi Mi 8 Lite (platina) - SDM660

These are Android-based smartphones that can boot mainline Linux with simple-framebuffer and USB support.

Signed-off-by Gianluca Boiano <[email protected]>

---
 Documentation/devicetree/bindings/arm/qcom.yaml | 4 ++++
 1 file changed, 4 insertions(+)

Create a shared device tree include file for Xiaomi smartphones and tablets based on Qualcomm SDM636/SDM660 SoCs. This reduces code duplication when adding new Xiaomi devices and ensures consistent configuration across the family.

The common dtsi includes:
- PM660/PM660L PMIC configuration with volume/power buttons
- Serial console (blsp1_uart2, blsp2_uart1)
- Hall effect sensor (disabled by default)
- USB (qusb2phy0, usb3) in peripheral mode
- SD card (sdhc_2) pinctrl and supplies
- eMMC (sdhc_1) with HS400 support
- Backlight (pm660l_wled)
- Framebuffer memory reservation
- WiFi (wcn3990)
- Bluetooth (wcn3990)

Also refactor sdm660-xiaomi-lavender.dts to use the new common include, removing duplicated code.

Signed-off-by Gianluca Boiano <[email protected]>

---
 .../boot/dts/qcom/sdm660-xiaomi-common.dtsi   | 214 ++++++++++++++++++
 .../boot/dts/qcom/sdm660-xiaomi-lavender.dts  | 144 +-----------

 2 files changed, 219 insertions(+), 139 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm660-xiaomi-common.dtsi

arch/arm64/boot/dts/qcom/sdm660-xiaomi-common.dtsi new file +0 -0

new file mode 100644
index 000000000000..37ce675089fb

Copyright year "2022" is odd for refactored code
Missing copyright attribution from Dang

Fix regulator configurations to ensure stable operation:
- vreg_l2b_2p95: Increase max voltage from 2696mV to 3100mV to support proper SD card voltage signaling

- vreg_l3b_3p3: Add regulator-always-on to keep the regulator enabled during boot

- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

Why regulator-always-on for l3b?

Why isn't sdhc_2 enabled globally in common?

Quoted 1 line · Konrad Dybcio

Why regulator-always-on for l3b?

This regulator powers the touchscreen. Without always-on, display initialization fails during boot. This matches downstream behavior. I can add a comment explaining this if preferred.

Quoted 1 line

Why isn't sdhc_2 enabled globally in common?

jasmine and platina don't have SD card slots, so enabling sdhc_2 globally would be incorrect. Only tulip, whyred, and lavender have SD card support.

Quoted 6 lines · Gianluca Boiano

Quoted 1 line · Konrad Dybcio

Why regulator-always-on for l3b?

This regulator powers the touchscreen. Without always-on, display initialization fails during boot. This matches downstream behavior. I can add a comment explaining this if preferred.

Is there a chance it simply needs to be power sequenced in a specific order vs the display itself? (seed drm_panel_add_follower())

Quoted 11 lines · Konrad Dybcio

Quoted 6 lines · Gianluca Boiano

Quoted 1 line · Konrad Dybcio

Why regulator-always-on for l3b?

This regulator powers the touchscreen. Without always-on, display initialization fails during boot. This matches downstream behavior. I can add a comment explaining this if preferred.

Is there a chance it simply needs to be power sequenced in a specific order vs the display itself? (seed drm_panel_add_follower())

According to my schematics for e.g lavender, vreg_l3b_3p3 does not power anything directly controlled by HLOS (Linux), it seems to be connected to p-sensor only, and goes to bottom board.

The change is done by vendor (Xiaomi) and as far as I remember is there for every xiaomi-sdm660 device [1].

Quoted 3 lines · Gianluca Boiano

Fix regulator configurations to ensure stable operation:
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

The driver needs to be fixed instead, as it should perform a regulator_set_load()

Quoted 7 lines · Konrad Dybcio

Quoted 3 lines · Gianluca Boiano

Fix regulator configurations to ensure stable operation:
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

The driver needs to be fixed instead, as it should perform a regulator_set_load()

Also change done by me in [1] with more detailed explanation:

Since the commit f05ab10 ("arm64: dts: qcom: sdm660-lavender:
Add missing USB phy supply") previously untouched by Linux regulator l10a is now used, but it exposed a bug from initial porting: when booting with USB cable inserted, or booting without cable and inserting it later, board reboots.

Quoted 10 lines · Alexey Minnekhanov

Quoted 7 lines · Konrad Dybcio

Quoted 3 lines · Gianluca Boiano

Fix regulator configurations to ensure stable operation:
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

The driver needs to be fixed instead, as it should perform a regulator_set_load()

Quoted 7 lines

Also change done by me in [1] with more detailed explanation:

Since the commit f05ab10 ("arm64: dts: qcom: sdm660-lavender:
Add missing USB phy supply") previously untouched by Linux regulator l10a is now used, but it exposed a bug from initial porting: when booting with USB cable inserted, or booting without cable and inserting it later, board reboots.

FYI this shouldn't be required with the upstream driver, I don't think the core calls .set_load(0) and RPM isn't notified of a current requirement change unless that happens (qcom_smd-regulator.c)

In the power grid, I see (current values representing the peak):

-- USB2
VDDA (3.1 V - vdda-phy-dpdm-supply) - 60mA
VDDA (1.8 V - vdda-pll-supply) - 30mA

VDD (?) - 11.4 mA
VDDA_DVDD (?) - 35 mA

-- USB3
VDDA (1.8 V) - 14 mA
VDDA_CORE - 68.6 mA

+Dmitry poked at 660 in the past

Konrad

Quoted 32 lines · Konrad Dybcio

Quoted 10 lines · Alexey Minnekhanov

Quoted 7 lines · Konrad Dybcio

Quoted 3 lines · Gianluca Boiano

Fix regulator configurations to ensure stable operation:
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

The driver needs to be fixed instead, as it should perform a regulator_set_load()

Quoted 7 lines

Also change done by me in [1] with more detailed explanation:

Since the commit f05ab10 ("arm64: dts: qcom: sdm660-lavender:
Add missing USB phy supply") previously untouched by Linux regulator l10a is now used, but it exposed a bug from initial porting: when booting with USB cable inserted, or booting without cable and inserting it later, board reboots.

FYI this shouldn't be required with the upstream driver, I don't think the core calls .set_load(0) and RPM isn't notified of a current requirement change unless that happens (qcom_smd-regulator.c)

In the power grid, I see (current values representing the peak):

-- USB2
VDDA (3.1 V - vdda-phy-dpdm-supply) - 60mA
VDDA (1.8 V - vdda-pll-supply) - 30mA

VDD (?) - 11.4 mA
VDDA_DVDD (?) - 35 mA

Quoted 8 lines

-- USB3
VDDA (1.8 V) - 14 mA
VDDA_CORE - 68.6 mA

+Dmitry poked at 660 in the past

Konrad

This is not needed e.g on sdm630-sony-nile-pioneer, it's booting fine without system-load with USB cable inserted. Maybe IFC board doesn't require this too. Seems to be xiaomi specific thing again?

Alternative is to not touch L10A regulator (comment out vdda-pll-supply from qusb2phy0 node and face the "phy@c012000: 'vdda-pll-supply' is a required property" dtbs-check error again. Which we don't want to do of course. And schematics say that vreg_l10a_1p8 is connected to at least:
VDD_USB1_HS_1P8, VDD_USB2_HS_1P8, QFPROM_PRG, VDDA_APC1_CS_1P8, VDD_PLL2_1, VDD_PLL2_2.

Quoted 46 lines · Alexey Minnekhanov

Quoted 32 lines · Konrad Dybcio

Quoted 10 lines · Alexey Minnekhanov

Quoted 7 lines · Konrad Dybcio

Quoted 3 lines · Gianluca Boiano

Fix regulator configurations to ensure stable operation:
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

The driver needs to be fixed instead, as it should perform a regulator_set_load()

Quoted 7 lines

Also change done by me in [1] with more detailed explanation:

Since the commit f05ab10 ("arm64: dts: qcom: sdm660-lavender:
Add missing USB phy supply") previously untouched by Linux regulator l10a is now used, but it exposed a bug from initial porting: when booting with USB cable inserted, or booting without cable and inserting it later, board reboots.

FYI this shouldn't be required with the upstream driver, I don't think the core calls .set_load(0) and RPM isn't notified of a current requirement change unless that happens (qcom_smd-regulator.c)

In the power grid, I see (current values representing the peak):

-- USB2
VDDA (3.1 V - vdda-phy-dpdm-supply) - 60mA
VDDA (1.8 V - vdda-pll-supply) - 30mA

VDD (?) - 11.4 mA
VDDA_DVDD (?) - 35 mA

Quoted 8 lines

-- USB3
VDDA (1.8 V) - 14 mA
VDDA_CORE - 68.6 mA

+Dmitry poked at 660 in the past

Konrad

This is not needed e.g on sdm630-sony-nile-pioneer, it's booting fine without system-load with USB cable inserted. Maybe IFC board doesn't require this too. Seems to be xiaomi specific thing again?

Quoted 6 lines

Alternative is to not touch L10A regulator (comment out vdda-pll-supply from qusb2phy0 node and face the "phy@c012000: 'vdda-pll-supply' is a required property" dtbs-check error again. Which we don't want to do of course. And schematics say that vreg_l10a_1p8 is connected to at least:
VDD_USB1_HS_1P8, VDD_USB2_HS_1P8, QFPROM_PRG, VDDA_APC1_CS_1P8, VDD_PLL2_1, VDD_PLL2_2.

It might be that there is an issue because of it being used for APC1 too. I don't observe any issues on my IFC6560 board (where it is also connected to APC1).

I'd suggest adding a dummy fixed regulator node as L10A and documenting that it is not to be touched by Linux on this device). We do this for some other "system" regulators on other devices.

Quoted 54 lines · Dmitry Baryshkov

Quoted 52 lines · Alexey Minnekhanov

Quoted 32 lines · Konrad Dybcio

Quoted 10 lines · Alexey Minnekhanov

Quoted 7 lines · Konrad Dybcio

Quoted 3 lines · Gianluca Boiano

Fix regulator configurations to ensure stable operation:
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

The driver needs to be fixed instead, as it should perform a regulator_set_load()

Quoted 7 lines

Also change done by me in [1] with more detailed explanation:

Since the commit f05ab10 ("arm64: dts: qcom: sdm660-lavender:
Add missing USB phy supply") previously untouched by Linux regulator l10a is now used, but it exposed a bug from initial porting: when booting with USB cable inserted, or booting without cable and inserting it later, board reboots.

FYI this shouldn't be required with the upstream driver, I don't think the core calls .set_load(0) and RPM isn't notified of a current requirement change unless that happens (qcom_smd-regulator.c)

In the power grid, I see (current values representing the peak):

-- USB2
VDDA (3.1 V - vdda-phy-dpdm-supply) - 60mA
VDDA (1.8 V - vdda-pll-supply) - 30mA

VDD (?) - 11.4 mA
VDDA_DVDD (?) - 35 mA

Quoted 8 lines

-- USB3
VDDA (1.8 V) - 14 mA
VDDA_CORE - 68.6 mA

+Dmitry poked at 660 in the past

Konrad

This is not needed e.g on sdm630-sony-nile-pioneer, it's booting fine without system-load with USB cable inserted. Maybe IFC board doesn't require this too. Seems to be xiaomi specific thing again?

Alternative is to not touch L10A regulator (comment out vdda-pll-supply from qusb2phy0 node and face the "phy@c012000: 'vdda-pll-supply' is a required property" dtbs-check error again. Which we don't want to do of course. And schematics say that vreg_l10a_1p8 is connected to at least:
VDD_USB1_HS_1P8, VDD_USB2_HS_1P8, QFPROM_PRG, VDDA_APC1_CS_1P8, VDD_PLL2_1, VDD_PLL2_2.

Quoted 3 lines

It might be that there is an issue because of it being used for APC1 too. I don't observe any issues on my IFC6560 board (where it is also connected to APC1).

Wait, what? The same line going to external ports and the CPU supply!?

Quoted 4 lines

I'd suggest adding a dummy fixed regulator node as L10A and documenting that it is not to be touched by Linux on this device). We do this for some other "system" regulators on other devices.

I think that system-load may be fitting, but it needs a comment

Fix regulator configurations to ensure stable operation:
- vreg_l2b_2p95: Increase max voltage from 2696mV to 3100mV to support proper SD card voltage signaling
- vreg_l3b_3p3: Add regulator-always-on to keep the regulator enabled during boot
- vreg_l10a_1p8: Add regulator-system-load of 14000uA for proper USB PHY PLL operation

Also enable the SD card controller (sdhc_2) which was left disabled.

Add initial device tree support for the Xiaomi Redmi Note 6 Pro (codename: tulip), a smartphone based on Qualcomm SDM636 SoC with 4GB RAM and a 6.26" 1080x2280 display.

This enables:
- Booting to a framebuffer console
- USB support
- Hall effect sensor
- Battery monitoring
- Charging (pm660_charger)
- Status LED (pm660l_lpg)

Signed-off-by Gianluca Boiano <[email protected]>

---

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts new file +9 -0

+			console-size = <0x20000>;
+			record-size = <0x20000>;
+			ftrace-size = <0x0>;
+			pmsg-size = <0x20000>;
+		};
+	};
+};
+
+&framebuffer0 {

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts new file +8 -0

+
+&rpm_requests {
+	regulators-0 {
+		compatible = "qcom,rpm-pm660l-regulators";
+
+		vdd_s1-supply = <&vph_pwr>;
+		vdd_s2-supply = <&vph_pwr>;
+		vdd_s3_s4-supply = <&vph_pwr>;

Consolidate ramoops, hall sensor, pm660_charger, pm660l_wled, regulators

Quoted 14 lines · Gianluca Boiano

Add initial device tree support for the Xiaomi Redmi Note 6 Pro (codename: tulip), a smartphone based on Qualcomm SDM636 SoC with 4GB RAM and a 6.26" 1080x2280 display.

This enables:
- Booting to a framebuffer console
- USB support
- Hall effect sensor
- Battery monitoring
- Charging (pm660_charger)
- Status LED (pm660l_lpg)

Signed-off-by Gianluca Boiano <[email protected]>

---

Review

Quoted 3 lines

+&pm660l_wled {

(quoted diff) +2 -0

+	status = "okay";
+};

This seems to as well

Quoted 12 lines

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts new file +12 -0

+
+&rpm_requests {
+	regulators-0 {
+		compatible = "qcom,rpm-pm660l-regulators";
+
+		vdd_s1-supply = <&vph_pwr>;
+		vdd_s2-supply = <&vph_pwr>;
+		vdd_s3_s4-supply = <&vph_pwr>;
+		vdd_s5-supply = <&vph_pwr>;
+		vdd_s6-supply = <&vph_pwr>;
+
+		vdd_l1_l9_l10-supply = <&vreg_s2b_1p05>;

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts line 89

Quoted 6 lines

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts new file +6 -0

+		vdd_l2-supply = <&vreg_bob>;
+		vdd_l3_l5_l7_l8-supply = <&vreg_bob>;
+		vdd_l4_l6-supply = <&vreg_bob>;
+		vdd_bob-supply = <&vph_pwr>;
+
+		vreg_s1b_1p125: s1 {

Please diff the regulator settings, they're likely mostly common

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts line 333

Quoted 4 lines

arch/arm64/boot/dts/qcom/sdm636-xiaomi-tulip.dts new file +4 -0

+
+&tlmm {
+	gpio-reserved-ranges = <8 4>; /* Fingerprint SPI */
+};

This setting is common to all of them too

Quoted 15 lines · Konrad Dybcio

Quoted 14 lines · Gianluca Boiano

Add initial device tree support for the Xiaomi Redmi Note 6 Pro (codename: tulip), a smartphone based on Qualcomm SDM636 SoC with 4GB RAM and a 6.26" 1080x2280 display.

This enables:
- Booting to a framebuffer console
- USB support
- Hall effect sensor
- Battery monitoring
- Charging (pm660_charger)
- Status LED (pm660l_lpg)

Signed-off-by Gianluca Boiano <[email protected]>

---

Once again clover is exception here, all 3 variants of clover are using

     gpio-reserved-ranges = <0 4>;

I think it might be better to leave this setting to board files?