From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
Signed-off-by: Dale Whinham <daleyo@gmail.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;
+ }
+
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];
--
2.50.1
On 2025/7/15 01:35:42, Dale Whinham wrote:
> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
> Signed-off-by: Dale Whinham <daleyo@gmail.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.
[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@radxa.com>
On 2025/7/17 04:21, Xilin Wu <sophon@radxa.com> wrote :
>
> On 2025/7/15 01:35:42, Dale Whinham wrote:
> > From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
> > Signed-off-by: Dale Whinham <daleyo@gmail.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.
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?
[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@radxa.com>
On 7/17/25 10:27 PM, Jérôme de Bretagne wrote:
> On 2025/7/17 04:21, Xilin Wu <sophon@radxa.com> wrote :
>>
>> On 2025/7/15 01:35:42, Dale Whinham wrote:
>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
>>> Signed-off-by: Dale Whinham <daleyo@gmail.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
>
> 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, so I wouldn't expect it to
be a big blocker.
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.
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@radxa.com>
>
Le jeu. 17 juil. 2025 à 23:10, Konrad Dybcio
<konrad.dybcio@oss.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@radxa.com> wrote :
> >>
> >> On 2025/7/15 01:35:42, Dale Whinham wrote:
> >>> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
> >>> Signed-off-by: Dale Whinham <daleyo@gmail.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@radxa.com>
> >
On Thu, Jul 17, 2025 at 11:36:38PM +0200, Jérôme de Bretagne wrote: > Le jeu. 17 juil. 2025 à 23:10, Konrad Dybcio > <konrad.dybcio@oss.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@radxa.com> wrote : > > >> > > >> On 2025/7/15 01:35:42, Dale Whinham wrote: > > >>> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com> > > >>> Signed-off-by: Dale Whinham <daleyo@gmail.com> > > >>> --- > > >>> drivers/gpu/drm/msm/dp/dp_panel.c | 13 +++++++++++++ > > >>> 1 file changed, 13 insertions(+) > > >>> [...] > > > > > > > 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. Unforutunately, there is more than that. We should also be writing the LINK_RATE_SET register. So, just setting the max_bw is not enough. -- With best wishes Dmitry
On Friday, Jul 18, 2025, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > > On Thu, Jul 17, 2025 at 11:36:38PM +0200, Jérôme de Bretagne wrote: > > Le jeu. 17 juil. 2025 à 23:10, Konrad Dybcio > > <konrad.dybcio@oss.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@radxa.com> wrote : > > > >> > > > >> On 2025/7/15 01:35:42, Dale Whinham wrote: > > > >>> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com> > > > >>> Signed-off-by: Dale Whinham <daleyo@gmail.com> > > > >>> --- > > > >>> drivers/gpu/drm/msm/dp/dp_panel.c | 13 +++++++++++++ > > > >>> 1 file changed, 13 insertions(+) > > > >>> > > [...] > > > > > > > > > > > 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. > > Unforutunately, there is more than that. We should also be writing the > LINK_RATE_SET register. So, just setting the max_bw is not enough. Maybe I've misunderstood. When you say max_bw is not enough, are you talking about some future driver changes or about a potential shorter-term fix? I can confirm that this initial simple patch (and also the updated one reusing the quirk list [4]) is enough to get the SP11 OLED display working whereas it doesn't probe and remains off without such a fix. Thanks, Jérôme [4] https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb > -- > With best wishes > Dmitry
On 18/07/2025 21:26, Jérôme de Bretagne wrote: > On Friday, Jul 18, 2025, Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: >> >> On Thu, Jul 17, 2025 at 11:36:38PM +0200, Jérôme de Bretagne wrote: >>> Le jeu. 17 juil. 2025 à 23:10, Konrad Dybcio >>> <konrad.dybcio@oss.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@radxa.com> wrote : >>>>>> >>>>>> On 2025/7/15 01:35:42, Dale Whinham wrote: >>>>>>> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com> >>>>>>> Signed-off-by: Dale Whinham <daleyo@gmail.com> >>>>>>> --- >>>>>>> drivers/gpu/drm/msm/dp/dp_panel.c | 13 +++++++++++++ >>>>>>> 1 file changed, 13 insertions(+) >>>>>>> >> >> [...] >> >>> >>>>> >>>>> 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. >> >> Unforutunately, there is more than that. We should also be writing the >> LINK_RATE_SET register. So, just setting the max_bw is not enough. > > Maybe I've misunderstood. When you say max_bw is not enough, > are you talking about some future driver changes or about a potential > shorter-term fix? > > I can confirm that this initial simple patch (and also the updated one > reusing the quirk list [4]) is enough to get the SP11 OLED display > working whereas it doesn't probe and remains off without such a fix. These parts were changed in eDP 1.4 and then 1.5, but basically, if MAX_LINK_RATE is 0, the driver should also write LINK_RATE_SET register. See how it's handled by the intel or AMD drivers. > > Thanks, > Jérôme > > [4] https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb >> -- >> With best wishes >> Dmitry -- With best wishes Dmitry
On Mon, Jul 14, 2025 at 10:36 AM Dale Whinham <daleyo@gmail.com> wrote:
>
> From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
> Signed-off-by: Dale Whinham <daleyo@gmail.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;
> + }
Not a dp expert myself, but..
In drm_dp_helpers.c there is dpcd_quirk_list[].. which applies quirks
based on the oui ("Organizational Unique ID") of the dp sink. I think
this would be the correct way to handle this. Although I guess you'll
need to add a new quirk for this.
Idk if the surface pro 11 has multiple different panel options. If so
you defn wouldn't want to match on the DMI.
BR,
-R
> +
> 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];
> --
> 2.50.1
>
On Mon, Jul 14, 2025 at 21:51, Rob Clark <rob.clark@oss.qualcomm.com> wrote:
>
> On Mon, Jul 14, 2025 at 10:36 AM Dale Whinham <daleyo@gmail.com> wrote:
> >
> > From: Jérôme de Bretagne <jerome.debretagne@gmail.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@gmail.com>
> > Signed-off-by: Dale Whinham <daleyo@gmail.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;
> > + }
>
> Not a dp expert myself, but..
>
> In drm_dp_helpers.c there is dpcd_quirk_list[].. which applies quirks
> based on the oui ("Organizational Unique ID") of the dp sink. I think
> this would be the correct way to handle this. Although I guess you'll
> need to add a new quirk for this.
>
> Idk if the surface pro 11 has multiple different panel options. If so
> you defn wouldn't want to match on the DMI.
>
> BR,
> -R
Thanks Rob for the feedback, I have a working implementation
based on your suggestion with a new quirk, we will switch to it in V2.
Best,
Jérôme
> > +
> > 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];
> > --
> > 2.50.1
> >
© 2016 - 2025 Red Hat, Inc.