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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2435 bytes --]

On Wed, Jul 01, 2026 at 10:43:01AM +0800, Fenglin Wu wrote:

> Qcom PMH0101 includes bi-directional level-shifter (BIDIR_LVL_SHIFTER)
> modules that act as open-drain voltage translators, mainly to support
> 1.2 to 1.8V voltage translation on the I2C bus between the SoC with 1.2V
> IOs and other I2C clients with 1.8V IOs. Each module shares two physical
> pins with two GPIO modules, and control of the BIDIR_LVL_SHIFTER module
> is centralized on the AOP side with 'XOB' resources so it can be shared
> between different subsystems.

> When a BIDIR_LVL_SHIFTER is enabled, it needs to send RPMh commands to
> enable it and SPMI commands to disable the related two GPIO modules, to
> make sure their circuitry does not interfere with it. For now, the
> suggestion is to write a new driver for BIDIR_LVL_SHIFTER and place it
> as a child of the rpmh_rsc device, and refer to pinstate nodes to
> disable these two GPIO modules. However, we are now facing a difficulty
> in deciding which subsystem the new driver should belong to. We expected
> that the new driver should provide following capabilities:

To the extent any of this is comprehensible (I don't know what things
like AOP, XOB and so on are) nothing about this is screaming regulator.
It sounds like you just want to turn on and off a device to make the bus
you're talking through work?

> 1. Enable and disable the level-shifter at runtime. Consumers, likely
> I2C client devices, will enable it when active and disable it when not,
> mainly to save power.
> 2. Allow sharing the level-shifter between multiple consumers, even
> across different subsystems (currently managed by AOP).

> Following are the approaches that we are considered, and it seems only a
> regulator device could satisfy the requirement the best but we want to
> check with you if you are fine to put it in the regulator framework.

Why would this be a regulator?  It's not providing power to anything
which is a fairly key element of being a regulator, it fits about as
well with clocks (which also provide reference counting which is AFAICT
what you're looking for here).  You'll have a hard time writing DTs for
this that actually refelect the hardware I think.  Possibly it's a power
domain (or a resource controlled by a power domain, I know they manage
clocks and regulators)? 

Possibly work out a DT binding for this and then work back from there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]