[PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform

[Rakesh Kota]

On Tue, Jun 30, 2026 at 03:50:16PM +0200, Konrad Dybcio wrote:
> On 6/30/26 2:42 PM, Rakesh Kota wrote:
> > On Sun, Jun 28, 2026 at 03:33:23PM +0300, Dmitry Baryshkov wrote:
> >> On Thu, Jun 25, 2026 at 09:11:19PM +0530, Kamal Wadhwa wrote:
> >>> On Wed, Jun 17, 2026 at 03:48:14PM +0300, Dmitry Baryshkov wrote:
> >>>> On Mon, 18 May 2026 at 14:49, Kamal Wadhwa
> >>>> <kamal.wadhwa at oss.qualcomm.com> wrote:
> >>>>>
> >>>>> On Sun, May 17, 2026 at 08:18:15PM +0300, Dmitry Baryshkov wrote:
> >>>>>> On Thu, May 14, 2026 at 04:09:18PM +0530, Kamal Wadhwa wrote:
> >>>>>>> On Wed, May 13, 2026 at 06:14:20PM +0300, Dmitry Baryshkov wrote:
> >>>>>>>> On 13/05/2026 17:29, Rakesh Kota wrote:
> >>>>>>>>> On Wed, May 13, 2026 at 03:01:47PM +0300, Dmitry Baryshkov wrote:
> >>>>>>>>>> On Wed, May 13, 2026 at 04:28:35AM +0000, sashiko-bot at kernel.org wrote:
> >>>>>>>>>>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> >>>>>>>>>>> - [High] The PMIC regulator definitions omit their required input supply dependencies (e.g., `vdd_s2-supply`, `vdd_l3-supply`), breaking the power hierarchy.
> >>>>>>>>>>> - [Medium] The device tree inaccurately hardcodes the `compatible` string to a different PMIC model (`qcom,rpm-pm2250-regulators`) instead of explicitly identifying the actual hardware (PM4125).
> >>>>>>>>>>> --
> >>>>>>>>>>>> +
> >>>>>>>>>>>> +         pm4125_s2: s2 {
> >>>>>>>>>>>> +                 regulator-min-microvolt = <1000000>;
> >>>>>>>>>>>> +                 regulator-max-microvolt = <1200000>;
> >>>>>>>>>>>> +         };
> >>>>>>>>>>>
> >>>>>>>>>>> Do these regulators need to explicitly define their input supply dependencies
> >>>>>>>>>>> such as vdd_s2-supply?
> >>>>>>>>>>>
> >>>>>>>>>>> Without these properties, the regulator framework might be unaware that the
> >>>>>>>>>>> PMIC regulators draw power from upstream supplies.
> >>>>>>>>>>>
> >>>>>>>>>>> If the kernel dynamically manages the upstream supply and its reference count
> >>>>>>>>>>> drops to zero, could it be disabled, causing an unexpected power loss for
> >>>>>>>>>>> downstream components?
> >>>>>>>>>>
> >>>>>>>>>> And this is a correct comment. Please provide missing supplies.
> >>>>>>>>>>
> >>>>>>>>> As per the Qualcomm system design, the parent-child supply relationship
> >>>>>>>>> is managed by the RPM firmware, not the Linux regulator framework. The
> >>>>>>>>> RPM ensures the parent supply is never disabled until all subsystem
> >>>>>>>>> votes are cleared.
> >>>>>>>>
> >>>>>>>> How is this different from other, previous platforms?
> >>>>>>>
> >>>>>>> This is not different. In the previous platforms too this is taken care from the
> >>>>>>> RPM/RPMH firmware side, the only case where we may need explicit vote to parent
> >>>>>>> is for non-rpmh/rpm regulator rails (like i2c based regulator pm8008), which
> >>>>>>> may have a RPM/RPMH regulator as a parent.
> >>>>>>>
> >>>>>>> Even on those previous targets the parent rail of all RPM/RPMH regulators are
> >>>>>>> internally voted by RPM/RPMH FW at proper voltage with required headroom
> >>>>>>> calculated based on the active child rails. This was done for all the
> >>>>>>> subsystems (including APPS) regulators.
> >>>>>>>
> >>>>>>> So no explicit handling from the APPS is required for parent supply.
> >>>>>>
> >>>>>> You are explaining the driver behaviour. But the question is about the
> >>>>>> hardware description. If there is no difference, please add necessary
> >>>>>> supplies back.
> >>>>>
> >>>>> I understand your concern about descibing the parent-child relation in the
> >>>>> devicetree, and given that we have been almost always followed this for all
> >>>>> the previous targets, it will expected of us to add them.
> >>>>
> >>>> Yes.
> >>>>
> >>>>>
> >>>>> However, we want to avoid the unnecessary access to the parent from APPS.
> >>>>
> >>>> Why? What is the reason? Do we want to do the same for all the
> >>>> platforms? Only for Shikra? Something else?
> >>>>
> >>>>> At the moment, I do not see a way to avoid that, if we add the parent
> >>>>> regulators.
> >>>>
> >>>> That depend on the answer to the previous question. In the end, we can
> >>>> make the driver ignore the parents by removing them from the regulator
> >>>> desc.
> >>>
> >>> Ok, this seems like a good suggestion, so you mean its ok if we define the
> >>> regulator desc's supply column with NULL? And only keep that in the DT?
> >>>
> >>> you mean like this?
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/qcom-rpmh-regulator.c?h=v7.1#n1453
> >>>
> >>> (please let me know if i got that right. thanks)
> >>
> >> Yes. Don't forget to explain in the commit message, why you are doing
> >> so.
> > 
> > Currently, Agatti uses the same PMIC, so we cannot set the driver
> > supply name reference to NULL. Since it's an older target,
> > we'll need to run a regression before making any driver-level changes.
> > 
> > Additionally, the child-to-parent regulator ganging differs between
> > Shikra and Agatti:
> > 
> >  - On Agatti, l3 regulator is ganged with vdd_l13_l14_l15_l16
> >  - On Shikra, l3 is ganged with vdd_l2_l3
> 
> Is it configurable on the PMIC level? I was under the impression the
> supply maps are fixed in hardware.  Is there a chance the agatti
> description is just wrong?

The supply ganging between child LDOs and parent supplies is not fixed
at the PMIC hardware level — it varies per platform based on system
design requirements. The same LDO can have a different parent supply on
different SoCs.

I have verified the Agatti parent-child supply mappings and they are
correct. The difference between Agatti and Shikra is a legitimate
platform-level design difference, not an error in the Agatti DT.

regards
Rakesh Kota