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@xxxxxxxxxxxxxxxx> 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