[PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[Mahadevan P]

This series enables full 4-lane DisplayPort operation on SC7280/kodiak
platforms by wiring up the QMP Combo PHY correctly and consolidating
the DP endpoint configuration in the SoC dtsi.

Patch 1 adds mode-switch to the QMP Combo PHY node in kodiak.dtsi,
which is required for the PHY to respond to USB-C Alternate Mode
negotiation and switch into 4-lane DP configuration.

Patch 2 moves the data-lanes property from individual board files into
kodiak.dtsi since the PHY-to-controller wiring is fixed in silicon.
It also removes redundant remote-endpoint and orientation-switch
overrides from qcs6490-rb3gen2 and qcs6490-thundercomm-rubikpi3 that
are already covered by the SoC dtsi.

Patch 3 updates data-lanes from <0 1> to <0 1 2 3> in kodiak.dtsi now
that mode-switch is in place, enabling the full 4-lane DP link.

Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
---
Changes in v2:
- Split single patch into 3 patches.
- Move mode-switch and data-lanes to kodiak.dtsi instead of board
  file (Neil Armstrong, Konrad Dybcio)
- Remove redundant board-level endpoint and orientation-switch
  overrides now covered by kodiak.dtsi
- v1 received a Reviewed-by from Dmitry on the combined change;
  that tag has been dropped pending re-review of the split.

---
Mahadevan P (3):
      arm64: dts: qcom: kodiak: allow mode-switch events to reach the QMP Combo PHY
      arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi
      arm64: dts: qcom: kodiak: Set up 4-lane DP

 arch/arm64/boot/dts/qcom/kodiak.dtsi                          |  2 ++
 arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts            |  4 ----
 arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts         |  4 ----
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts                  | 11 -----------
 arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts |  1 -
 arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts     |  3 ---
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi                |  1 -
 7 files changed, 2 insertions(+), 24 deletions(-)
---
base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
change-id: 20260420-kodiak_v2-d7a06d50db5e

Best regards,
-- 
Mahadevan P <mahadevan.p@oss.qualcomm.com>

[PATCH v2 1/3] arm64: dts: qcom: kodiak: allow mode-switch events to reach the QMP Combo PHY

[Mahadevan P]

From: Mahadevan P <mahap@qti.qualcomm.com>

Allow mode-switch events to reach the QMP Combo PHY to support
setting the QMP Combo PHY in DP 4Lanes Altmode.

Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..96ac3656ab5a 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -4320,6 +4320,7 @@ usb_1_qmpphy: phy@88e8000 {
 			#clock-cells = <1>;
 			#phy-cells = <1>;
 
+			mode-switch;
 			orientation-switch;
 
 			ports {

-- 
2.34.1

[PATCH v2 2/3] arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi

[Mahadevan P]

From: Mahadevan P <mahap@qti.qualcomm.com>

The connection between the QMP Combo PHY and the DisplayPort controller
is fixed in SoC, so move the data-lanes property to kodiak.dtsi and
drop the per-board overrides.

Also remove the redundant remote-endpoint cross-links and
orientation-switch property from qcs6490-rb3gen2 and
qcs6490-thundercomm-rubikpi3, which are already defined in kodiak.dtsi.

Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi                          |  1 +
 arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts            |  4 ----
 arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts         |  4 ----
 arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts                  | 11 -----------
 arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts |  1 -
 arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts     |  3 ---
 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi                |  1 -
 7 files changed, 1 insertion(+), 24 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 96ac3656ab5a..0acc6917d7aa 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -5704,6 +5704,7 @@ dp_in: endpoint {
 					port@1 {
 						reg = <1>;
 						mdss_dp_out: endpoint {
+							data-lanes = <0 1>;
 							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
 						};
 					};
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 04cb9230d29f..9fe09968768a 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -932,10 +932,6 @@ &mdss_dp {
 	status = "okay";
 };
 
-&mdss_dp_out {
-	data-lanes = <0 1>;
-};
-
 &mdss_dsi {
 	vdda-supply = <&vreg_l6b>;
 	status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts b/arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts
index bf18c4852081..5a019501437a 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts
@@ -540,10 +540,6 @@ &mdss_dp {
 	status = "okay";
 };
 
-&mdss_dp_out {
-	data-lanes = <0 1>;
-};
-
 &pcie0 {
 	perst-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
 	wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index e393ccf1884a..9f76c95af4bc 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -788,11 +788,6 @@ &mdss_dp {
 	status = "okay";
 };
 
-&mdss_dp_out {
-	data-lanes = <0 1>;
-	remote-endpoint = <&usb_dp_qmpphy_dp_in>;
-};
-
 &mdss_dsi {
 	vdda-supply = <&vreg_l6b_1p2>;
 	status = "okay";
@@ -1391,8 +1386,6 @@ &usb_1_qmpphy {
 	vdda-phy-supply = <&vreg_l6b_1p2>;
 	vdda-pll-supply = <&vreg_l1b_0p912>;
 
-	orientation-switch;
-
 	status = "okay";
 };
 
@@ -1404,10 +1397,6 @@ &usb_dp_qmpphy_usb_ss_in {
 	remote-endpoint = <&usb_1_dwc3_ss>;
 };
 
-&usb_dp_qmpphy_dp_in {
-	remote-endpoint = <&mdss_dp_out>;
-};
-
 &ufs_mem_hc {
 	reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
 	vcc-supply = <&vreg_l7b_2p952>;
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts
index a5ad796cb65d..a120f7c5cfa5 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts
@@ -662,7 +662,6 @@ &mdss_dp {
 };
 
 &mdss_dp_out {
-	data-lanes = <0 1>;
 	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
 };
 
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
index f47efca42d48..d33f8aa38b13 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
@@ -788,10 +788,7 @@ &mdss_dp {
 };
 
 &mdss_dp_out {
-	data-lanes = <0 1>;
 	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
-
-	remote-endpoint = <&usb_dp_qmpphy_dp_in>;
 };
 
 &mdss_dsi {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 5c5e4f1dd221..504c3615f7ac 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -463,7 +463,6 @@ &mdss_dp {
 };
 
 &mdss_dp_out {
-	data-lanes = <0 1>;
 	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
 };
 

-- 
2.34.1

[PATCH v2 3/3] arm64: dts: qcom: kodiak: Set up 4-lane DP

[Mahadevan P]

From: Mahadevan P <mahap@qti.qualcomm.com>

Allow up to 4 lanes for the DisplayPort link from the PHY to the
controller now the mode-switch events can reach the QMP Combo PHY.

Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 0acc6917d7aa..204513a6bd89 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -5704,7 +5704,7 @@ dp_in: endpoint {
 					port@1 {
 						reg = <1>;
 						mdss_dp_out: endpoint {
-							data-lanes = <0 1>;
+							data-lanes = <0 1 2 3>;
 							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
 						};
 					};

-- 
2.34.1

Re: [PATCH v2 1/3] arm64: dts: qcom: kodiak: allow mode-switch events to reach the QMP Combo PHY

[Konrad Dybcio]

On 4/29/26 8:40 AM, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
> 
> Allow mode-switch events to reach the QMP Combo PHY to support
> setting the QMP Combo PHY in DP 4Lanes Altmode.
> 
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[Bjorn Andersson]

On Wed, Apr 29, 2026 at 12:10:39PM +0530, Mahadevan P wrote:
> This series enables full 4-lane DisplayPort operation on SC7280/kodiak
> platforms by wiring up the QMP Combo PHY correctly and consolidating
> the DP endpoint configuration in the SoC dtsi.
> 
> Patch 1 adds mode-switch to the QMP Combo PHY node in kodiak.dtsi,
> which is required for the PHY to respond to USB-C Alternate Mode
> negotiation and switch into 4-lane DP configuration.
> 
> Patch 2 moves the data-lanes property from individual board files into
> kodiak.dtsi since the PHY-to-controller wiring is fixed in silicon.
> It also removes redundant remote-endpoint and orientation-switch
> overrides from qcs6490-rb3gen2 and qcs6490-thundercomm-rubikpi3 that
> are already covered by the SoC dtsi.
> 
> Patch 3 updates data-lanes from <0 1> to <0 1 2 3> in kodiak.dtsi now
> that mode-switch is in place, enabling the full 4-lane DP link.

Are you sure that herobrine has 4 lanes routed on the PCB?

Regards,
Bjorn

> 
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
> Changes in v2:
> - Split single patch into 3 patches.
> - Move mode-switch and data-lanes to kodiak.dtsi instead of board
>   file (Neil Armstrong, Konrad Dybcio)
> - Remove redundant board-level endpoint and orientation-switch
>   overrides now covered by kodiak.dtsi
> - v1 received a Reviewed-by from Dmitry on the combined change;
>   that tag has been dropped pending re-review of the split.
> 
> ---
> Mahadevan P (3):
>       arm64: dts: qcom: kodiak: allow mode-switch events to reach the QMP Combo PHY
>       arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi
>       arm64: dts: qcom: kodiak: Set up 4-lane DP
> 
>  arch/arm64/boot/dts/qcom/kodiak.dtsi                          |  2 ++
>  arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts            |  4 ----
>  arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts         |  4 ----
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts                  | 11 -----------
>  arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts |  1 -
>  arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts     |  3 ---
>  arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi                |  1 -
>  7 files changed, 2 insertions(+), 24 deletions(-)
> ---
> base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
> change-id: 20260420-kodiak_v2-d7a06d50db5e
> 
> Best regards,
> -- 
> Mahadevan P <mahadevan.p@oss.qualcomm.com>
> 

Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[Konrad Dybcio]

On 5/22/26 5:41 AM, Bjorn Andersson wrote:
> On Wed, Apr 29, 2026 at 12:10:39PM +0530, Mahadevan P wrote:
>> This series enables full 4-lane DisplayPort operation on SC7280/kodiak
>> platforms by wiring up the QMP Combo PHY correctly and consolidating
>> the DP endpoint configuration in the SoC dtsi.
>>
>> Patch 1 adds mode-switch to the QMP Combo PHY node in kodiak.dtsi,
>> which is required for the PHY to respond to USB-C Alternate Mode
>> negotiation and switch into 4-lane DP configuration.
>>
>> Patch 2 moves the data-lanes property from individual board files into
>> kodiak.dtsi since the PHY-to-controller wiring is fixed in silicon.
>> It also removes redundant remote-endpoint and orientation-switch
>> overrides from qcs6490-rb3gen2 and qcs6490-thundercomm-rubikpi3 that
>> are already covered by the SoC dtsi.
>>
>> Patch 3 updates data-lanes from <0 1> to <0 1 2 3> in kodiak.dtsi now
>> that mode-switch is in place, enabling the full 4-lane DP link.
> 
> Are you sure that herobrine has 4 lanes routed on the PCB?

+Doug any chance you still have schematics for that old boy?

Bjorn, perhaps we could switch to a model where we define the max
capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
them as necessary? Not meeting these is borderline a board defect anyway

Konrad

Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[Doug Anderson]

Hi,

On Fri, Jun 19, 2026 at 8:34 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 5/22/26 5:41 AM, Bjorn Andersson wrote:
> > On Wed, Apr 29, 2026 at 12:10:39PM +0530, Mahadevan P wrote:
> >> This series enables full 4-lane DisplayPort operation on SC7280/kodiak
> >> platforms by wiring up the QMP Combo PHY correctly and consolidating
> >> the DP endpoint configuration in the SoC dtsi.
> >>
> >> Patch 1 adds mode-switch to the QMP Combo PHY node in kodiak.dtsi,
> >> which is required for the PHY to respond to USB-C Alternate Mode
> >> negotiation and switch into 4-lane DP configuration.
> >>
> >> Patch 2 moves the data-lanes property from individual board files into
> >> kodiak.dtsi since the PHY-to-controller wiring is fixed in silicon.
> >> It also removes redundant remote-endpoint and orientation-switch
> >> overrides from qcs6490-rb3gen2 and qcs6490-thundercomm-rubikpi3 that
> >> are already covered by the SoC dtsi.
> >>
> >> Patch 3 updates data-lanes from <0 1> to <0 1 2 3> in kodiak.dtsi now
> >> that mode-switch is in place, enabling the full 4-lane DP link.
> >
> > Are you sure that herobrine has 4 lanes routed on the PCB?
>
> +Doug any chance you still have schematics for that old boy?
>
> Bjorn, perhaps we could switch to a model where we define the max
> capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
> them as necessary? Not meeting these is borderline a board defect anyway

Bleh, I'd forgotten what a pain it was to look at herobrine schematics
with the whole qcard "abstraction".

My memory and a quick glance at schematics makes me say that herobrine
only has 2 lanes of DP. The problem is that this SoC really wasn't
designed with a laptop in mind. I seem to remember there only being
one USB 3 port and it is muxed with two of the DP lanes (since the SoC
is designed to drive a single Type-C port). In order to support all of
the ports that a laptop should have, you pretty much need to feed that
one USB 3 port into a USB hub and hardcode the DP to always use two
lanes.

The two DP lanes then go to a mux where they can be routed either
towards the left Type C port or the right Type C port.

In terms of whether we can support the 8.1 GHz link speed, I remember
much debate during the project, but I don't recall all the details. I
think the discussion was that we were supposed to support the higher
speeds, but we had to disable them because they weren't working. From
my fuzzy memory, it was unclear whether the problem was known to be
hardware or software related. I can try to dig deeper if it's
relevant.

-Doug

Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[Konrad Dybcio]

On 6/22/26 12:11 AM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Jun 19, 2026 at 8:34 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:

[...]


>>>
>>> Are you sure that herobrine has 4 lanes routed on the PCB?
>>
>> +Doug any chance you still have schematics for that old boy?
>>
>> Bjorn, perhaps we could switch to a model where we define the max
>> capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
>> them as necessary? Not meeting these is borderline a board defect anyway
> 
> Bleh, I'd forgotten what a pain it was to look at herobrine schematics
> with the whole qcard "abstraction".
> 
> My memory and a quick glance at schematics makes me say that herobrine
> only has 2 lanes of DP. The problem is that this SoC really wasn't
> designed with a laptop in mind. I seem to remember there only being
> one USB 3 port and it is muxed with two of the DP lanes (since the SoC
> is designed to drive a single Type-C port). In order to support all of
> the ports that a laptop should have, you pretty much need to feed that
> one USB 3 port into a USB hub and hardcode the DP to always use two
> lanes.
> 
> The two DP lanes then go to a mux where they can be routed either
> towards the left Type C port or the right Type C port.
> 
> In terms of whether we can support the 8.1 GHz link speed, I remember
> much debate during the project, but I don't recall all the details. I
> think the discussion was that we were supposed to support the higher
> speeds, but we had to disable them because they weren't working. From
> my fuzzy memory, it was unclear whether the problem was known to be
> hardware or software related. I can try to dig deeper if it's
> relevant.

If anyone still has herobrine easily accessible, I guess a smoke test
with a high res display and this:

diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 5c5e4f1dd221..a39e418fdabb 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -464,7 +464,7 @@ &mdss_dp {
 
 &mdss_dp_out {
        data-lanes = <0 1>;
-       link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
+       link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
 };
 
 /* NVMe drive, enabled on a per-board basis */

would be the quickest way to confirm that. Although we can just leave
it as-is if it's problematic.. I think you said there's some folks that
still use it a couple years ago

Konrad

Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY

[Dmitry Baryshkov]

On Fri, Jun 26, 2026 at 06:02:12PM +0200, Konrad Dybcio wrote:
> On 6/22/26 12:11 AM, Doug Anderson wrote:
> > Hi,
> > 
> > On Fri, Jun 19, 2026 at 8:34 AM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
> 
> [...]
> 
> 
> >>>
> >>> Are you sure that herobrine has 4 lanes routed on the PCB?
> >>
> >> +Doug any chance you still have schematics for that old boy?
> >>
> >> Bjorn, perhaps we could switch to a model where we define the max
> >> capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
> >> them as necessary? Not meeting these is borderline a board defect anyway
> > 
> > Bleh, I'd forgotten what a pain it was to look at herobrine schematics
> > with the whole qcard "abstraction".
> > 
> > My memory and a quick glance at schematics makes me say that herobrine
> > only has 2 lanes of DP. The problem is that this SoC really wasn't
> > designed with a laptop in mind. I seem to remember there only being
> > one USB 3 port and it is muxed with two of the DP lanes (since the SoC
> > is designed to drive a single Type-C port). In order to support all of
> > the ports that a laptop should have, you pretty much need to feed that
> > one USB 3 port into a USB hub and hardcode the DP to always use two
> > lanes.

This matches my memory and the abstractions that Stephen has been trying
to implement.

> > 
> > The two DP lanes then go to a mux where they can be routed either
> > towards the left Type C port or the right Type C port.
> > 
> > In terms of whether we can support the 8.1 GHz link speed, I remember
> > much debate during the project, but I don't recall all the details. I
> > think the discussion was that we were supposed to support the higher
> > speeds, but we had to disable them because they weren't working. From
> > my fuzzy memory, it was unclear whether the problem was known to be
> > hardware or software related. I can try to dig deeper if it's
> > relevant.
> 
> If anyone still has herobrine easily accessible, I guess a smoke test
> with a high res display and this:

I remember that it was not stable. HBR3 worked in some cases and didn't
in the other cases. So, I'd rather not touch the old grampa and leave it
as is.

> 
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> index 5c5e4f1dd221..a39e418fdabb 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> @@ -464,7 +464,7 @@ &mdss_dp {
>  
>  &mdss_dp_out {
>         data-lanes = <0 1>;
> -       link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
> +       link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
>  };
>  
>  /* NVMe drive, enabled on a per-board basis */
> 
> would be the quickest way to confirm that. Although we can just leave
> it as-is if it's problematic.. I think you said there's some folks that
> still use it a couple years ago

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/3] arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi

[Dmitry Baryshkov]

On Wed, Apr 29, 2026 at 12:10:41PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
> 
> The connection between the QMP Combo PHY and the DisplayPort controller
> is fixed in SoC, so move the data-lanes property to kodiak.dtsi and
> drop the per-board overrides.
> 
> Also remove the redundant remote-endpoint cross-links and
> orientation-switch property from qcs6490-rb3gen2 and
> qcs6490-thundercomm-rubikpi3, which are already defined in kodiak.dtsi.

Separate commit.

> 
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/kodiak.dtsi                          |  1 +
>  arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts            |  4 ----
>  arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts         |  4 ----
>  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts                  | 11 -----------
>  arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts |  1 -
>  arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts     |  3 ---
>  arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi                |  1 -
>  7 files changed, 1 insertion(+), 24 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 96ac3656ab5a..0acc6917d7aa 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,6 +5704,7 @@ dp_in: endpoint {
>  					port@1 {
>  						reg = <1>;
>  						mdss_dp_out: endpoint {
> +							data-lanes = <0 1>;

This is not true. The SoC has 4 lanes going from the DP controller to
the QMP PHY.

>  							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
>  						};
>  					};

-- 
With best wishes
Dmitry

Re: [PATCH v2 3/3] arm64: dts: qcom: kodiak: Set up 4-lane DP

[Dmitry Baryshkov]

On Wed, Apr 29, 2026 at 12:10:42PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
> 
> Allow up to 4 lanes for the DisplayPort link from the PHY to the
> controller now the mode-switch events can reach the QMP Combo PHY.
> 
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 0acc6917d7aa..204513a6bd89 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,7 +5704,7 @@ dp_in: endpoint {
>  					port@1 {
>  						reg = <1>;
>  						mdss_dp_out: endpoint {
> -							data-lanes = <0 1>;
> +							data-lanes = <0 1 2 3>;

So, basically, you've force-enabled 4 lanes for all devices, even though
they had 2 lanes enabled only. Don't do that. Squash it to the previous
commit and enable carefully, only for the platforms where you actually
know that there are 4 DP lanes to be used.

>  							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
>  						};
>  					};
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/3] arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi

[Bjorn Andersson]

On Fri, Jun 26, 2026 at 11:50:40PM +0300, Dmitry Baryshkov wrote:
> On Wed, Apr 29, 2026 at 12:10:41PM +0530, Mahadevan P wrote:
> > From: Mahadevan P <mahap@qti.qualcomm.com>
> > 
> > The connection between the QMP Combo PHY and the DisplayPort controller
> > is fixed in SoC, so move the data-lanes property to kodiak.dtsi and
> > drop the per-board overrides.
> > 
> > Also remove the redundant remote-endpoint cross-links and
> > orientation-switch property from qcs6490-rb3gen2 and
> > qcs6490-thundercomm-rubikpi3, which are already defined in kodiak.dtsi.
> 
> Separate commit.
> 
> > 
> > Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> > ---
> >  arch/arm64/boot/dts/qcom/kodiak.dtsi                          |  1 +
> >  arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts            |  4 ----
> >  arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts         |  4 ----
> >  arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts                  | 11 -----------
> >  arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts |  1 -
> >  arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts     |  3 ---
> >  arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi                |  1 -
> >  7 files changed, 1 insertion(+), 24 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > index 96ac3656ab5a..0acc6917d7aa 100644
> > --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > @@ -5704,6 +5704,7 @@ dp_in: endpoint {
> >  					port@1 {
> >  						reg = <1>;
> >  						mdss_dp_out: endpoint {
> > +							data-lanes = <0 1>;
> 
> This is not true. The SoC has 4 lanes going from the DP controller to
> the QMP PHY.
> 

Does this property really denote the number of lanes and mapping the
internal pipe between DP TX and PHY? Doesn't it tell how the external
mapping looks like?

Regards,
Bjorn

> >  							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
> >  						};
> >  					};
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v2 3/3] arm64: dts: qcom: kodiak: Set up 4-lane DP

[Bjorn Andersson]

On Wed, Apr 29, 2026 at 12:10:42PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
> 
> Allow up to 4 lanes for the DisplayPort link from the PHY to the

It's hard to follow your thought process here, as you didn't document
why this change should be made. Start your commit message by describing
the problem that your change is solving.

> controller now the mode-switch events can reach the QMP Combo PHY.
> 
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 0acc6917d7aa..204513a6bd89 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,7 +5704,7 @@ dp_in: endpoint {
>  					port@1 {
>  						reg = <1>;
>  						mdss_dp_out: endpoint {
> -							data-lanes = <0 1>;
> +							data-lanes = <0 1 2 3>;

And as Dmitry pointed out, not all Kodiak-based boards have 4 DP-lanes
wired up.

Regards,
Bjorn

>  							remote-endpoint = <&usb_dp_qmpphy_dp_in>;
>  						};
>  					};
> 
> -- 
> 2.34.1
>