<div dir="ltr">On Friday, Jul 18, 2025, Dmitry Baryshkov <<a href="mailto:dmitry.baryshkov@oss.qualcomm.com" target="_blank">dmitry.baryshkov@oss.qualcomm.com</a>> 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 >> <<a href="mailto:konrad.dybcio@oss.qualcomm.com" target="_blank">konrad.dybcio@oss.qualcomm.com</a>> a écrit : >> > >> > On 7/17/25 10:27 PM, Jérôme de Bretagne wrote: >> > > On 2025/7/17 04:21, Xilin Wu <<a href="mailto:sophon@radxa.com" target="_blank">sophon@radxa.com</a>> wrote : >> > >> >> > >> On 2025/7/15 01:35:42, Dale Whinham wrote: >> > >>> From: Jérôme de Bretagne <<a href="mailto:jerome.debretagne@gmail.com" target="_blank">jerome.debretagne@gmail.com</a>> >> > >>> >> > >>> 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 <<a href="mailto:jerome.debretagne@gmail.com" target="_blank">jerome.debretagne@gmail.com</a>> >> > >>> Signed-off-by: Dale Whinham <<a href="mailto:daleyo@gmail.com" target="_blank">daleyo@gmail.com</a>> >> > >>> --- >> > >>> 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, <div>are you talking about some future driver changes or about a potential</div><div>shorter-term fix?</div><div> </div><div>I can confirm that this initial simple patch (and also the updated one</div><div>reusing the quirk list [4]) is enough to get the SP11 OLED display</div><div>working whereas it doesn't probe and remains off without such a fix.</div> Thanks, Jérôme [4] <a href="https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb" target="_blank">https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb</a></div> > -- > With best wishes > Dmitry >