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
