Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue write commands
From: Fenglin Wu
Date: Wed Jun 03 2026 - 22:19:05 EST
On 6/2/2026 3:29 PM, Fenglin Wu wrote:
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?
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 RPMHThis replicates the story of the PMIC regulators. There are two drivers,
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.
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.