Re: [PATCH v2 2/2] arm64: dts: qcom: Add Xiaomi Poco M3

[Barnabás Czémán]

On 2026-11-01 17:49, Amir Hanip wrote:
> On Fri, 30 Oct 2026 13:30:28 +0100, Barnabas Czeman wrote:
> > Poco M3 (citrus) is same HW like Redmi 9T (lime) and Remi 9T NFC
> > (lemon) basically is a lime with NFC.
> > So i think it would be better make a common base from lemon's
> > devicetree instead of making the same devicetree again for the
> > different variants where only the compatible and the model property
> > will be the difference.
> > Check sm6115-xiaomi-gingkgo-common for example, it was the same case
> > for Redmi Note 8 (ginkgo) and 8T (willow).
>
> Hi Barnabas, Adam,
>
> Thanks for the review, that makes sense. I am preparing a v3 that
> moves the shared parts of lemon into sm6115-xiaomi-lime-common.dtsi
> and has both lemon and citrus include it. I used the name lime-common
> following your naming. Happy to rename it.
>
> Plan for v3:
> 1. dt-bindings (unchanged)
> 2. lemon: move the shared nodes into the common dtsi, no functional
>    change intended
> 3. citrus on top of the common dtsi
>
> I can only test citrus. I do not own a Redmi 9T, so lemon is untested
> on hardware. Instead, I compared the lemon DTS before and after the
> split, normalized with dtc (dtc -I dts -O dts -s). The only
> difference is the numbering of two auto-generated phandles. I will
> describe the check in the cover letter. Adam,
> would you be able to test lemon once v3 is posted, or look at the
> split beforehand?
>
> The IPA carve-outs (pil_ipa_fw_mem and pil_ipa_gsi_mem) are identical
> on both, so they now live in the common dtsi.
>
> I kept the following per variant because I cannot tell whether they
> are real hardware differences or just differences between the stock
> firmware images:
>
> - ADSP carve-out: 0x53800000/0x2200000 on citrus, 0x53400000/0x2600000
>   on lemon. Both regions end at 0x55a00000, so only the start and
>   size differ. I can only confirm that the citrus value works on my
>   device.
If there are no overlaps the bigger range could work for both of them.
> - GPU carve-out: 0x55a15000 on citrus (right after pil_ipa_gsi_mem,
>   like the SoC dtsi defaults), 0xfa400000 on lemon. The citrus value
>   works: the GPU runs with a full DT that includes the display
>   pipeline, which is not part of this series. I cannot verify
>   lemon's value. Adam, is 0xfa400000 intentional?
> - PM6125 regulators: seven have different voltage ranges (s7, l5,
>   l7, l11, l17, l18, l22). l24 has the same range, but only citrus
>   sets regulator-allow-set-load. lemon also marks l5, l7 and l22 as
>   always-on, citrus does not.
You should check where the regulators are used, at downstream many times
driver bindings are overriding the ranges. You should check properties
like these:
		-min-voltage = <1800000 0>;
		-max-voltage = <1800000 0>;
		-load-current = <180000 0>;
For the always-on it could be a bad habit from downstream
where they are not leave to the driver to set the regulator on/off,
keeping always-on properties not always necessary with the upstream 
drivers.

> - citrus deletes cdsp_sec_mem and the orientation-switch property of
>   usb_qmpphy, lemon does not.
I think it could be just left over from the reference design since
these devices are not supporting DP.
> Barnabas, Adam: do you know whether these differences are real, or
> whether they only come from the firmware of each model?
>
> Thanks,
> Amir