Re: [PATCH v8 1/4] dt-bindings: i2c: qcom,i2c-geni: Document multi-owner controller support

[Bjorn Andersson]

On Wed, Jul 08, 2026 at 10:40:07AM +0530, Mukesh Kumar Savaliya wrote:
> Document a DeviceTree property to describe QUP-based I2C controllers that
> are shared with one or more other system processors.
> 
> On some Qualcomm platforms, a QUP-based I2C controller may be accessed by
> multiple system processors (for example, APPS and DSP). In such
> configurations, the operating system must not assume exclusive ownership
> of the controller or its associated hardware resources.
> 
> The new qcom,qup-multi-owner property indicates that the controller is
> externally shared and that the operating system must avoid operations
> which rely on sole control of the hardware.
> 
> Acked-by: Rob Herring (Arm) <robh@xxxxxxxxxx>
> Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@xxxxxxxxxxxxxxxx>
> ---
>  .../bindings/i2c/qcom,i2c-geni-qcom.yaml         | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> index 51534953a69c..ed9b029603fd 100644
> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> @@ -60,6 +60,22 @@ properties:
>    power-domains:
>      maxItems: 1
>  
> +  qcom,qup-multi-owner:
> +    type: boolean
> +    description:
> +      Indicates that the QUP-based controller is shared with one or more
> +      other system processors and must not be assumed to have exclusive
> +      ownership by the operating system.
> +
> +      The associated GPIOs must not be reconfigured into a sleep state
> +      during runtime suspend, as doing so may disrupt transactions
> +      initiated by another owner of the controller.

I think this should be made even clearer that this defined a requirement
on the operating system. I also think that "sleep state" is a misnomer,
it's not the sleep state as such that is the problem (what happens if I
define a sleep state with functional settings, or what happens if I
define an "idle" state?)

One way to handle this would be to declare that only "default" state is
allowed, when this property is specified.

If we still want this, I think it should be rephrased something like:

"""
When this option is present the Operating System must ignore any
non-default pinctrl state configuration, as reconfiguring the associated
pins might disrupt transactions initiated by another owner of the
controller.
"""

Regards,
Bjorn

> +
> +      Each owner is responsible for maintaining any resource votes
> +      required for operation of the shared controller (for example clocks,
> +      power domains, interconnect bandwidth, or other platform-specific
> +      resources)
> +
>    reg:
>      maxItems: 1
>  
> -- 
> 2.43.0
>