[PATCH 5/7] dt-bindings: usb: google,cros-ec-typec: Add ports for DP altmode
Dmitry Baryshkov
dmitry.baryshkov at oss.qualcomm.com
Thu Apr 24 04:10:31 PDT 2025
On Tue, Apr 15, 2025 at 05:02:05PM -0700, Stephen Boyd wrote:
> Add a DT graph binding to google,cros-ec-typec so that it can combine
> DisplayPort (DP) and USB SuperSpeed (SS) data into a USB type-c endpoint
> that is connected to the usb-c-connector node's SS endpoint. Allow there
> to be multiple 'typec' nodes underneath the EC node so that one DT graph
> exists per DP bridge. The EC is actually controlling TCPCs and redrivers
> that combine the DP and USB signals together so this more accurately
> reflects the hardware design without introducing yet another DT node
> underneath the EC for USB type-c "stuff".
>
> If the type-c ports are being shared between a single DP controller then
> the ports need to know about each other and determine a policy to drive
> DP to one type-c port or the other. If the type-c ports each have their
> own dedicated DP controller then they're able to operate independently
> and enter/exit DP altmode independently as well. We can't connect the DP
> controller's endpoint to one usb-c-connector port at 1 endpoint and the USB
> controller's endpoint to another usb-c-connector port at 1 endpoint either
> because the DP muxing case would have DP connected to two
> usb-c-connector endpoints which the graph binding doesn't support.
>
> Therefore, one typec node is required per the capabilities of the type-c
> port(s) being managed. Add a port to the DisplayPort altmode as well, so
> that we can show the connection between the DP controller and the DP
> altmode. This lets us indicate which type-c ports the DP controller is
> wired to. For example, if DP was connected to ports 0 and 2, while port
> 1 was connected to another DP controller we wouldn't be able to
> implement that without having some other DT property to indicate which
> output ports are connected to the DP endpoint.
>
> Furthermore, this supports ChromeOS designs like Corsola where a DP
> controller/PHY is split with two lanes going to one connector and the
> other two lanes going to another connector. In this case, we wouldn't
> have the graph binding under the cros-ec-typec node, but we would have
> the graph binding in the DP altmode directly connected to the DP
> controller's two output endpoints.
>
> Cc: Rob Herring (Arm) <robh at kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>
> Cc: Conor Dooley <conor+dt at kernel.org>
> Acked-by: Lee Jones <lee at kernel.org>
> Cc: Benson Leung <bleung at chromium.org>
> Cc: Guenter Roeck <groeck at chromium.org>
> Cc: Tzung-Bi Shih <tzungbi at kernel.org>
> Cc: <devicetree at vger.kernel.org>
> Cc: <chrome-platform at lists.linux.dev>
> Cc: Pin-yen Lin <treapking at chromium.org>
> Cc: Abhishek Pandit-Subedi <abhishekpandit at chromium.org>
> Cc: Łukasz Bartosik <ukaszb at chromium.org>
> Cc: Jameson Thies <jthies at google.com>
> Cc: Andrei Kuchynski <akuchynski at chromium.org>
> Signed-off-by: Stephen Boyd <swboyd at chromium.org>
> ---
> .../bindings/connector/usb-connector.yaml | 6 +
> .../bindings/mfd/google,cros-ec.yaml | 7 +-
> .../bindings/usb/google,cros-ec-typec.yaml | 165 ++++++++++++++++++
> 3 files changed, 175 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 11e40d225b9f..e3d60997c03e 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -179,6 +179,12 @@ properties:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: VDO returned by Discover Modes USB PD command.
>
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: OF graph bindings modeling a data bus to the
> + DisplayPort altmode from the DisplayPort controller. Used when
> + the altmode switch is part of the port manager.
Well......
> +
> port:
> $ref: /schemas/graph.yaml#/properties/port
> description: OF graph bindings modeling a data bus to the connector, e.g.
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index ac89696fa649..63d506e88abb 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -98,9 +98,6 @@ properties:
>
> gpio-controller: true
>
> - typec:
> - $ref: /schemas/usb/google,cros-ec-typec.yaml#
> -
> ec-pwm:
> $ref: /schemas/pwm/google,cros-ec-pwm.yaml#
> deprecated: true
> @@ -163,6 +160,10 @@ patternProperties:
> type: object
> $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
>
> + "^typec(-[0-9])*$":
> + type: object
> + $ref: /schemas/usb/google,cros-ec-typec.yaml#
> +
> required:
> - compatible
>
> diff --git a/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml
> index 3272d0e01f7e..611345bbe884 100644
> --- a/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml
> @@ -26,6 +26,55 @@ properties:
> '#size-cells':
> const: 0
>
> + mux-gpios:
> + description: GPIOs indicating which way the DisplayPort mux is steered
> + minItems: 1
> + maxItems: 3
> +
> + no-hpd:
> + description: Indicates this device doesn't signal HPD for DisplayPort
> + type: boolean
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port at 0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Port for DisplayPort (DP) data
> +
> + properties:
> + endpoint at 0:
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Input DP port
> +
> + patternProperties:
> + '^endpoint@[1-8]$':
> + $ref: /schemas/graph.yaml#/properties/endpoint
> + description: Output to the usb-c connector's DP altmode
> +
> + required:
> + - endpoint at 0
> +
> + anyOf:
> + - required:
> + - endpoint at 1
> + - required:
> + - endpoint at 2
> + - required:
> + - endpoint at 3
> + - required:
> + - endpoint at 4
> + - required:
> + - endpoint at 5
> + - required:
> + - endpoint at 6
> + - required:
> + - endpoint at 7
> + - required:
> + - endpoint at 8
> +
> patternProperties:
> '^connector@[0-9a-f]+$':
> $ref: /schemas/connector/usb-connector.yaml#
> @@ -35,10 +84,30 @@ patternProperties:
> required:
> - compatible
>
> +allOf:
> + - if:
> + required:
> + - no-hpd
> + then:
> + properties:
> + ports:
> + required:
> + - port at 0
> + - if:
> + required:
> + - mux-gpios
> + then:
> + properties:
> + ports:
> + required:
> + - port at 0
> +
> additionalProperties: false
>
> examples:
> - |+
> + #include <dt-bindings/gpio/gpio.h>
> +
> spi {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -47,6 +116,8 @@ examples:
> compatible = "google,cros-ec-spi";
> reg = <0>;
> interrupts = <35 0>;
> + #gpio-cells = <2>;
> + gpio-controller;
>
> typec {
> compatible = "google,cros-ec-typec";
> @@ -54,12 +125,106 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> + mux-gpios = <&cros_ec 42 GPIO_ACTIVE_HIGH>, <&cros_ec 3 GPIO_ACTIVE_HIGH>;
> +
> connector at 0 {
> compatible = "usb-c-connector";
> reg = <0>;
> power-role = "dual";
> data-role = "dual";
> try-power-role = "source";
> +
> + altmodes {
> + displayport {
Should there be an svid / vdo definition?
> + port {
> + usbc0_dp: endpoint {
> + remote-endpoint = <&dp_out0>;
> + };
I think this is slightly incorrect. The lanes from the DP mux inside the
EC are routed to the SS part of the USB-C connector. As such...
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + usb_c0_hs: endpoint {
> + remote-endpoint = <&usb_hub_dfp3_hs>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + usb_c0_ss: endpoint {
> + remote-endpoint = <&usb_hub_dfp3_ss>;
> + };
This should be more like
port at 1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
usb_c0_ss: endpoint at 0 {
reg = <0>;
remote-endpoint = <&usb_hub_dfp3_ss>;
};
usbc0_dp: endpoint at 1 {
reg = <1>;
remote-endpoint = <&dp_out0>;
};
};
Would it make the driver significantly more complicated?
--
With best wishes
Dmitry
More information about the linux-arm-kernel
mailing list