linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Stephen Boyd <swboyd@chromium.org>, chrome-platform@lists.linux.dev
Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org,
	Douglas Anderson <dianders@chromium.org>,
	Pin-yen Lin <treapking@chromium.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Lee Jones <lee@kernel.org>,
	Benson Leung <bleung@chromium.org>,
	Guenter Roeck <groeck@chromium.org>,
	Prashant Malani <pmalani@chromium.org>,
	Tzung-Bi Shih <tzungbi@kernel.org>
Subject: Re: [PATCH 13/22] dt-bindings: chrome: Add google,cros-ec-typec-switch binding
Date: Sun, 11 Feb 2024 14:34:25 +0100	[thread overview]
Message-ID: <46ac6ab8-b0a5-497d-91b6-1d2ced33184b@linaro.org> (raw)
In-Reply-To: <20240210070934.2549994-14-swboyd@chromium.org>

On 10/02/2024 08:09, Stephen Boyd wrote:
> Add a binding for the USB type-c switch controls found on some ChromeOS
> Embedded Controllers (ECs). When this device is a mode switch, it takes
> one DisplayPort (DP) port as input and some number (possibly zero) of
> USB SuperSpeed ports (bundles of USB SS lanes) as input, and muxes those
> lanes into USB type-c SuperSpeed lanes suitable for the SSTRX1/2 pins on
> a usb-c-connector. When this device is an orientation switch, it
> redirects the DP lanes to the proper USB type-c SSTRX lanes.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Lee Jones <lee@kernel.org>
> Cc: Benson Leung <bleung@chromium.org>
> Cc: Guenter Roeck <groeck@chromium.org>
> Cc: Prashant Malani <pmalani@chromium.org>
> Cc: Tzung-Bi Shih <tzungbi@kernel.org>
> Cc: <devicetree@vger.kernel.org>
> Cc: <chrome-platform@lists.linux.dev>
> Cc: Pin-yen Lin <treapking@chromium.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
>  .../chrome/google,cros-ec-typec-switch.yaml   | 365 ++++++++++++++++++
>  .../bindings/mfd/google,cros-ec.yaml          |   5 +
>  2 files changed, 370 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml
> 
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml
> new file mode 100644
> index 000000000000..17a0ba928f5d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec-switch.yaml
> @@ -0,0 +1,365 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/chrome/google,cros-ec-typec-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google Chrome OS EC(Embedded Controller) USB Type C Switch
> +
> +maintainers:
> +  - Benson Leung <bleung@chromium.org>
> +  - Prashant Malani <pmalani@chromium.org>
> +  - Stephen Boyd <swboyd@chromium.org>
> +
> +description:
> +  Chrome OS devices have an Embedded Controller(EC) which has access to USB
> +  Type C switching. This node is intended to allow the OS to control Type C
> +  signal muxing for USB-C orientation and alternate modes. The node for this
> +  device should be under a cros-ec node like google,cros-ec-spi.
> +

If this is USB Type C switch, then you miss reference to
usb-switch.yaml, but then ports look a bit different.

> +properties:
> +  compatible:
> +    const: google,cros-ec-typec-switch
> +
> +  mode-switch:
> +    description: Indicates this device controls altmode switching
> +    type: boolean
> +
> +  orientation-switch:
> +    description: Indicates this device controls orientation switching
> +    type: boolean
> +
> +  mux-gpios:
> +    description: GPIOs indicating which way the DP mux is steered

missing maxItems

> +
> +  no-hpd:
> +    description: Indicates this device doesn't signal HPD for DisplayPort
> +    type: boolean
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        description: Input port to receive DisplayPort (DP) data
> +        unevaluatedProperties: false
> +
> +        properties:
> +          endpoint@0:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: DisplayPort data
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical DP data lane indexes
> +                  - 0 is DP ML0 lane
> +                  - 1 is DP ML1 lane
> +                  - 2 is DP ML2 lane
> +                  - 3 is DP ML3 lane
> +                oneOf:
> +                  - items:
> +                      - const: 0
> +                      - const: 1
> +                  - items:
> +                      - const: 0
> +                      - const: 1
> +                      - const: 2
> +                      - const: 3
> +
> +        required:
> +          - endpoint@0
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description:
> +          Input port to receive USB SuperSpeed (SS) data
> +        properties:
> +          endpoint@0:
> +            $ref: /schemas/graph.yaml#/properties/endpoint
> +            description: USB SS data
> +
> +          endpoint@1:
> +            $ref: /schemas/graph.yaml#/properties/endpoint
> +            description: USB SS data
> +
> +        anyOf:
> +          - required:
> +              - endpoint@0
> +          - required:
> +              - endpoint@1
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description:
> +          Output port for USB-C data
> +        properties:
> +          endpoint@0:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@1:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 1st type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@2:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 2nd type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@3:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 3rd type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@4:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 4th type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@5:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 5th type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@6:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 6th type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +          endpoint@7:
> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +            description: USB-C data for EC's 7th type-c port
> +            unevaluatedProperties: false
> +            properties:
> +              data-lanes:
> +                $ref: /schemas/types.yaml#/definitions/uint32-array
> +                description: |
> +                  An array of physical USB-C data lane indexes.
> +                  - 0 is SSRX1 lane
> +                  - 1 is SSTX1 lane
> +                  - 2 is SSTX2 lane
> +                  - 3 is SSRX2 lane
> +                minItems: 4
> +                maxItems: 4
> +                items:
> +                  maximum: 3
> +
> +        anyOf:
> +          - required:
> +              - endpoint@0

