Re: [PATCH v2 3/5] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Document static lanes mapping

[Neil Armstrong <neil.armstrong@linaro.org>]

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