[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <81b1e0b8-6a5b-4eb9-8f9d-fe9a52f0afcd@linaro.org>
Date: Tue, 2 Sep 2025 14:29:33 +0200
From: Neil Armstrong <neil.armstrong@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>, Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, dri-devel@...ts.freedesktop.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org
Subject: Re: [PATCH v2 3/5] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy:
Document static lanes mapping
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
Powered by blists - more mailing lists