I don't get what you want to say here. This anyOf should have no effect.

> +          - required:
> +              - endpoint@1
> +          - required:
> +              - endpoint@2
> +          - required:
> +              - endpoint@3
> +          - required:
> +              - endpoint@4
> +          - required:
> +              - endpoint@5
> +          - required:
> +              - endpoint@6
> +          - required:
> +              - endpoint@7
> +
> +    required:
> +      - port@2
> +    anyOf:
> +      - required:
> +          - port@0
> +      - required:
> +          - port@1

Same problem here

> +
> +required:
> +  - compatible
> +  - ports
> +
> +allOf:
> +  - if:
> +      properties:
> +        no-hpd: true

I don't understand this either. What is it for? Where did you see such
syntax?


> +      required:
> +        - no-hpd> +    then:
> +      properties:
> +        ports:
> +          required:
> +            - port@0
> +  - if:
> +      properties:
> +        mode-switch: true
> +      required:
> +        - mode-switch
> +    then:
> +      properties:
> +        ports:
> +          required:
> +            - port@0
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    spi {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      cros_ec: ec@0 {
> +        compatible = "google,cros-ec-spi";
> +        reg = <0>;
> +        interrupts = <35 0>;

Same concerns about interrupts.

> +
> +        typec-switch {
> +          compatible = "google,cros-ec-typec-switch";
> +          mode-switch;
> +          orientation-switch;
> +
> +          ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +              reg = <0>;
> +              #address-cells = <1>;
> +              #size-cells = <0>;
> +              dp_in: endpoint@0 {
> +                reg = <0>;
> +                remote-endpoint = <&dp_phy>;
> +                data-lanes = <0 1>;
> +              };
> +            };
> +
> +            port@1 {
> +              reg = <1>;
> +              #address-cells = <1>;
> +              #size-cells = <0>;
> +
> +              usb_in_0: endpoint@0 {
> +                reg = <0>;
> +                remote-endpoint = <&usb_ss_0_out>;
> +              };
> +
> +              usb_in_1: endpoint@1 {
> +                reg = <1>;
> +                remote-endpoint = <&usb_ss_1_out>;
> +              };
> +            };
> +
> +            port@2 {
> +              reg = <2>;
> +              #address-cells = <1>;
> +              #size-cells = <0>;
> +
> +              cros_typec_c0_ss: endpoint@0 {
> +                reg = <0>;
> +                remote-endpoint = <&usb_c0_ss>;
> +              };
> +
> +              cros_typec_c1_ss: endpoint@1 {
> +                reg = <1>;
> +                remote-endpoint = <&usb_c1_ss>;
> +              };
> +            };
> +          };
> +        };
> +      };
> +    };
> +...
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index ded396b28fba..563c51a4a39c 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -164,6 +164,10 @@ patternProperties:
>      type: object
>      $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
>  
> +  "^typec-switch[0-9]*$":

Missing - after typec-switch (e.g. typec-switch-1)

> +    type: object
> +    $ref: /schemas/chrome/google,cros-ec-typec-switch.yaml#


