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. Thanks, Jérôme [4] https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb > -- > With best wishes > Dmitry >
