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.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.
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
