The QMP USB3/DP Combo PHY hosts an USB3 phy and a DP PHY on top
of a combo glue to route either lanes to the 4 shared physical lanes.
The routing of the lanes can be:
- 2 DP + 2 USB3
- 4 DP
- 2 USB3
The layout of the lanes was designed to be mapped and swapped
related to the USB-C Power Delivery negociation, so it supports
a finite set of mappings inherited by the USB-C Altmode layouts.
Nevertheless those QMP Comby PHY can be used to drive a DisplayPort
connector, DP->HDMI bridge, USB3 A Connector, etc... without
an USB-C connector and no PD events.
Document the data-lanes on numbered port@0 out endpoints,
allowing us to document the lanes mapping to DisplayPort
and/or USB3 connectors/peripherals.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 67 +++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 5005514d7c3a1e4a8893883497fd204bc04e12be..ac9a307675bc4e86f7693ba260c75b7b88d992ec 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -81,10 +81,75 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: Output endpoint of the PHY
+ unevaluatedProperties: false
+
+ properties:
+ endpoint:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description: Display Port Output lanes of the PHY when used with static mapping,
+ The entry index is the DP lanes index, and the number is the PHY
+ signal in the order RX0, TX0, TX1, RX1.
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 4
+ oneOf:
+ - items: # DisplayPort 1 lane, normal orientation
+ - const: 3
+ - items: # DisplayPort 1 lane, flipped orientation
+ - const: 0
+ - items: # DisplayPort 2 lanes, normal orientation
+ - const: 3
+ - const: 2
+ - items: # DisplayPort 2 lanes, flipped orientation
+ - const: 0
+ - const: 1
+ - items: # DisplayPort 4 lanes, normal orientation
+ - const: 3
+ - const: 2
+ - const: 1
+ - const: 0
+ - items: # DisplayPort 4 lanes, flipped orientation
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+ required:
+ - data-lanes
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description: USB Output lanes of the PHY when used with static mapping.
+ The entry index is the USB3 lane in the order TX then RX, and the
+ number is the PHY signal in the order RX0, TX0, TX1, RX1.
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ oneOf:
+ - items: # USB3, normal orientation
+ - const: 1
+ - const: 0
+ - items: # USB3, flipped orientation
+ - const: 2
+ - const: 3
+
+ required:
+ - data-lanes
port@1:
$ref: /schemas/graph.yaml#/properties/port
--
2.34.1On 9/30/25 9:39 AM, Neil Armstrong wrote: > The QMP USB3/DP Combo PHY hosts an USB3 phy and a DP PHY on top > of a combo glue to route either lanes to the 4 shared physical lanes. > > The routing of the lanes can be: > - 2 DP + 2 USB3 > - 4 DP > - 2 USB3 > > The layout of the lanes was designed to be mapped and swapped > related to the USB-C Power Delivery negociation, so it supports > a finite set of mappings inherited by the USB-C Altmode layouts. > > Nevertheless those QMP Comby PHY can be used to drive a DisplayPort > connector, DP->HDMI bridge, USB3 A Connector, etc... without > an USB-C connector and no PD events. > > Document the data-lanes on numbered port@0 out endpoints, > allowing us to document the lanes mapping to DisplayPort > and/or USB3 connectors/peripherals. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- [...] > + endpoint@1: > + $ref: /schemas/graph.yaml#/$defs/endpoint-base > + description: USB Output lanes of the PHY when used with static mapping. > + The entry index is the USB3 lane in the order TX then RX, and the > + number is the PHY signal in the order RX0, TX0, TX1, RX1.> + unevaluatedProperties: false > + > + properties: > + data-lanes: Can this be described in a somewhat reasonable way to be non-compatible with Type-C properties for more validation? If not, let's just maybe add a comment like # Static lane mappings are mutually exclusive with typec-mux/orientation-mux Konrad
On 10/6/25 11:43, Konrad Dybcio wrote: > On 9/30/25 9:39 AM, Neil Armstrong wrote: >> The QMP USB3/DP Combo PHY hosts an USB3 phy and a DP PHY on top >> of a combo glue to route either lanes to the 4 shared physical lanes. >> >> The routing of the lanes can be: >> - 2 DP + 2 USB3 >> - 4 DP >> - 2 USB3 >> >> The layout of the lanes was designed to be mapped and swapped >> related to the USB-C Power Delivery negociation, so it supports >> a finite set of mappings inherited by the USB-C Altmode layouts. >> >> Nevertheless those QMP Comby PHY can be used to drive a DisplayPort >> connector, DP->HDMI bridge, USB3 A Connector, etc... without >> an USB-C connector and no PD events. >> >> Document the data-lanes on numbered port@0 out endpoints, >> allowing us to document the lanes mapping to DisplayPort >> and/or USB3 connectors/peripherals. >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> --- > > [...] > >> + endpoint@1: >> + $ref: /schemas/graph.yaml#/$defs/endpoint-base >> + description: USB Output lanes of the PHY when used with static mapping. >> + The entry index is the USB3 lane in the order TX then RX, and the >> + number is the PHY signal in the order RX0, TX0, TX1, RX1.> + unevaluatedProperties: false >> + >> + properties: >> + data-lanes: > > Can this be described in a somewhat reasonable way to be non-compatible > with Type-C properties for more validation? I tried, but failed. Let me try again ! > > If not, let's just maybe add a comment like > > # Static lane mappings are mutually exclusive with typec-mux/orientation-mux Ack Thanks, Neil > > Konrad
© 2016 - 2026 Red Hat, Inc.