Re: [PATCH v2 2/4] dt-bindings: pinctrl: qcom,pmic-gpio: Add level-shifter function

[Fenglin Wu]

On 6/1/2026 7:30 PM, Krzysztof Kozlowski wrote:
> On 01/06/2026 07:00, Fenglin Wu wrote:
> > On 5/30/2026 6:29 PM, Krzysztof Kozlowski wrote:
> > > On Thu, May 28, 2026 at 06:05:36PM -0700, Fenglin Wu wrote:
> > > > Add the "level-shifter" function and add the required DT properties to
> > > > allow RPMh firmware to control the level-shifter. Introduce a custom
> > > > pinconf parameter "qcom,1p2v-1p8v-ls-en" for enabling or disabling the
> > > > level-shifter function.
> > > I don't get how PMIC, which is not a child of RPMh at all or not
> > > talking with RPMh RSC, needs to configure its pin via RPMh. It feels it
> > > is misrepresented.
> > The control for enabling or disabling the bi-directional level shifter
> > has been centralized in AOP, similar to how regulator resources are
> > managed. This allows it to be used on a serial bus shared by multiple
> > clients from different subsystems. Each subsystem can vote for its
> > enable state through RPMh commands, and AOP determines the final status
> > to turn the BIDIR_LVL_SHIFTER PMIC modules on or off. Additionally, each
> > bi-directional level shifter shares its physical pins with a pair of
> > PMIC GPIO modules and is mutually exclusive with other PMIC GPIO
> > functions, which means those PMIC GPIO functions must be disabled.
> So two completely independent hardware devices - PMIC and RPMh -
> configure the same hardware - level shifter and pin function?

Yes if we consider level shifter as a mux function of the GPIO pairs.

