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/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.

Also, I would still insist on the pin group configuration, as the 
level-shifter would only work between 2 pins. Do you see any concerns if 
we represent the level-shifter as following even after move to a new driver?

     pmh0101-ls1-en {
     	groups = "gpio11, gpio12";
     	function = "level-shifter";
     	qcom,1p2v-1p8v-ls-en = <1>;
     };

     pmh0101-ls1-dis {
     	groups = "gpio11, gpio12";
     	function = "level-shifter";
     	qcom,1p2v-1p8v-ls-en = <0>;
     };