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

Fri Jul 3 08:28:27 PDT 2026

On Tue, Jun 30, 2026 at 06:12:20PM +0530, 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.

Sure, just do it please.

> 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

Well, somebody tried to be too smart when contributing Agatti. Now that
needs to be fixed. Be sure to keep backwards compatibility with the
existing DTs.

>From the schematics that I see, the pins are:

- vin_l1
- vin_l2_l3
- vin_l5_l6_l7_l11_l12
- vin_l8_l9
- vin_l10
- vin_l13_l14
- vin_l15_l16
- vin_l17_l22
- vin_l18_l19
- vin_l4_l20_l21
- vin_xo_rf

Please correct the bindings and adjust the driver.

> Since vdd_l2_l3 is not present as a supply name in the driver, it will
> be skipped by the driver and would only serve as a representational
> reference in the DT.
> 
> We have two options to consider:
> 
> Option 1: Skip adding the child/parent relationship for Shikra for now,
> since the DT bindings are not enforcing it. (Ref:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml?h=v7.1)
> 
> Option 2: Go ahead and add the Shikra-specific ganging in DT now. Since
> the supply name (vdd_l2_l3) does not match what the driver expects
> (Agatti's mapping), it will be gracefully skipped by the driver — making
> it safe to add for documentation/representation purposes without any
> functional impact.
> 
> So,Please share your thoughts on above options ?

Option 3. The PMIC is not Shikra-specific. You've spotted an error.
Correct the way it is described an used while adding support for Shikra.

-- 
With best wishes
Dmitry