arm64: dts: qcom: add sdm660-xiaomi-common.dtsi for Xiaomi SDM660-family devices

[M0Rf30]

This patch creates a common devicetree include file for Xiaomi devices based on SDM630/SDM636/SDM660 SoCs, reducing code duplication across 6 device trees.

Affected devices:

• sdm636-xiaomi-tulip (Redmi Note 6 Pro)
• sdm636-xiaomi-whyred (Redmi Note 5 Pro)
• sdm660-xiaomi-jasmine (Mi A2)
• sdm660-xiaomi-platina (Mi 8 Lite)
• sdm660-xiaomi-lavender (Redmi Note 7)
• sdm660-xiaomi-clover (Mi Pad 4 / Mi Pad 4 Plus)

The common file includes shared configuration for:

• PM660/PM660L regulators
• GPIO keys, hall sensor, PON keys
• USB, WiFi, Bluetooth (wcn3990)
• eMMC/SD card
• Audio DAI configuration
• GPU, display (MDSS), Venus
• Modem

Device-specific elements (battery, panel, touchscreen, reserved-memory, regulator voltages) remain in individual device files.

[minlexx]

Just to leave a note about different Wi-Fi powering (maybe it's better to create a separate issue instead), there's this -> https://lore.kernel.org/linux-arm-msm/20251231-wcn3990-pwrctl-v1-0-1ff4d6028ad5@oss.qualcomm.com/T/
maybe we're all powering Wi-Fi incorrectly 🙈 and will need to rework it everywhere similarly to sda660-inforce change in that patch series.

[setotau]

New revision of wcm399x patches https://lore.kernel.org/linux-arm-msm/20260106-wcn3990-pwrctl-v2-0-0386204328be@oss.qualcomm.com/T/

[okias]

+		vddch0-supply = <&vreg_l19a_3p3>;
+		vddch1-supply = <&vreg_l8b_3p3>;

this channel setup from ifc6560 is more believable. I would recommend checking if this isn't default on whole sdm660 family.

	vdd-3.3-ch0-supply = <&vreg_l19a_3p3>;
	vdd-3.3-ch1-supply = <&vreg_l19a_3p3>;

looks more like copy-paste, but pointless setup

[minlexx]

in lavender schemas neither l8b nor ch1 are not even mentioned

[setotau]

Maybe it can be removed in the lavender's dts

[M0Rf30]

+		vddch0-supply = <&vreg_l19a_3p3>;
+		vddch1-supply = <&vreg_l8b_3p3>;

this channel setup from ifc6560 is more believable. I would recommend checking if this isn't default on whole sdm660 family.

	vdd-3.3-ch0-supply = <&vreg_l19a_3p3>;
	vdd-3.3-ch1-supply = <&vreg_l19a_3p3>;

looks more like copy-paste, but pointless setup

I removed vdd-3.3-ch1-supply property, was introduced by me only to silence some dmesg messages, has no effects

[okias]

I would ask on mailing list, maybe ch1 was never included in wcm3980 and thus the warning is bogus? (just guessing here, someone from QCOM may know)

[setotau]

I removed vdd-3.3-ch1-supply property, was introduced by me only to silence some dmesg messages, has no effects

Do you suggest to add this property to devices' dts'es?

xiaomi-clover has the ch1 supply on the scheme

[M0Rf30]

I removed vdd-3.3-ch1-supply property, was introduced by me only to silence some dmesg messages, has no effects

Do you suggest to add this property to devices' dts'es? xiaomi-clover has the ch1 supply on the scheme

added to clover

[setotau]

Also clover uses zap-shader from modem partition, so it is better to change the shader extension from mbn to mdt

[M0Rf30]

Also clover uses zap-shader from modem partition, so it is better to change the shader extension from mbn to mdt

I unified the naming and firmware like for other socs.
Take a look here https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7731

[minlexx]

Also clover uses zap-shader from modem partition, so it is better to change the shader extension from mbn to mdt

.mdt will not be accepted upstream unfortunately. So either we upstream dts with .mbn and package .mbn in fw package, or we teach msm-firmware-loader to read firmware-name property form /sys/class/remoteproc/remoteprocN directories and create symlinks from .mbn -> .mdt while preserving full correct path that DT expects (something like qcom/sdm660/Xiaomi/clover/modem.mbn -> /run/msm-firmware-loader/mnt/modem/image/modem.mdt). Kernel can auto detect actual firmware file type regradless of whether it's mdt or mbn.

[setotau]

I unified the naming and firmware like for other socs.
Take a look here https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7731

Maybe it is better to squash the shader to mbn file using pil-squasher, isn't it?

[minlexx]

I was thinking about this for some time and I think this MR can't go in right now, because it will create unmaintainable difference to upstream and will cause big problems when sending patches, because -common is not there and patches will have to be recreated from scratch. Maintaining 2 separate source trees is not fun 😢 But this is still very good example of how it should be done. Just not here..

What needs to be done first, I think, is to create sdm660-xiaomi-common.dtsi upstream first. For it to happen at least one more xiaomi device tree needs to be sent there, together with rework of lavender dts. Doesn't matter which one - it can be clover, jasmine (as most similar to lavender) or tulip. Patchset should contain something like 2 commits:

1. split existing lavender dts to 660-xiaomi-common and make lavender dts include the common one
2. add new sdm660-xiaomi device using the common one again.

If you send such rework upstream now, chances are it can be upstream by linux 6.20 release. And then, when rebasing our fork on top of 6.20 release we can have it. It will be painful manual rebase of every xiaomi-sdm660 dts, but it's doable and needs to be done once. Then it will all be easier.

Should be noted here that some drivers are not upstream (like panel driver and e.g. fuelgauge), therefore dts cannot be sent fully as is. So you'll have to remove for example fulegauge node and display stack (mdss/adreno/panel) and keep it framebuffer-only for now. Maybe better to start witl sending fg and panel drivers first?

For now if you don't want to send patches upstream, and just have some fixups to tulip audio, place them into existing tulip's dts 😔

[okias]

Maybe, just maybe, upstream could accept even the split into the common, when developers will reasonably be convinced that other devices sharing the common would follow.

I think it would be worth try it (any suggested variant).

[okias]

btw. regarding the firmware paths, it should look like (e.g. the convention Linux kernel uses)

$arch/$Vendor/$codename

thus something like

sdm630/Nokia/pl2

[minlexx]

From this MR we can have the "align GPU firmware paths" commit as separate MR maybe?