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 statically used to
drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector,
etc... without an USB-C connector and no PD events.
Add a property that documents the static lanes mapping to
each underlying PHY to allow supporting boards directly
connecting USB3 and DisplayPort lanes to the QMP Combo
lanes.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -76,6 +76,35 @@ properties:
mode-switch: true
orientation-switch: true
+ qcom,static-lanes-mapping:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ items:
+ enum:
+ - 0 # Unconnected (PHY_NONE)
+ - 4 # USB3 (PHY_TYPE_USB3)
+ - 6 # DisplayPort (PHY_TYPE_DP)
+ description:
+ Describes the static mapping of the Combo PHY lanes, when not used
+ a in a Type-C dynamic setup using USB-C PD Events to change the mapping.
+ The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY.
+ Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can
+ be connected to the DP PHY.
+ The numbers corresponds to the PHY Type the lanes are connected to.
+ The possible combinations are
+ <0 0 0 0> when none are connected
+ <4 4 0 6> USB3 and DP single lane
+ <4 4 6 6> USB3 and DP
+ <6 6 4 4> DP and USB3
+ <6 0 4 4> DP and USB3 single lane
+ <4 4 0 0> USB3 Only
+ <0 0 4 4> USB3 Only
+ <6 0 0 0> DP single lane
+ <0 0 0 6> DP single lane
+ <6 6 0 0> DP 2 lanes
+ <0 0 6 6> DP 2 lanes
+ <6 6 6 6> DP 4 lanes
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
--
2.34.1On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to > drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector, > etc... without an USB-C connector and no PD events. What is the use case for static mapping? Embedded HDMI port on T14s laptop? > > Add a property that documents the static lanes mapping to > each underlying PHY to allow supporting boards directly > connecting USB3 and DisplayPort lanes to the QMP Combo > lanes. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- > .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml > @@ -76,6 +76,35 @@ properties: > mode-switch: true > orientation-switch: true > > + qcom,static-lanes-mapping: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 4 > + items: > + enum: > + - 0 # Unconnected (PHY_NONE) > + - 4 # USB3 (PHY_TYPE_USB3) > + - 6 # DisplayPort (PHY_TYPE_DP) > + description: > + Describes the static mapping of the Combo PHY lanes, when not used > + a in a Type-C dynamic setup using USB-C PD Events to change the mapping. > + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY. > + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can > + be connected to the DP PHY. > + The numbers corresponds to the PHY Type the lanes are connected to. > + The possible combinations are > + <0 0 0 0> when none are connected > + <4 4 0 6> USB3 and DP single lane > + <4 4 6 6> USB3 and DP > + <6 6 4 4> DP and USB3 > + <6 0 4 4> DP and USB3 single lane > + <4 4 0 0> USB3 Only > + <0 0 4 4> USB3 Only Why do you need to handle here and in few other places mirrored case? Isn't enough to just say you only want USB3? Maybe my first question (what is usecase for this) answers this, though. This looks similar to rockchip,dp-lane-mux, from the objective point of view. Please look there and if it is really similar concept this would warrant having it as generic property in video-interfaces for example. I also wonder if this should not be stored in the endpoint. Best regards, Krzysztof
On 03/09/2025 09:07, Krzysztof Kozlowski wrote: > On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to >> drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector, >> etc... without an USB-C connector and no PD events. > > What is the use case for static mapping? Embedded HDMI port on T14s > laptop? > >> >> Add a property that documents the static lanes mapping to >> each underlying PHY to allow supporting boards directly >> connecting USB3 and DisplayPort lanes to the QMP Combo >> lanes. >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> --- >> .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++ >> 1 file changed, 29 insertions(+) >> >> 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644 >> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml >> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml >> @@ -76,6 +76,35 @@ properties: >> mode-switch: true >> orientation-switch: true >> >> + qcom,static-lanes-mapping: >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 4 >> + items: >> + enum: >> + - 0 # Unconnected (PHY_NONE) >> + - 4 # USB3 (PHY_TYPE_USB3) >> + - 6 # DisplayPort (PHY_TYPE_DP) >> + description: >> + Describes the static mapping of the Combo PHY lanes, when not used >> + a in a Type-C dynamic setup using USB-C PD Events to change the mapping. >> + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY. >> + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can >> + be connected to the DP PHY. >> + The numbers corresponds to the PHY Type the lanes are connected to. >> + The possible combinations are >> + <0 0 0 0> when none are connected >> + <4 4 0 6> USB3 and DP single lane >> + <4 4 6 6> USB3 and DP >> + <6 6 4 4> DP and USB3 >> + <6 0 4 4> DP and USB3 single lane > >> + <4 4 0 0> USB3 Only >> + <0 0 4 4> USB3 Only > > Why do you need to handle here and in few other places mirrored case? > Isn't enough to just say you only want USB3? Maybe my first question > (what is usecase for this) answers this, though. Usecase is larger than the HDMI on the T14s, we must handle boards directly connected some USB-A and DP stuff directly on the combo lanes. See https://lore.kernel.org/all/8A7C126C22789C9B+f30def47-302a-45ee-8f76-64ef277f773f@radxa.com/ > > This looks similar to rockchip,dp-lane-mux, from the objective point of > view. Please look there and if it is really similar concept this would > warrant having it as generic property in video-interfaces for example. Yes it's quite the same > > I also wonder if this should not be stored in the endpoint. But I'm trying to store this in the endpoint as [1], the Bindings & DT part looks fine, but the driver part looks horrible... I'll probably post an RFC of that shortly [1] https://lore.kernel.org/all/14f334fc-35de-4f21-8eb1-f6b41ac24704@linaro.org/ Neil > > Best regards, > Krzysztof >
On 9/2/25 11:00 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 statically used to > drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector, > etc... without an USB-C connector and no PD events. > > Add a property that documents the static lanes mapping to > each underlying PHY to allow supporting boards directly > connecting USB3 and DisplayPort lanes to the QMP Combo > lanes. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- > .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml > @@ -76,6 +76,35 @@ properties: > mode-switch: true > orientation-switch: true > > + qcom,static-lanes-mapping: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 4 > + items: > + enum: > + - 0 # Unconnected (PHY_NONE) > + - 4 # USB3 (PHY_TYPE_USB3) > + - 6 # DisplayPort (PHY_TYPE_DP) > + description: > + Describes the static mapping of the Combo PHY lanes, when not used > + a in a Type-C dynamic setup using USB-C PD Events to change the mapping. > + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY. > + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can > + be connected to the DP PHY. > + The numbers corresponds to the PHY Type the lanes are connected to. > + The possible combinations are > + <0 0 0 0> when none are connected > + <4 4 0 6> USB3 and DP single lane > + <4 4 6 6> USB3 and DP > + <6 6 4 4> DP and USB3 > + <6 0 4 4> DP and USB3 single lane > + <4 4 0 0> USB3 Only > + <0 0 4 4> USB3 Only > + <6 0 0 0> DP single lane > + <0 0 0 6> DP single lane > + <6 6 0 0> DP 2 lanes > + <0 0 6 6> DP 2 lanes > + <6 6 6 6> DP 4 lanes Would oneOf: - [0, 0, 0, 0] - ... or something similar work here? Konrad
On 02/09/2025 13:50, Konrad Dybcio wrote:
> On 9/2/25 11:00 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 statically used to
>> drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector,
>> etc... without an USB-C connector and no PD events.
>>
>> Add a property that documents the static lanes mapping to
>> each underlying PHY to allow supporting boards directly
>> connecting USB3 and DisplayPort lanes to the QMP Combo
>> lanes.
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644
>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
>> @@ -76,6 +76,35 @@ properties:
>> mode-switch: true
>> orientation-switch: true
>>
>> + qcom,static-lanes-mapping:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 4
>> + items:
>> + enum:
>> + - 0 # Unconnected (PHY_NONE)
>> + - 4 # USB3 (PHY_TYPE_USB3)
>> + - 6 # DisplayPort (PHY_TYPE_DP)
>> + description:
>> + Describes the static mapping of the Combo PHY lanes, when not used
>> + a in a Type-C dynamic setup using USB-C PD Events to change the mapping.
>> + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY.
>> + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can
>> + be connected to the DP PHY.
>> + The numbers corresponds to the PHY Type the lanes are connected to.
>> + The possible combinations are
>> + <0 0 0 0> when none are connected
>> + <4 4 0 6> USB3 and DP single lane
>> + <4 4 6 6> USB3 and DP
>> + <6 6 4 4> DP and USB3
>> + <6 0 4 4> DP and USB3 single lane
>> + <4 4 0 0> USB3 Only
>> + <0 0 4 4> USB3 Only
>> + <6 0 0 0> DP single lane
>> + <0 0 0 6> DP single lane
>> + <6 6 0 0> DP 2 lanes
>> + <0 0 6 6> DP 2 lanes
>> + <6 6 6 6> DP 4 lanes
>
> Would
>
> oneOf:
> - [0, 0, 0, 0]
> - ...
>
> or something similar work here?
I need to check, but I may need to do that instead:
oneOf:
- items:
- 0
- 0
- 0
- 0
- items:
- 4
- 4
- 6
- 6
...
But I want to be extra sure this is the right path before
Neil
>
> Konrad
On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to > drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector, > etc... without an USB-C connector and no PD events. > > Add a property that documents the static lanes mapping to > each underlying PHY to allow supporting boards directly > connecting USB3 and DisplayPort lanes to the QMP Combo > lanes. > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > --- > .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml > @@ -76,6 +76,35 @@ properties: > mode-switch: true > orientation-switch: true > > + qcom,static-lanes-mapping: > + $ref: /schemas/types.yaml#/definitions/uint32-array > + minItems: 4 > + items: > + enum: > + - 0 # Unconnected (PHY_NONE) > + - 4 # USB3 (PHY_TYPE_USB3) > + - 6 # DisplayPort (PHY_TYPE_DP) > + description: > + Describes the static mapping of the Combo PHY lanes, when not used > + a in a Type-C dynamic setup using USB-C PD Events to change the mapping. > + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY. > + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can > + be connected to the DP PHY. It feels like this significantly duplicates existing data-lanes definitions. Can we use that property to express the same semantics? > + The numbers corresponds to the PHY Type the lanes are connected to. > + The possible combinations are > + <0 0 0 0> when none are connected > + <4 4 0 6> USB3 and DP single lane > + <4 4 6 6> USB3 and DP > + <6 6 4 4> DP and USB3 > + <6 0 4 4> DP and USB3 single lane > + <4 4 0 0> USB3 Only > + <0 0 4 4> USB3 Only > + <6 0 0 0> DP single lane > + <0 0 0 6> DP single lane > + <6 6 0 0> DP 2 lanes > + <0 0 6 6> DP 2 lanes > + <6 6 6 6> DP 4 lanes > + > ports: > $ref: /schemas/graph.yaml#/properties/ports > properties: > > -- > 2.34.1 > -- With best wishes Dmitry
On 02/09/2025 11:30, Dmitry Baryshkov wrote: > On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to >> drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector, >> etc... without an USB-C connector and no PD events. >> >> Add a property that documents the static lanes mapping to >> each underlying PHY to allow supporting boards directly >> connecting USB3 and DisplayPort lanes to the QMP Combo >> lanes. >> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> >> --- >> .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++ >> 1 file changed, 29 insertions(+) >> >> 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644 >> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml >> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml >> @@ -76,6 +76,35 @@ properties: >> mode-switch: true >> orientation-switch: true >> >> + qcom,static-lanes-mapping: >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + minItems: 4 >> + items: >> + enum: >> + - 0 # Unconnected (PHY_NONE) >> + - 4 # USB3 (PHY_TYPE_USB3) >> + - 6 # DisplayPort (PHY_TYPE_DP) >> + description: >> + Describes the static mapping of the Combo PHY lanes, when not used >> + a in a Type-C dynamic setup using USB-C PD Events to change the mapping. >> + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY. >> + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can >> + be connected to the DP PHY. > > It feels like this significantly duplicates existing data-lanes > definitions. Can we use that property to express the same semantics? Well yes it has the same semantics, but not really the same meaning. data-lanes is designed to describes the lanes layout/ordering, not the type/mapping. Here, we do not describe the ordering, i.e which source lane is connected to which endpoint splot, but which lane is supposed to connect to which internal PHY. Anyway, I'm open to suggestions. Neil > > >> + The numbers corresponds to the PHY Type the lanes are connected to. >> + The possible combinations are >> + <0 0 0 0> when none are connected >> + <4 4 0 6> USB3 and DP single lane >> + <4 4 6 6> USB3 and DP >> + <6 6 4 4> DP and USB3 >> + <6 0 4 4> DP and USB3 single lane >> + <4 4 0 0> USB3 Only >> + <0 0 4 4> USB3 Only >> + <6 0 0 0> DP single lane >> + <0 0 0 6> DP single lane >> + <6 6 0 0> DP 2 lanes >> + <0 0 6 6> DP 2 lanes >> + <6 6 6 6> DP 4 lanes >> + >> ports: >> $ref: /schemas/graph.yaml#/properties/ports >> properties: >> >> -- >> 2.34.1 >> >
On Tue, Sep 02, 2025 at 11:35:25AM +0200, Neil Armstrong wrote:
> On 02/09/2025 11:30, Dmitry Baryshkov wrote:
> > On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to
> > > drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector,
> > > etc... without an USB-C connector and no PD events.
> > >
> > > Add a property that documents the static lanes mapping to
> > > each underlying PHY to allow supporting boards directly
> > > connecting USB3 and DisplayPort lanes to the QMP Combo
> > > lanes.
> > >
> > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> > > ---
> > > .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++
> > > 1 file changed, 29 insertions(+)
> > >
> > > 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644
> > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > @@ -76,6 +76,35 @@ properties:
> > > mode-switch: true
> > > orientation-switch: true
> > > + qcom,static-lanes-mapping:
> > > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > > + minItems: 4
> > > + items:
> > > + enum:
> > > + - 0 # Unconnected (PHY_NONE)
> > > + - 4 # USB3 (PHY_TYPE_USB3)
> > > + - 6 # DisplayPort (PHY_TYPE_DP)
> > > + description:
> > > + Describes the static mapping of the Combo PHY lanes, when not used
> > > + a in a Type-C dynamic setup using USB-C PD Events to change the mapping.
> > > + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY.
> > > + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can
> > > + be connected to the DP PHY.
> >
> > It feels like this significantly duplicates existing data-lanes
> > definitions. Can we use that property to express the same semantics?
>
> Well yes it has the same semantics, but not really the same meaning. data-lanes is designed
> to describes the lanes layout/ordering, not the type/mapping.
>
> Here, we do not describe the ordering, i.e which source lane is connected to which endpoint splot,
> but which lane is supposed to connect to which internal PHY.
>
> Anyway, I'm open to suggestions.
phy@abcdef {
ports {
port@1 {
endpoint {
remote-endpoint = <&&usb_1_dwc3_ss>;
data-lanes = <2 3>;
};
};
port@2 {
endpoint {
remote-endpoint = <&mdss_dp0_out>;
data-lanes = <1>;
};
};
};
};
phy@cafecafe {
ports {
port@1 {
endpoint {
remote-endpoint = <&&usb_1_dwc3_ss>;
status = "disabled";
};
};
port@2 {
endpoint {
remote-endpoint = <&mdss_dp0_out>;
data-lanes = <2 3 0 1>;
};
};
};
};
>
> Neil
>
> >
> >
> > > + The numbers corresponds to the PHY Type the lanes are connected to.
> > > + The possible combinations are
> > > + <0 0 0 0> when none are connected
> > > + <4 4 0 6> USB3 and DP single lane
> > > + <4 4 6 6> USB3 and DP
> > > + <6 6 4 4> DP and USB3
> > > + <6 0 4 4> DP and USB3 single lane
> > > + <4 4 0 0> USB3 Only
> > > + <0 0 4 4> USB3 Only
> > > + <6 0 0 0> DP single lane
> > > + <0 0 0 6> DP single lane
> > > + <6 6 0 0> DP 2 lanes
> > > + <0 0 6 6> DP 2 lanes
> > > + <6 6 6 6> DP 4 lanes
> > > +
> > > ports:
> > > $ref: /schemas/graph.yaml#/properties/ports
> > > properties:
> > >
> > > --
> > > 2.34.1
> > >
> >
>
--
With best wishes
Dmitry
On 02/09/2025 11:46, Dmitry Baryshkov wrote:
> On Tue, Sep 02, 2025 at 11:35:25AM +0200, Neil Armstrong wrote:
>> On 02/09/2025 11:30, Dmitry Baryshkov wrote:
>>> On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to
>>>> drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector,
>>>> etc... without an USB-C connector and no PD events.
>>>>
>>>> Add a property that documents the static lanes mapping to
>>>> each underlying PHY to allow supporting boards directly
>>>> connecting USB3 and DisplayPort lanes to the QMP Combo
>>>> lanes.
>>>>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>>> ---
>>>> .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++
>>>> 1 file changed, 29 insertions(+)
>>>>
>>>> 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644
>>>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
>>>> @@ -76,6 +76,35 @@ properties:
>>>> mode-switch: true
>>>> orientation-switch: true
>>>> + qcom,static-lanes-mapping:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> + minItems: 4
>>>> + items:
>>>> + enum:
>>>> + - 0 # Unconnected (PHY_NONE)
>>>> + - 4 # USB3 (PHY_TYPE_USB3)
>>>> + - 6 # DisplayPort (PHY_TYPE_DP)
>>>> + description:
>>>> + Describes the static mapping of the Combo PHY lanes, when not used
>>>> + a in a Type-C dynamic setup using USB-C PD Events to change the mapping.
>>>> + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY.
>>>> + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can
>>>> + be connected to the DP PHY.
>>>
>>> It feels like this significantly duplicates existing data-lanes
>>> definitions. Can we use that property to express the same semantics?
>>
>> Well yes it has the same semantics, but not really the same meaning. data-lanes is designed
>> to describes the lanes layout/ordering, not the type/mapping.
>>
>> Here, we do not describe the ordering, i.e which source lane is connected to which endpoint splot,
>> but which lane is supposed to connect to which internal PHY.
>>
>> Anyway, I'm open to suggestions.
>
> phy@abcdef {
> ports {
> port@1 {
> endpoint {
> remote-endpoint = <&&usb_1_dwc3_ss>;
> data-lanes = <2 3>;
> };
> };
>
> port@2 {
> endpoint {
> remote-endpoint = <&mdss_dp0_out>;
> data-lanes = <1>;
> };
> };
> };
> };
>
> phy@cafecafe {
> ports {
> port@1 {
> endpoint {
> remote-endpoint = <&&usb_1_dwc3_ss>;
> status = "disabled";
> };
> };
>
> port@2 {
> endpoint {
> remote-endpoint = <&mdss_dp0_out>;
> data-lanes = <2 3 0 1>;
> };
> };
> };
> };
This is wrong, those are the internal connections to the controllers,
those are fixed. I'm speaking about the external lanes, but there's only
a single port.
So, following your suggestion, we should use the Output port 0, but as it's
only a single port it would need to have 2 endpoints, one for USB3 and one for
DP.
For example:
\{
dp-connector {
compatible = "dp-connector";
type = "a";
port {
dp_con: endpoint {
remote-endpoint = <&usb_1_ss2_qmpphy_dp_out>;
};
};
};
usb-a-connector {
compatible = "usb-a-connector";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
usb_con_hs: endpoint {
remote-endpoint = <&usb_1_ss2_dwc3_hs>;
};
};
port@1 {
reg = <1>;
usb_con_ss: endpoint {
remote-endpoint = <&usb_1_ss2_qmpphy_usb3_out>;
};
};
};
};
};
&usb_1_ss2_dwc3_hs {
remote-endpoint = <&usb_1_ss2_dwc3_hs>;
};
&usb_1_ss2_qmpphy {
/delete-property/ mode-switch;
/delete-property/ orientation-switch;
ports {
port@0{
#address-cells = <1>;
#size-cells = <0>;
/delete-node/ endpoint;
usb_1_ss2_qmpphy_usb3_out: endpoint@0 {
reg = <0>;
remote-endpoint = <&usb_con_ss>;
data-lanes = <1 2 0 0>;
};
usb_1_ss2_qmpphy_dp_out: endpoint@1 {
reg = <1>;
remote-endpoint = <&dp_con>;
data-lanes = <0 0 1 2>;
};
};
};
};
So the driver logic would need to look at the port0/endpoint0 and port0/endpoint1
data-lanes to figure out the mode.
Is this what you were thinking ?
Neil
>
>
>>
>> Neil
>>
>>>
>>>
>>>> + The numbers corresponds to the PHY Type the lanes are connected to.
>>>> + The possible combinations are
>>>> + <0 0 0 0> when none are connected
>>>> + <4 4 0 6> USB3 and DP single lane
>>>> + <4 4 6 6> USB3 and DP
>>>> + <6 6 4 4> DP and USB3
>>>> + <6 0 4 4> DP and USB3 single lane
>>>> + <4 4 0 0> USB3 Only
>>>> + <0 0 4 4> USB3 Only
>>>> + <6 0 0 0> DP single lane
>>>> + <0 0 0 6> DP single lane
>>>> + <6 6 0 0> DP 2 lanes
>>>> + <0 0 6 6> DP 2 lanes
>>>> + <6 6 6 6> DP 4 lanes
>>>> +
>>>> ports:
>>>> $ref: /schemas/graph.yaml#/properties/ports
>>>> properties:
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
>
On Tue, Sep 02, 2025 at 12:05:45PM +0200, Neil Armstrong wrote:
> On 02/09/2025 11:46, Dmitry Baryshkov wrote:
> > On Tue, Sep 02, 2025 at 11:35:25AM +0200, Neil Armstrong wrote:
> > > On 02/09/2025 11:30, Dmitry Baryshkov wrote:
> > > > On Tue, Sep 02, 2025 at 11:00:30AM +0200, 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 statically used to
> > > > > drive a DisplayPort connector, DP->HDMI bridge, USB3 A Connector,
> > > > > etc... without an USB-C connector and no PD events.
> > > > >
> > > > > Add a property that documents the static lanes mapping to
> > > > > each underlying PHY to allow supporting boards directly
> > > > > connecting USB3 and DisplayPort lanes to the QMP Combo
> > > > > lanes.
> > > > >
> > > > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> > > > > ---
> > > > > .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 29 ++++++++++++++++++++++
> > > > > 1 file changed, 29 insertions(+)
> > > > >
> > > > > 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 c8bc512df08b5694c8599f475de78679a4438449..12511a462bc6245e0b82726d053d8605148c5047 100644
> > > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> > > > > @@ -76,6 +76,35 @@ properties:
> > > > > mode-switch: true
> > > > > orientation-switch: true
> > > > > + qcom,static-lanes-mapping:
> > > > > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > + minItems: 4
> > > > > + items:
> > > > > + enum:
> > > > > + - 0 # Unconnected (PHY_NONE)
> > > > > + - 4 # USB3 (PHY_TYPE_USB3)
> > > > > + - 6 # DisplayPort (PHY_TYPE_DP)
> > > > > + description:
> > > > > + Describes the static mapping of the Combo PHY lanes, when not used
> > > > > + a in a Type-C dynamic setup using USB-C PD Events to change the mapping.
> > > > > + The 4 lanes can either routed to the underlying DP PHY or the USB3 PHY.
> > > > > + Only 2 of the lanes can be connected to the USB3 PHY, but the 4 lanes can
> > > > > + be connected to the DP PHY.
> > > >
> > > > It feels like this significantly duplicates existing data-lanes
> > > > definitions. Can we use that property to express the same semantics?
> > >
> > > Well yes it has the same semantics, but not really the same meaning. data-lanes is designed
> > > to describes the lanes layout/ordering, not the type/mapping.
> > >
> > > Here, we do not describe the ordering, i.e which source lane is connected to which endpoint splot,
> > > but which lane is supposed to connect to which internal PHY.
> > >
> > > Anyway, I'm open to suggestions.
> >
> > phy@abcdef {
> > ports {
> > port@1 {
> > endpoint {
> > remote-endpoint = <&&usb_1_dwc3_ss>;
> > data-lanes = <2 3>;
> > };
> > };
> >
> > port@2 {
> > endpoint {
> > remote-endpoint = <&mdss_dp0_out>;
> > data-lanes = <1>;
> > };
> > };
> > };
> > };
> >
> > phy@cafecafe {
> > ports {
> > port@1 {
> > endpoint {
> > remote-endpoint = <&&usb_1_dwc3_ss>;
> > status = "disabled";
> > };
> > };
> >
> > port@2 {
> > endpoint {
> > remote-endpoint = <&mdss_dp0_out>;
> > data-lanes = <2 3 0 1>;
> > };
> > };
> > };
> > };
>
> This is wrong, those are the internal connections to the controllers,
> those are fixed. I'm speaking about the external lanes, but there's only
> a single port.
>
> So, following your suggestion, we should use the Output port 0, but as it's
> only a single port it would need to have 2 endpoints, one for USB3 and one for
> DP.
>
> For example:
>
> \{
> dp-connector {
> compatible = "dp-connector";
> type = "a";
>
> port {
> dp_con: endpoint {
> remote-endpoint = <&usb_1_ss2_qmpphy_dp_out>;
> };
> };
> };
>
> usb-a-connector {
> compatible = "usb-a-connector";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> usb_con_hs: endpoint {
> remote-endpoint = <&usb_1_ss2_dwc3_hs>;
> };
> };
>
> port@1 {
> reg = <1>;
> usb_con_ss: endpoint {
> remote-endpoint = <&usb_1_ss2_qmpphy_usb3_out>;
> };
> };
> };
> };
>
> };
>
> &usb_1_ss2_dwc3_hs {
> remote-endpoint = <&usb_1_ss2_dwc3_hs>;
> };
>
> &usb_1_ss2_qmpphy {
> /delete-property/ mode-switch;
> /delete-property/ orientation-switch;
>
> ports {
>
> port@0{
> #address-cells = <1>;
> #size-cells = <0>;
>
> /delete-node/ endpoint;
>
> usb_1_ss2_qmpphy_usb3_out: endpoint@0 {
> reg = <0>;
>
> remote-endpoint = <&usb_con_ss>;
>
> data-lanes = <1 2 0 0>;
> };
>
> usb_1_ss2_qmpphy_dp_out: endpoint@1 {
> reg = <1>;
>
> remote-endpoint = <&dp_con>;
>
> data-lanes = <0 0 1 2>;
> };
> };
> };
> };
>
> So the driver logic would need to look at the port0/endpoint0 and port0/endpoint1
> data-lanes to figure out the mode.
>
> Is this what you were thinking ?
No, I was really thinking about the data-lanes in the PHY parts, so I
was incorrect there (which is incrrect as you've pointed out).
The endpoints approach looks interesting though.
--
With best wishes
Dmitry
On 02/09/2025 14:22, Dmitry Baryshkov wrote:
> On Tue, Sep 02, 2025 at 12:05:45PM +0200, Neil Armstrong wrote:
>> On 02/09/2025 11:46, Dmitry Baryshkov wrote:
<snip>
>>
>> This is wrong, those are the internal connections to the controllers,
>> those are fixed. I'm speaking about the external lanes, but there's only
>> a single port.
>>
>> So, following your suggestion, we should use the Output port 0, but as it's
>> only a single port it would need to have 2 endpoints, one for USB3 and one for
>> DP.
>>
>> For example:
>>
>> \{
>> dp-connector {
>> compatible = "dp-connector";
>> type = "a";
>>
>> port {
>> dp_con: endpoint {
>> remote-endpoint = <&usb_1_ss2_qmpphy_dp_out>;
>> };
>> };
>> };
>>
>> usb-a-connector {
>> compatible = "usb-a-connector";
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> reg = <0>;
>> usb_con_hs: endpoint {
>> remote-endpoint = <&usb_1_ss2_dwc3_hs>;
>> };
>> };
>>
>> port@1 {
>> reg = <1>;
>> usb_con_ss: endpoint {
>> remote-endpoint = <&usb_1_ss2_qmpphy_usb3_out>;
>> };
>> };
>> };
>> };
>>
>> };
>>
>> &usb_1_ss2_dwc3_hs {
>> remote-endpoint = <&usb_1_ss2_dwc3_hs>;
>> };
>>
>> &usb_1_ss2_qmpphy {
>> /delete-property/ mode-switch;
>> /delete-property/ orientation-switch;
>>
>> ports {
>>
>> port@0{
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> /delete-node/ endpoint;
>>
>> usb_1_ss2_qmpphy_usb3_out: endpoint@0 {
>> reg = <0>;
>>
>> remote-endpoint = <&usb_con_ss>;
>>
>> data-lanes = <1 2 0 0>;
>> };
>>
>> usb_1_ss2_qmpphy_dp_out: endpoint@1 {
>> reg = <1>;
>>
>> remote-endpoint = <&dp_con>;
>>
>> data-lanes = <0 0 1 2>;
>> };
>> };
>> };
>> };
>>
>> So the driver logic would need to look at the port0/endpoint0 and port0/endpoint1
>> data-lanes to figure out the mode.
>>
>> Is this what you were thinking ?
>
> No, I was really thinking about the data-lanes in the PHY parts, so I
> was incorrect there (which is incrrect as you've pointed out).
>
> The endpoints approach looks interesting though.
>
Indeed this would accurately describe the data flow and lane mapping, but
I fear this would add a very complex logic in the driver.
Anyway I'll try to drop something.
Neil
© 2016 - 2025 Red Hat, Inc.