Extend the usb-switch binding to support DisplayPort (DP) alternate
modes. A third port for the DP signal is necessary when a mode-switch is
muxing USB and DP together onto a usb type-c connector. Add data-lanes
to the usbc output node to allow a device using this binding to remap
the data lanes on the output. Add an example to show how this new port
can be used.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Conor Dooley <conor+dt@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>
---
.../devicetree/bindings/usb/usb-switch.yaml | 89 +++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml
index f5dc7e23b134..816f295f322f 100644
--- a/Documentation/devicetree/bindings/usb/usb-switch.yaml
+++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml
@@ -52,6 +52,14 @@ properties:
endpoint:
$ref: '#/$defs/usbc-in-endpoint'
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: '#/$defs/dp-endpoint'
+
oneOf:
- required:
- port
@@ -65,6 +73,19 @@ $defs:
$ref: /schemas/graph.yaml#/$defs/endpoint-base
description: Super Speed (SS) output endpoint to a type-c connector
unevaluatedProperties: false
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array of physical USB Type-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
usbc-in-endpoint:
$ref: /schemas/graph.yaml#/$defs/endpoint-base
@@ -79,7 +100,75 @@ $defs:
items:
maximum: 8
+ dp-endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description: DisplayPort (DP) input from the DP PHY
+ 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
+
examples:
+ # A USB + DP mode and orientation switch which muxes DP altmode
+ # and USB onto a usb-c-connector node.
+ - |
+ device {
+ mode-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint {
+ remote-endpoint = <&usb_c_connector>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint {
+ remote-endpoint = <&usb_ss_phy>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ endpoint {
+ remote-endpoint = <&dp_phy>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+ };
+
# A USB orientation switch which flips the pin orientation
# for a usb-c-connector node.
- |
--
https://chromeos.devOn Sat, Aug 31, 2024 at 09:06:51PM GMT, Stephen Boyd wrote:
> Extend the usb-switch binding to support DisplayPort (DP) alternate
> modes. A third port for the DP signal is necessary when a mode-switch is
> muxing USB and DP together onto a usb type-c connector. Add data-lanes
> to the usbc output node to allow a device using this binding to remap
> the data lanes on the output. Add an example to show how this new port
> can be used.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Conor Dooley <conor+dt@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>
> ---
> .../devicetree/bindings/usb/usb-switch.yaml | 89 +++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml
> index f5dc7e23b134..816f295f322f 100644
> --- a/Documentation/devicetree/bindings/usb/usb-switch.yaml
> +++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml
> @@ -52,6 +52,14 @@ properties:
> endpoint:
> $ref: '#/$defs/usbc-in-endpoint'
>
> + port@2:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> +
> + properties:
> + endpoint:
> + $ref: '#/$defs/dp-endpoint'
Is it a separate port or is it an endpoint of the same upstream-facing
(non-connector-facing) SS port?
> +
> oneOf:
> - required:
> - port
> @@ -65,6 +73,19 @@ $defs:
> $ref: /schemas/graph.yaml#/$defs/endpoint-base
> description: Super Speed (SS) output endpoint to a type-c connector
> unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB Type-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
What is the usecase to delare less than 4 lanes going to the USB-C
connector?
>
> usbc-in-endpoint:
> $ref: /schemas/graph.yaml#/$defs/endpoint-base
> @@ -79,7 +100,75 @@ $defs:
> items:
> maximum: 8
>
> + dp-endpoint:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: DisplayPort (DP) input from the DP PHY
> + 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
> +
> examples:
> + # A USB + DP mode and orientation switch which muxes DP altmode
> + # and USB onto a usb-c-connector node.
> + - |
> + device {
> + mode-switch;
> + orientation-switch;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + endpoint {
> + remote-endpoint = <&usb_c_connector>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + endpoint {
> + remote-endpoint = <&usb_ss_phy>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + endpoint {
> + remote-endpoint = <&dp_phy>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> + };
> +
> # A USB orientation switch which flips the pin orientation
> # for a usb-c-connector node.
> - |
> --
> https://chromeos.dev
>
--
With best wishes
Dmitry
Quoting Dmitry Baryshkov (2024-09-19 03:40:19) > On Sat, Aug 31, 2024 at 09:06:51PM GMT, Stephen Boyd wrote: > > diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml > > index f5dc7e23b134..816f295f322f 100644 > > --- a/Documentation/devicetree/bindings/usb/usb-switch.yaml > > +++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml > > @@ -52,6 +52,14 @@ properties: > > endpoint: > > $ref: '#/$defs/usbc-in-endpoint' > > > > + port@2: > > + $ref: /schemas/graph.yaml#/$defs/port-base > > + unevaluatedProperties: false > > + > > + properties: > > + endpoint: > > + $ref: '#/$defs/dp-endpoint' > > Is it a separate port or is it an endpoint of the same upstream-facing > (non-connector-facing) SS port? I don't quite follow this comment. This is an input DP endpoint/port. > > > + > > oneOf: > > - required: > > - port > > @@ -65,6 +73,19 @@ $defs: > > $ref: /schemas/graph.yaml#/$defs/endpoint-base > > description: Super Speed (SS) output endpoint to a type-c connector > > unevaluatedProperties: false > > + properties: > > + data-lanes: > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > + description: | > > + An array of physical USB Type-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 > > What is the usecase to delare less than 4 lanes going to the USB-C > connector? I'm not aware of any usecase. The 'maximum: 3' is the max value in the cell, i.e. 0, 1, 2, or 3.
On Thu, Oct 10, 2024 at 06:43:35PM -0400, Stephen Boyd wrote: > Quoting Dmitry Baryshkov (2024-09-19 03:40:19) > > On Sat, Aug 31, 2024 at 09:06:51PM GMT, Stephen Boyd wrote: > > > diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml > > > index f5dc7e23b134..816f295f322f 100644 > > > --- a/Documentation/devicetree/bindings/usb/usb-switch.yaml > > > +++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml > > > @@ -52,6 +52,14 @@ properties: > > > endpoint: > > > $ref: '#/$defs/usbc-in-endpoint' > > > > > > + port@2: > > > + $ref: /schemas/graph.yaml#/$defs/port-base > > > + unevaluatedProperties: false > > > + > > > + properties: > > > + endpoint: > > > + $ref: '#/$defs/dp-endpoint' > > > > Is it a separate port or is it an endpoint of the same upstream-facing > > (non-connector-facing) SS port? > > I don't quite follow this comment. This is an input DP endpoint/port. This is the question: is this a separate port or just an endpoint on the port? > > > > > > + > > > oneOf: > > > - required: > > > - port > > > @@ -65,6 +73,19 @@ $defs: > > > $ref: /schemas/graph.yaml#/$defs/endpoint-base > > > description: Super Speed (SS) output endpoint to a type-c connector > > > unevaluatedProperties: false > > > + properties: > > > + data-lanes: > > > + $ref: /schemas/types.yaml#/definitions/uint32-array > > > + description: | > > > + An array of physical USB Type-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 > > > > What is the usecase to delare less than 4 lanes going to the USB-C > > connector? > > I'm not aware of any usecase. The 'maximum: 3' is the max value in the > cell, i.e. 0, 1, 2, or 3. -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.