[PATCH 0/9] Microsoft Surface Pro 11 support

[PATCH 0/9] Microsoft Surface Pro 11 support

[Dale Whinham]

This series brings support for the X1E80100/X1P64100-based Microsoft
Surface Pro 11.

Patches 7 to 9 are included as RFC as we are unsure of how best to
achieve the required functionality, however the implementation is
functional.

Dale Whinham (6):
  dt-bindings: display: panel: samsung,atna30dw01: document ATNA30DW01
  firmware: qcom: scm: allow QSEECOM on Surface Pro 11
  platform/surface: aggregator_registry: Add Surface Pro 11
  arm64: dts: qcom: Add support for Surface Pro 11
  wifi: ath12k: Add support for disabling rfkill via devicetree
  arm64: dts: qcom: x1e80100-denali: Disable rfkill for wifi0

Jérôme de Bretagne (3):
  dt-bindings: arm: qcom: Document Microsoft Surface Pro 11
  drm/msm/dp: Work around bogus maximum link rate
  dt-bindings: wireless: ath12k: Add disable-rfkill property

 .../devicetree/bindings/arm/qcom.yaml         |    1 +
 .../display/panel/samsung,atna33xc20.yaml     |    2 +
 .../bindings/net/wireless/qcom,ath12k.yaml    |    3 +
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 .../dts/qcom/x1e80100-microsoft-denali.dts    | 1341 +++++++++++++++++
 drivers/firmware/qcom/qcom_scm.c              |    1 +
 drivers/gpu/drm/msm/dp/dp_panel.c             |   13 +
 drivers/net/wireless/ath/ath12k/core.c        |    3 +
 .../surface/surface_aggregator_registry.c     |   18 +
 9 files changed, 1383 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/x1e80100-microsoft-denali.dts

-- 
2.50.1

[PATCH 2/9] dt-bindings: display: panel: samsung, atna30dw01: document ATNA30DW01

[Dale Whinham]

The Samsung ATNA30DW01 panel is a 13" AMOLED eDP panel. It is similar to
the ATNA33XC20 except that it is smaller and has a higher resolution.

Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Signed-off-by: Dale Whinham <daleyo@gmail.com>
---
 .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml   | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml
index 31f0c0f038e4..e36659340ef3 100644
--- a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml
+++ b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml
@@ -19,6 +19,8 @@ properties:
       - const: samsung,atna33xc20
       - items:
           - enum:
+              # Samsung 13" 3K (2880×1920 pixels) eDP AMOLED panel
+              - samsung,atna30dw01
               # Samsung 14" WQXGA+ (2880×1800 pixels) eDP AMOLED panel
               - samsung,atna40yk20
               # Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
-- 
2.50.1

Re: [PATCH 2/9] dt-bindings: display: panel: samsung,atna30dw01: document ATNA30DW01

[Doug Anderson]

Hi,

On Mon, Jul 14, 2025 at 10:36 AM Dale Whinham <daleyo@gmail.com> wrote:
>
> The Samsung ATNA30DW01 panel is a 13" AMOLED eDP panel. It is similar to
> the ATNA33XC20 except that it is smaller and has a higher resolution.
>
> Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> Signed-off-by: Dale Whinham <daleyo@gmail.com>
> ---
>  .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml   | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH 2/9] dt-bindings: display: panel: samsung,atna30dw01: document ATNA30DW01

[Rob Herring (Arm)]

On Mon, 14 Jul 2025 18:35:38 +0100, Dale Whinham wrote:
> The Samsung ATNA30DW01 panel is a 13" AMOLED eDP panel. It is similar to
> the ATNA33XC20 except that it is smaller and has a higher resolution.
> 
> Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> Signed-off-by: Dale Whinham <daleyo@gmail.com>
> ---
>  .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml   | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 2/9] dt-bindings: display: panel: samsung,atna30dw01: document ATNA30DW01

[Doug Anderson]

Hi,

On Mon, Jul 14, 2025 at 8:58 PM Rob Herring (Arm) <robh@kernel.org> wrote:
>
>
> On Mon, 14 Jul 2025 18:35:38 +0100, Dale Whinham wrote:
> > The Samsung ATNA30DW01 panel is a 13" AMOLED eDP panel. It is similar to
> > the ATNA33XC20 except that it is smaller and has a higher resolution.
> >
> > Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
> > Signed-off-by: Dale Whinham <daleyo@gmail.com>
> > ---
> >  .../devicetree/bindings/display/panel/samsung,atna33xc20.yaml   | 2 ++
> >  1 file changed, 2 insertions(+)
> >
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>

Pushed to drm-misc-next:

[2/9] dt-bindings: display: panel: samsung,atna30dw01: document ATNA30DW01
      commit: 0bcc0f5e98bebd05e44261df3c33d274084eab60

Given how many of these we're up to now, I'm starting to wonder if we
should come up with a generic compatible like we did with "edp-panel"
and then we can stop having to merge CLs like this. All of these
Samsung OLED eDP panels have the same power up sequence and once we do
that then we can read them via EDID or via DP AUX bus to identify
which specific panel we have and if they need additional tweaking,
just like we do with "edp-panel". Do DT folks have any opinion about
that? Coming up with a name would be a pain since I wouldn't want to
assert that all future Samsung OLED eDP panels will have the same
powerup sequence. Maybe "samsung,amoled-edp-panel-v1" even though that
sounds terrible and there's no known need for a "-v2"?

-Doug

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

[Dale Whinham]

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

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

[Rob Clark]

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
>

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

[Jérôme de Bretagne]

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

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

[Xilin Wu]

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>

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

[Jérôme de Bretagne]

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>

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

[Konrad Dybcio]

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

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

[Jérôme de Bretagne]

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

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

[Dmitry Baryshkov]

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

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

[Jérôme de Bretagne]

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4461 bytes --]

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

[Jérôme de Bretagne]

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

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

[Dmitry Baryshkov]

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