Re: [PATCH 14/20] arm64: dts: qcom: kaanapali-mtp: Enable more features

Kamal Wadhwa
2025-10-13T16:21:45Z

Hi Eugen,

On Fri, Oct 10, 2025 at 05:02:54PM +0300, Eugen Hristev wrote:
>
>
> On 10/10/25 13:54, Jishnu Prakash wrote:
> > Hi Dmitry and Eugen,
> >
> > On 10/9/2025 9:58 PM, Dmitry Baryshkov wrote:
> >> On Thu, Oct 09, 2025 at 05:58:03PM +0300, Eugen Hristev wrote:
> >>>
> >>>
> >>> On 10/9/25 16:54, Jishnu Prakash wrote:
> >>>> Hi Eugen,
> >>>>
> >>>> On 9/25/2025 1:33 PM, Eugen Hristev wrote:
> >>>>>
> >>>>>
> >>>>> On 9/25/25 03:17, Jingyi Wang wrote:
> >>>>>> Enable more features on Kaanapali MTP boards including PMIC peripherals,
> >>>>>> bus, SDHCI, remoteprocs, USB, PCIE, WLAN and Bluetooth.
> >>>>>>
> >>>>>> Written with help from Jyothi Kumar Seerapu(added bus), Ronak Raheja
> >>>>>> (added USB), Manish Pandey(added SDHCI), Jishnu Prakash(added PMIC),
> >>>>>> Qiang Yu(added PCIE), Yijie Yang(Added WLAN) and Zijun Hu(Added Bluetooth).
> >>>>>>
> >>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> >>>>>> ---
> >>>>>> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 663 +++++++++++++++++++++++++++++
> >>>>>> 1 file changed, 663 insertions(+)
> >>>>>>
> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> >>>>>> index 9cf3158e2712..2949579481a9 100644
> >>>>>> --- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> >>>>>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> >>>>>> @@ -5,9 +5,23 @@
> >>>>>>
> >>>>
> >>>> ...
> >>>>
> >>>>>> +
> >>>>>> +&spmi_bus1 {
> >>>>>> + pmd8028: pmic@4 {
> >>>>>> + compatible = "qcom,pmd8028", "qcom,spmi-pmic";
> >>>>>> + reg = <0x4 SPMI_USID>;
> >>>>>> + #address-cells = <1>;
> >>>>>> + #size-cells = <0>;
> >>>>>> +
> >>>>>> + pmd8028_temp_alarm: temp-alarm@a00 {
> >>>>>> + compatible = "qcom,spmi-temp-alarm";
> >>>>>> + reg = <0xa00>;
> >>>>>> + interrupts = <0x4 0xa 0x0 IRQ_TYPE_EDGE_BOTH>;
> >>>>>> + #thermal-sensor-cells = <0>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + pmd8028_gpios: gpio@8800 {
> >>>>>> + compatible = "qcom,pmd8028-gpio", "qcom,spmi-gpio";
> >>>>>> + reg = <0x8800>;
> >>>>>> + gpio-controller;
> >>>>>> + gpio-ranges = <&pmd8028_gpios 0 0 4>;
> >>>>>> + #gpio-cells = <2>;
> >>>>>> + interrupt-controller;
> >>>>>> + #interrupt-cells = <2>;
> >>>>>> + };
> >>>>>> + };
> >>>>>> +
> >>>>>> + pmih0108: pmic@7 {
> >>>>>> + compatible = "qcom,pmih0108", "qcom,spmi-pmic";
> >>>>>> + reg = <0x7 SPMI_USID>;
> >>>>>> + #address-cells = <1>;
> >>>>>> + #size-cells = <0>;
> >>>>>> +
> >>>>>> + pmih0108_temp_alarm: temp-alarm@a00 {
> >>>>>> + compatible = "qcom,spmi-temp-alarm";
> >>>>>> + reg = <0xa00>;
> >>>>>> + interrupts = <0x7 0xa 0x0 IRQ_TYPE_EDGE_BOTH>;
> >>>>>> + #thermal-sensor-cells = <0>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + pmih0108_gpios: gpio@8800 {
> >>>>>> + compatible = "qcom,pmih0108-gpio", "qcom,spmi-gpio";
> >>>>>> + reg = <0x8800>;
> >>>>>> + gpio-controller;
> >>>>>> + gpio-ranges = <&pmih0108_gpios 0 0 18>;
> >>>>>> + #gpio-cells = <2>;
> >>>>>> + interrupt-controller;
> >>>>>> + #interrupt-cells = <2>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + pmih0108_eusb2_repeater: phy@fd00 {
> >>>>>> + compatible = "qcom,pm8550b-eusb2-repeater";
> >>>>>> + reg = <0xfd00>;
> >>>>>> + #phy-cells = <0>;
> >>>>>> + vdd18-supply = <&vreg_l15b_1p8>;
> >>>>>> + vdd3-supply = <&vreg_l5b_3p1>;
> >>>>>> + };
> >>>>>> + };
> >>>>>> +
> >>>>>> + pmr735d: pmic@a {
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> The PMR735D is available in pmr735d_a.dtsi
> >>>>>
> >>>>> Can we find a way to reuse that include file instead of duplicating it
> >>>>> here ?
> >>>>
> >>>> In pmr735d_a.dtsi, the peripherals are added under the parent phandle
> >>>> "spmi_bus", which was commonly used in older SoCs having only a single
> >>>> bus under the PMIC arbiter, but in Kaanapali, there are two buses
> >>>> present under the PMIC arbiter, with phandles "spmi_bus0" and "spmi_bus1",
> >>>> so we cannot include the file as it is.
> >>>>
> >>>
> >>> I know the problem. I disagree with using include files in one case, and
> >>> having the PMIC in the dts in the other case.
> >>>
> >>> So there has to be a unified way to handle this in all cases.
> >>
> >> Rework SPMI PMICs to follow the approach started by Johan for PM8008. I
> >> think this is the way to go.
> >>
> >
> > We got a recommendation from Krzysztof recently here for Glymur:
> > https://lore.kernel.org/all/b784387b-5744-422e-92f5-3d575a24d01c@kernel.org/
> >
> > For PMH0110, he suggested we could keep different DTSI files per SoC,
> > like pmh0110-kaanapali.dtsi and pmh0110-glymur.dtsi.
> >
> > We could follow a similar approach on Kaanapali, to
> > #include the following files in the .dts file:
> >
> > pmk8850.dtsi
> > pmh0101.dtsi
> > pmh0110-kaanapali.dtsi
> > pmh0104-kaanapali.dtsi
> > pmd8028-kaanapali.dtsi
> > pmih0108-kaanapali.dtsi
> > pmr735d-kaanapali.dtsi
> > pm8010-kaanapali.dtsi
> >
> > The first two files are new and common with Glymur,so they
> > do not have the SoC name suffix.
> >
> > Hope this is fine, please let us know if you see any issue.
>
> I would like it to be consistent, you would have to rename the old
> pmr735d.dtsi into pmr735d-whatever-soc-was-using-it.dtsi in another
> patch, and then create pmr735d-kaanpali.dtsi for kaanapali.
>
> Does this look good ?

Currently we were thinking to name PMIC dtsi based on below criteria:
- pmic.dtsi can be used `as-is` (common bus-id/spmi-id) for more than
one SoC -> use filename without SoC suffix.
- If there is a delta between two SoCs (old existing pmic file mismatch
busid/spmi-ids) for same PMIC -> have SoC-specific PMIC files.

IMO, This will be sligtly better to identify
- which pmic dtsi is older and have common placement on bus, sid and
other properties for multiple targets.
- Which pmic's have deviated away and landed late on the upstream

NOTE: We have good number of examples where pmics are re-used as-is
with same bus-id and spmi-id eg- pmk8550, pmk8350 etc. So we want to
suffix the target only if the target is not first one to use it and
deviated from the first version, where reuse is not possible.

On the other hand, to align to your request we may have to fix this
retrospectively for all pmics as lot of older pmic.dtsi also will fall
in same catagory, then just simply adding a SoC specific pmic version.

And also losing this (above described) understanding of the `history
and common design` of each pmic.dtsi file.

Does this justification works? Please let us know if you still see
any problems with this naming critria, or we can improve it still?

> >
> > Thanks,
> > Jishnu
> >

Regards,
Kamal