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 <[email protected]> > > > > > --- > > > > > .../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
