linux-kernel - Re: [PATCH 6/9] drm/msm/dp: Work around bogus maximum link rate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+kEDGE1kb12pW_OH1n4LmB9PVtgEsft563p9Cx_Mxev9Em3Ow@mail.gmail.com>
Date: Thu, 17 Jul 2025 23:36:38 +0200
From: Jérôme de Bretagne <jerome.debretagne@...il.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Xilin Wu <sophon@...xa.com>, Dale Whinham <daleyo@...il.com>, Rob Clark <robdclark@...il.com>, 
	Abhinav Kumar <quic_abhinavk@...cinc.com>, Dmitry Baryshkov <lumag@...nel.org>, 
	Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, linux-arm-msm@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/9] drm/msm/dp: Work around bogus maximum link rate

Le jeu. 17 juil. 2025 à 23:10, Konrad Dybcio
<konrad.dybcio@....qualcomm.com> a écrit :
>
> On 7/17/25 10:27 PM, Jérôme de Bretagne wrote:
> > On 2025/7/17 04:21, Xilin Wu <sophon@...xa.com> wrote :
> >>
> >> On 2025/7/15 01:35:42, Dale Whinham wrote:
> >>> From: Jérôme de Bretagne <jerome.debretagne@...il.com>
> >>>
> >>> The OLED display in the Surface Pro 11 reports a maximum link rate of
> >>> zero in its DPCD, causing it to fail to probe correctly.
> >>>
> >>> The Surface Pro 11's DSDT table contains some XML with an
> >>> "EDPOverrideDPCDCaps" block that defines the max link rate as 0x1E
> >>> (8.1Gbps/HBR3).
> >>>
> >>> Add a quirk to conditionally override the max link rate if its value
> >>> is zero specifically for this model.
> >>>
> >>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@...il.com>
> >>> Signed-off-by: Dale Whinham <daleyo@...il.com>
> >>> ---
> >>>   drivers/gpu/drm/msm/dp/dp_panel.c | 13 +++++++++++++
> >>>   1 file changed, 13 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c
> >>> index 4e8ab75c771b..b2e65b987c05 100644
> >>> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> >>> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> >>> @@ -11,6 +11,8 @@
> >>>   #include <drm/drm_of.h>
> >>>   #include <drm/drm_print.h>
> >>>
> >>> +#include <linux/dmi.h>
> >>> +
> >>>   #define DP_MAX_NUM_DP_LANES 4
> >>>   #define DP_LINK_RATE_HBR2   540000 /* kbytes */
> >>>
> >>> @@ -58,6 +60,17 @@ static int msm_dp_panel_read_dpcd(struct msm_dp_panel *msm_dp_panel)
> >>>       if (rc)
> >>>               return rc;
> >>>
> >>> +     /*
> >>> +      * for some reason the ATNA30DW01-1 OLED panel in the Surface Pro 11
> >>> +      * reports a max link rate of 0 in the DPCD. Fix it to match the
> >>> +      * EDPOverrideDPCDCaps string found in the ACPI DSDT
> >>> +      */
> >>> +     if (dpcd[DP_MAX_LINK_RATE] == 0 &&
> >>> +         dmi_match(DMI_SYS_VENDOR, "Microsoft Corporation") &&
> >>> +         dmi_match(DMI_PRODUCT_NAME, "Microsoft Surface Pro, 11th Edition")) {
> >>> +             dpcd[1] = DP_LINK_BW_8_1;
> >>> +     }
> >>> +
> >>
> >> My Galaxy Book4 Edge with the ATNA60CL07-0 panel also reports a max link
> >> rate of 0. But I think eDP v1.4 panels need a different way to retrieve
> >> supported links rates, which could be found in the amdgpu [1], i915 [2]
> >> and nouveau [3] drivers.
> >
> > Thanks Xilin for the sharing and pointers into 3 other drivers, that
> > would explain the current limitation for Adreno GPUs. Fixing it would
> > require a big contribution independent of the actual SP11 enablement.
>
> FWIW Adreno is a wholly separate (from DPU - the display engine) block

Thanks Konrad, indeed I should have referred to the display engine.

> >
> > Is it a feature planned in the short-medium term within the MSM driver?
> > If not, would a quirk like [4] be acceptable upstream in the meanwhile?
>
> I'm not a display guy, but this looks like yet another block of code
> begging to be commonized across DP drivers,

I agree 100% in principle, but the 3 implementations are different today.

> so I wouldn't expect it to be a big blocker.

Well, it is for me :)

> Adding a panel quirk doesn't seem in order, as the panel is /probably/
> very much in spec, and it's the driver bit that's missing.

I agree that a quirk shouldn't be needed. I guess we'll work on
upstreaming everything else and keep an out-of-tree patch for this
issue for the moment That's a bit sad as this will block regular
users from easily installing / testing via the Ubuntu Concept ISO
for instance.

Or could the quirk be accepted temporarily with good comments
then reverted when the driver adds the missing support? I guess
it would depend on the time scale of this support landing.

Cheers,
Jérôme

> Konrad
>
> >
> > [4] https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb
> >
> > Thanks a lot,
> > Jérôme
> >
> >
> >
> >> [1]:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c#n2098
> >> [2]:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/i915/display/intel_dp.c#n4281
> >> [3]:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/nouveau/nouveau_dp.c#n101
> >>
> >>
> >>>       msm_dp_panel->vsc_sdp_supported = drm_dp_vsc_sdp_supported(panel->aux, dpcd);
> >>>       link_info = &msm_dp_panel->link_info;
> >>>       link_info->revision = dpcd[DP_DPCD_REV];
> >>
> >>
> >> --
> >> Best regards,
> >> Xilin Wu <sophon@...xa.com>
> >