[PATCH v2 3/5] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Document static lanes mapping
Neil Armstrong
neil.armstrong at linaro.org
Tue Sep 2 03:05:45 PDT 2025
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 at 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 at abcdef {
> ports {
> port at 1 {
> endpoint {
> remote-endpoint = <&&usb_1_dwc3_ss>;
> data-lanes = <2 3>;
> };
> };
>
> port at 2 {
> endpoint {
> remote-endpoint = <&mdss_dp0_out>;
> data-lanes = <1>;
> };
> };
> };
> };
>
> phy at cafecafe {
> ports {
> port at 1 {
> endpoint {
> remote-endpoint = <&&usb_1_dwc3_ss>;
> status = "disabled";
> };
> };
>
> port at 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 at 0 {
reg = <0>;
usb_con_hs: endpoint {
remote-endpoint = <&usb_1_ss2_dwc3_hs>;
};
};
port at 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 at 0{
#address-cells = <1>;
#size-cells = <0>;
/delete-node/ endpoint;
usb_1_ss2_qmpphy_usb3_out: endpoint at 0 {
reg = <0>;
remote-endpoint = <&usb_con_ss>;
data-lanes = <1 2 0 0>;
};
usb_1_ss2_qmpphy_dp_out: endpoint at 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
>>>>
>>>
>>
>
More information about the linux-phy
mailing list