On 18/07/2025 21:26, Jérôme de Bretagne wrote:
On Friday, Jul 18, 2025, Dmitry Baryshkov
<dmitry.barysh...@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.dyb...@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 <sop...@radxa.com> wrote :
On 2025/7/15 01:35:42, Dale Whinham wrote:
From: Jérôme de Bretagne <jerome.debreta...@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.debreta...@gmail.com>
Signed-off-by: Dale Whinham <dal...@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