Best regards,
Krzysztof


  reply	other threads:[~2024-02-11 13:34 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-10  7:09 [PATCH 00/22] platform/chrome: Add DT USB/DP muxing/topology to Trogdor Stephen Boyd
2024-02-10  7:09 ` [PATCH 01/22] dt-bindings: gpio: Add binding for ChromeOS EC GPIO controller Stephen Boyd
2024-02-11 13:26   ` Krzysztof Kozlowski
2024-02-15  0:44     ` Stephen Boyd
2024-02-15 14:06   ` Rob Herring
2024-02-15 22:00     ` Stephen Boyd
2024-02-10  7:09 ` [PATCH 02/22] gpio: Add ChromeOS EC GPIO driver Stephen Boyd
2024-02-13 17:57   ` Linus Walleij
2024-02-10  7:09 ` [PATCH 03/22] dt-bindings: usb: Add downstream facing ports to realtek binding Stephen Boyd
2024-02-10 11:29   ` Rob Herring
2024-02-10  7:09 ` [PATCH 04/22] usb: core: Set connect_type of ports based on DT node Stephen Boyd
2024-02-14  0:03   ` Doug Anderson
2024-02-14 23:51     ` Stephen Boyd
2024-02-10  7:09 ` [PATCH 05/22] drm/atomic-helper: Introduce lane remapping support to bridges Stephen Boyd
2024-02-10  7:09 ` [PATCH 06/22] drm/bridge: Verify lane assignment is going to work during atomic_check Stephen Boyd
2024-02-10  7:09 ` [PATCH 07/22] device property: Add remote endpoint to devcon matcher Stephen Boyd
2024-02-10  7:09 ` [PATCH 08/22] platform/chrome: cros_ec_typec: Purge blocking switch devlinks Stephen Boyd
2024-02-10  7:09 ` [PATCH 09/22] platform/chrome: cros_typec_switch: Use read_poll_timeout helper Stephen Boyd
2024-02-10  7:09 ` [PATCH 10/22] platform/chrome: cros_typec_switch: Move port creation code to sub-function Stephen Boyd
2024-02-10  7:09 ` [PATCH 11/22] platform/chrome: cros_typec_switch: Use fwnode instead of ACPI APIs Stephen Boyd
2024-02-10  7:09 ` [PATCH 12/22] platform/chrome: cros_typec_switch: Use dev_err_probe() Stephen Boyd
2024-02-10  7:09 ` [PATCH 13/22] dt-bindings: chrome: Add google,cros-ec-typec-switch binding Stephen Boyd
2024-02-11 13:34   ` Krzysztof Kozlowski [this message]
2024-02-15  1:52     ` Stephen Boyd
2024-02-15  8:34       ` Krzysztof Kozlowski
2024-02-11 13:35   ` Krzysztof Kozlowski
2024-02-10  7:09 ` [PATCH 14/22] platform/chrome: cros_typec_switch: Add support for signaling HPD to drm_bridge Stephen Boyd
2024-02-10 14:10   ` Dmitry Baryshkov
2024-02-11  8:52     ` Stephen Boyd
2024-02-11  9:00       ` Dmitry Baryshkov
2024-02-10  7:09 ` [PATCH 15/22] platform/chrome: cros_typec_switch: Support DP muxing via DRM lane assignment Stephen Boyd
2024-02-10  7:09 ` [PATCH 16/22] platform/chrome: cros_typec_switch: Support orientation-switch Stephen Boyd
2024-02-10  7:09 ` [PATCH 17/22] platform/chrome: cros_typec_switch: Handle lack of HPD information Stephen Boyd
2024-02-10  7:09 ` [PATCH 18/22] dt-bindings: chrome: Add binding for ChromeOS Pogo pin connector Stephen Boyd
2024-02-11 13:39   ` Krzysztof Kozlowski
2024-02-15  0:07     ` Stephen Boyd
2024-02-15  8:39       ` Krzysztof Kozlowski
2024-02-14  1:17   ` Doug Anderson
2024-02-15  0:10     ` Stephen Boyd
2024-02-10  7:09 ` [PATCH 19/22] arm64: dts: qcom: sc7180: quackingstick: Disable instead of delete usb_c1 Stephen Boyd
2024-02-10 11:51   ` Dmitry Baryshkov
2024-02-13 23:24   ` Doug Anderson
2024-02-10  7:09 ` [PATCH 20/22] arm64: dts: qcom: sc7180: pazquel: Add missing comment header Stephen Boyd
2024-02-10 11:51   ` Dmitry Baryshkov
2024-02-13 23:24   ` Doug Anderson
2024-02-10  7:09 ` [PATCH 21/22] arm64: dts: qcom: sc7180-trogdor: Make clamshell/detachable fragments Stephen Boyd
2024-02-10 11:53   ` Dmitry Baryshkov
2024-02-13 23:34   ` Doug Anderson
2024-02-15  0:35     ` Stephen Boyd
2024-02-15  0:39       ` Doug Anderson
2024-02-10  7:09 ` [PATCH 22/22] arm64: dts: qcom: sc7180-trogdor: Wire up USB and DP to usb-c-connectors Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46ac6ab8-b0a5-497d-91b6-1d2ced33184b@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=groeck@chromium.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=pmalani@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=swboyd@chromium.org \
    --cc=treapking@chromium.org \
    --cc=tzungbi@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).