> > For these reasons, adding bi-directional level shifter software support
> > to the pinctrl-spmi-gpio driver is considered the best approach. Let me
> > know if you have a better suggestion.
> >
> > > > Additionally, add the "groups" property with the allowed group names
> > > > that can be used to control the level-shifter function on pmh0101.
> > > >
> > > > Signed-off-by: Fenglin Wu <fenglin.wu@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >    .../bindings/pinctrl/qcom,pmic-gpio.yaml           | 66 +++++++++++++++++++++-
> > > >    include/dt-bindings/pinctrl/qcom,pmic-gpio.h       |  1 +
> > > >    2 files changed, 64 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> > > > index b8109e6c2a10..19dc61ddff2d 100644
> > > > --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> > > > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> > > > @@ -119,6 +119,21 @@ properties:
> > > >          The first cell will be used to define gpio number and the
> > > >          second denotes the flags for this gpio
> > > >    
> > > > +  qcom,rpmh:
> > > > +    description:
> > > > +      Phandle to the RPMh controller device. Required for PMICs when the
> > > > +      bidirectional level shifters is used (e.g., pmh0101), to enable
> > > > +      communication with RPMh firmware for level shifter control.
> > > > +    $ref: /schemas/types.yaml#/definitions/phandle
> > > > +
> > > > +  qcom,pmic-id:
> > > > +    description:
> > > > +      The ID of the PMIC which supports bidirectional level shifter function.
> > > > +      It is used as the RPMh resource name suffix to request control of the
> > > > +      level shifter to the RPMh firmware.
> > > > +    $ref: /schemas/types.yaml#/definitions/string
> > > > +    pattern: "^[A-N]_E[0-3]+$"
> > > You do not get instance IDs (it's explcitly documented in docs).
> > Okay. This is primarily for creating the resource names used to obtain
> > the rpmh addresses from the cmd-db for the level-shifter.
> >
> > I can change it to a different name if you still agree to add the
> > support in the pinctrl driver.
> ID or name, same thing. Still not allowed.

Okay. Then I don't know how could the driver be able to get the rpmh 
address from the cmd-db.

Maybe just like what Dmitry suggested, register a separate, RPMh-based 
GPIO driver for those GPIOs associated with the level shifter function, 
would be a better approach?

Re: [PATCH v2 1/4] soc: qcom: rpmh: Allow non-child devices to issue 
write commands - Dmitry Baryshkov 
<https://lore.kernel.org/linux-arm-msm/4ac5hjmr6divqs4myhcw5sveuboj265sw2jwslbivrfwh5e7ce@6d7ajvgikkgt/>

> > > > +
> > > >    additionalProperties: false
> > > >    
> > > >    required:
> > > > @@ -330,6 +345,22 @@ allOf:
> > > >              contains:
> > > >                enum:
> > > >                  - qcom,pmh0101-gpio
> > > > +    then:
> > > > +      properties:
> > > > +        gpio-line-names:
> > > > +          minItems: 18
> > > > +          maxItems: 18
> > > > +        gpio-reserved-ranges:
> > > > +          minItems: 1
> > > > +          maxItems: 9
> > > > +        qcom,rpmh: true
> > > > +        qcom,pmic-id: true
> > > > +
> > > > +  - if:
> > > > +      properties:
> > > > +        compatible:
> > > > +          contains:
> > > > +            enum:
> > > >                  - qcom,pmih0108-gpio
> > > >        then:
> > > >          properties:
> > > > @@ -523,6 +554,19 @@ $defs:
> > > >            items:
> > > >              pattern: '^gpio([0-9]+)$'
> > > >    
> > > > +      groups:
> > > > +        $ref: /schemas/types.yaml#/definitions/string-array
> > > > +        description:
> > > > +          List of GPIO groups to apply properties to. Only valid for
> > > > +          function "level-shifter" on pmh0101. Valid groups are
> > > > +          gpio11, gpio12; gpio13, gpio14; gpio15, gpio16; gpio17, gpio18.
> > > > +        items:
> > > > +          enum:
> > > > +            - gpio11, gpio12
> > > > +            - gpio13, gpio14
> > > > +            - gpio15, gpio16
> > > > +            - gpio17, gpio18
> > > > +
> > > >          function:
> > > >            items:
> > > >              - enum:
> > > > @@ -536,6 +580,7 @@ $defs:
> > > >                  - dtest4
> > > >                  - func3  # supported by LV/MV GPIO subtypes
> > > >                  - func4  # supported by LV/MV GPIO subtypes
> > > > +              - level-shifter  # supported only by pmh0101
> > > >    
> > > >          bias-disable: true
> > > >          bias-pull-down: true
> > > > @@ -592,9 +637,24 @@ $defs:
> > > >              configured as digital input.
> > > >            enum: [1, 2, 3, 4]
> > > >    
> > > > -    required:
> > > > -      - pins
> > > > -      - function
> > > > +      qcom,1p2v-1p8v-ls-en:
> > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > +        description:
> > > > +          Enable or disable the bidirectional 1.2V/1.8V level shifter
> > > > +          associated with the specified GPIO group. When set to 1, an RPMh
> > > > +          vote is sent to AOP to enable the level shifter. When set to 0,
> > > > +          the vote is withdrawn. Only valid when function is "level-shifter"
> > > > +          and groups is a level-shifter GPIO pair (e.g., "gpio11, gpio12"
> > > > +          on pmh0101).
> > > And there are no generic pinconf properties defining the voltage?
> > The 1.2V and 1.8V voltages on each side of the bidirectional level
> > shifter are not configurable. They are fixed in the hardware with
> > built-in reference voltages at each side of the pins. I am adding this
> > custom pinconf parameter mainly to control its enabling status. Also, I
> > am adding "1p2v-1p8v" in the parameter name to provide additional
> > clarity for users about the "level-shifter" function.
> So there are or there are not?

There is not such generic pinconf parameter based what I saw here:

https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/tree/drivers/pinctrl/pinconf-generic.c#n173

> Best regards,
> Krzysztof