Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands

[Dmitry Baryshkov]

On Thu, Jun 04, 2026 at 10:02:43AM +0800, Fenglin Wu wrote:
> 
> On 6/2/2026 3:29 PM, Fenglin Wu wrote:
> > 
> > On 6/1/2026 9:37 PM, Dmitry Baryshkov wrote:
> > > On Thu, May 28, 2026 at 06:05:35PM -0700, Fenglin Wu wrote:
> > > > Currently, the RPMH driver only allows child devices of the RPMH
> > > > controller to issue commands, as it assumes dev->parent points to the
> > > > RSC device.
> > > > 
> > > > There is a possibility that certain devices which are not children of
> > > > the RPMH controller want to send commands for special control at the
> > > > RPMH side. For example, in PMH0101 PMICs, there are bidirectional
> > > > level shifter (LS) peripherals, and each LS works with a pair of PMIC
> > > > GPIOs. The control of the LS, which is combined with the GPIO
> > > > configuration, is handled by RPMH firmware for sharing the resource
> > > > between different subsystems. From a hardware point of view, the LS
> > > > functionality is tied to a pair of PMIC GPIOs, so its control is more
> > > > suitable to be added in the pinctrl-spmi-gpio driver by adding the
> > > > level-shifter function. However, the pinctrl-spmi-gpio device is a
> > > > child device of the SPMI controller, not the RPMH controller.
> > > This replicates the story of the PMIC regulators. There are two drivers,
> > > one SPMI and one RPMh. Why don't we add a separate, RPMh-based GPIO
> > > driver targeting only those paired GPIOs (and we don't even need to
> > > represent them as a pair, it might be just one pin).
> > 
> > Thanks for the suggestion.
> > 
> > I agree that adding a separate, RPMh-based GPIO driver would be more
> > straightforward from RPMh control perspective. It makes the new device
> > as a child of the RSC device then it can naturally use the APIs for RPMh
> > commands. The main challenge here is, we need to make the level-shifter
> > mutually exclusive with other GPIO functions when the GPIO pairs are
> > used in level-shifter function, which means we need to write SPMI
> > commands to disable the associated GPIO modules. I am not sure if AOP
> > already handles this; as far as I know, AOP only manages the
> > BIDIR_LVL_SHIFTER module registers. Let me double check on this
> > internally, if the GPIO modules could be controlled along
> > with BIDIR_LVL_SHIFTER module registers at AOP side, and get back.
> > 
> I checked on this internally, AOP only handles BIDIR_LVL_SHIFTER module
> registers, it doesn't disable the associated GPIO modules. Also, I still
> have no idea how could we make the "level-shifter" function to be mutually
> exclusive with other GPIO functions after moved it into a separate driver.
> Do you have further suggestions?

So, for my understanding, we still need to write SPMI registers to
configure the pins and only then AOP can handle the level shifter?

I was thinking of using gpio-reserved-ranges to prevent those GPIOs from
being used by the normal SPMI driver.

-- 
With best wishes
Dmitry