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

[Rakesh Kota]

On Fri, Jul 03, 2026 at 06:32:10PM +0300, Dmitry Baryshkov wrote:
> On Fri, Jul 03, 2026 at 03:00:35PM +0530, Rakesh Kota wrote:
> > 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.
> 
> It can have different power supplies, but the supply is provided through
> a fixed pin of the PMIC. Please correct me if I'm wrong.
> 

You're right, I apologize for the confusion. The supply rail is fixed in
hardware via physical pin connections. The differing supply name in the
Agatti DTS is likely incorrect. 

I'll address this in the next patch series — updating the driver
to set the parent supply to NULL, and correcting the Agatti and Shikra
DT parent supply names to match the actual PMIC pin connections,
since the base change has already been merged.

https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/tree/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi?h=for-next#n52

> > 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.
> 
> There is an error in the DT. It uses fake PMIC supply names.
>
yes, i will correct.

regards
Rakesh Kota