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.armstr...@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-64ef277f7...@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-f6b41ac24...@linaro.org/
Neil
Best regards,
Krzysztof
