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

[Fenglin Wu <fenglin.wu@oss.qualcomm.com>]

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?