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
