From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: "Jérôme de Bretagne" <jerome.debretagne@gmail.com>,
"Xilin Wu" <sophon@radxa.com>
Cc: Dale Whinham <daleyo@gmail.com>, Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Dmitry Baryshkov <lumag@kernel.org>, Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/9] drm/msm/dp: Work around bogus maximum link rate
Date: Thu, 17 Jul 2025 23:10:17 +0200 [thread overview]
Message-ID: <eb0f5be5-3a6f-4969-affd-c01a6216ad0c@oss.qualcomm.com> (raw)
In-Reply-To: <CA+kEDGGaKrYO9Pu3un_Nq_6AOZC5L9sG+CEwh2ZEzWFeHGqtEA@mail.gmail.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>
>
next prev parent reply other threads:[~2025-07-17 21:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 17:35 [PATCH 0/9] Microsoft Surface Pro 11 support Dale Whinham
2025-07-14 17:35 ` [PATCH 1/9] dt-bindings: arm: qcom: Document Microsoft Surface Pro 11 Dale Whinham
2025-07-15 3:58 ` Rob Herring (Arm)
2025-07-14 17:35 ` [PATCH 2/9] dt-bindings: display: panel: samsung,atna30dw01: document ATNA30DW01 Dale Whinham
2025-07-14 17:41 ` Doug Anderson
2025-07-15 3:58 ` Rob Herring (Arm)
2025-07-15 17:26 ` Doug Anderson
2025-07-14 17:35 ` [PATCH 3/9] firmware: qcom: scm: allow QSEECOM on Surface Pro 11 Dale Whinham
2025-07-14 17:35 ` [PATCH 4/9] platform/surface: aggregator_registry: Add " Dale Whinham
2025-07-15 22:24 ` Maximilian Luz
2025-07-14 17:35 ` [PATCH 5/9] arm64: dts: qcom: Add support for " Dale Whinham
2025-07-14 17:35 ` [PATCH 6/9] drm/msm/dp: Work around bogus maximum link rate Dale Whinham
2025-07-14 19:50 ` Rob Clark
2025-07-15 22:52 ` Jérôme de Bretagne
2025-07-17 2:21 ` Xilin Wu
2025-07-17 20:27 ` Jérôme de Bretagne
2025-07-17 21:10 ` Konrad Dybcio [this message]
2025-07-17 21:36 ` Jérôme de Bretagne
2025-07-18 10:52 ` Dmitry Baryshkov
2025-07-18 18:26 ` Jérôme de Bretagne
2025-07-18 18:30 ` Dmitry Baryshkov
2025-07-14 17:35 ` [PATCH 7/9 RFC] dt-bindings: wireless: ath12k: Add disable-rfkill property Dale Whinham
2025-07-14 22:33 ` Dmitry Baryshkov
2025-07-14 23:26 ` Jérôme de Bretagne
2025-07-15 4:02 ` Rob Herring
2025-07-14 17:35 ` [PATCH 8/9 RFC] wifi: ath12k: Add support for disabling rfkill via devicetree Dale Whinham
2025-07-14 17:35 ` [PATCH 9/9 RFC] arm64: dts: qcom: x1e80100-denali: Disable rfkill for wifi0 Dale Whinham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eb0f5be5-3a6f-4969-affd-c01a6216ad0c@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=airlied@gmail.com \
--cc=daleyo@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jerome.debretagne@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=sophon@radxa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®