Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
In-Reply-To: <20220615172129.1314056-5-pmalani@chromium.org>
References: <20220615172129.1314056-1-pmalani@chromium.org> <20220615172129.1314056-5-pmalani@chromium.org>
From:   Stephen Boyd <swboyd@chromium.org>
User-Agent: alot/0.10
Date:   Thu, 16 Jun 2022 00:42:01 -0700
Message-ID: <CAE-0n53ub30HXB325wPoMB4C3n4j_9FWnNu5AmtYgU3PBvs8mQ@mail.gmail.com>
Subject: Re: [PATCH v4 4/7] dt-bindings: drm/bridge: anx7625: Add mode-switch support
To:     Prashant Malani <pmalani@chromium.org>,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Cc:     bleung@chromium.org, heikki.krogerus@linux.intel.com,
        =?UTF-8?B?TsOtY29sYXMgRiAuIFIgLiBBIC4gUHJhZG8=?= 
        <nfraprado@collabora.com>, Andrzej Hajda <andrzej.hajda@intel.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        David Airlie <airlied@linux.ie>, devicetree@vger.kernel.org,
        dri-devel@lists.freedesktop.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Hsin-Yi Wang <hsinyi@chromium.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Jonas Karlman <jonas@kwiboo.se>,
        =?UTF-8?B?Sm9zw6kgRXhww7NzaXRv?= <jose.exposito89@gmail.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
        Maxime Ripard <maxime@cerno.tech>,
        Neil Armstrong <narmstrong@baylibre.com>,
        Pin-Yen Lin <treapking@chromium.org>,
        Robert Foss <robert.foss@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Sam Ravnborg <sam@ravnborg.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Xin Ji <xji@analogixsemi.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Quoting Prashant Malani (2022-06-15 10:20:20)
>
>  .../display/bridge/analogix,anx7625.yaml      | 64 +++++++++++++++++++
>  1 file changed, 64 insertions(+)

Can this file get a link to the product brief[1]? It helps to quickly
find the block diagram.

>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index 35a48515836e..bc6f7644db31 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -105,6 +105,34 @@ properties:
>        - port@0
>        - port@1
>
> +  switches:
> +    type: object
> +    description: Set of switches controlling DisplayPort traffic on
> +      outgoing RX/TX lanes to Type C ports.
> +    additionalProperties: false
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +    patternProperties:
> +      '^switch@[01]$':
> +        $ref: /schemas/usb/typec-switch.yaml#
> +        unevaluatedProperties: false
> +
> +        properties:
> +          reg:
> +            maxItems: 1
> +
> +        required:
> +          - reg
> +
> +    required:
> +      - switch@0
> +
>  required:
>    - compatible
>    - reg
> @@ -167,5 +195,41 @@ examples:
>                      };
>                  };
>              };
> +            switches {

Is "switches" a bus?

> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                switch@0 {
> +                    compatible = "typec-switch";

Is this compatible matched against a driver that's populated on this
"switches" bus?

> +                    reg = <0>;
> +                    mode-switch;
> +
> +                    ports {
> +                        #address-cells = <1>;
> +                        #size-cells = <0>;
> +                        port@0 {
> +                            reg = <0>;
> +                            anx_typec0: endpoint {
> +                                remote-endpoint = <&typec_port0>;
> +                            };
> +                        };
> +                    };

I was expecting to see these simply be more ports in the existing graph
binding of this device, and then have the 'mode-switch' or
'orientation-switch' properties be at the same level as the compatible
string "analogix,anx7625". Here's the reasoning, based on looking at the
product brief and the existing binding/implementation.

Looking at the only existing implementation of this binding upstream in
mt8183-kukui-jacuzzi.dtsi it looks like one of these typec ports is
actually the same physically as the 'anx7625_out' endpoint (reg address
of 1) that is already defined in the binding. It seems that MIPI DSI/DPI
comes in and is output through 2 lanes, SSRX2 and SSTX2 according to the
product brief[1], and that is connected to some eDP panel
("auo,b116xw03"). Presumably that is the same as anx_typec1 in this
patch? I suspect the USB3.1 input is not connected on this board, and
thus the crosspoint switch is never used, nor the SSRX1/SSTX1 pins.

The existing binding defines the MIPI DSI/DPI input as port0 and two of
the four lanes of output that is probably by default connected to the
"DisplayPort Transmitter" as port1 because that's how the crosspoint
switch comes out of reset. That leaves the USB3.1 input possibly needing
a port in the ports binding, and the other two lanes of output needing a
port in the ports binding to describe their connection to the downstream
device. And finally information about if the crosspoint switch needs to
be registered with the typec framework to do typec things, which can be
achieved by the presence of the 'mode-switch' property.

On a board like kukui-jacuzzi these new properties and ports wouldn't be
specified, because what is there is already sufficient. If this chip is
connected to a usb-c-connector then I'd expect to see a connection from
the output ports in the graph binding to the connector node's ports.
There aren't any ports in the usb-c-connector binding though from what I
see.

I believe there's also one more use case here where USB3.1 or MIPI
DSI/DPI is connected on the input side and this device is used to steer
USB3.1 or DP through the crosspoint switch to either of the two output
pairs. This last scenario means that we have to describe both output
pairs, SSRX1/SSTX1 and SSRX2/SSTX2, as different ports in the binding so
they can be connected to different usb-c-connectors if the hardware
engineer wired the output pins that way.

TL;DR: Can we add 'mode-switch' as an optional property and two more
ports at address 2 and 3 for the USB3.1 input and the SSRX1/SSTX1 pair
respectively to the existing graph part of this binding?

> +                };
> +                switch@1 {
> +                    compatible = "typec-switch";
> +                    reg = <1>;
> +                    mode-switch;
> +
> +                    ports {
> +                        #address-cells = <1>;
> +                        #size-cells = <0>;
> +                        port@0 {
> +                            reg = <0>;
> +                            anx_typec1: endpoint {
> +                                remote-endpoint = <&typec_port1>;
> +                            };
> +                        };
> +                    };
> +                };
> +            };
>          };

[1] https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf