On Thu, Sep 04, 2025 at 03:20:23PM +0200, Wolfgang Frisch wrote: > Hi Imre, > > > On 9/2/25 6:13 PM, Imre Deak wrote: > > This looks like the issue tracked at > > https://gitlab.freedesktop.org/drm/amd/-/issues/4500 > Thanks! I wasn't aware of that issue being tracked already. > > > The correct solution there is to disable the DPCD probing, which AMD > > folks are working on atm. Until that, could you give a go to patch [1] > > on the above ticket equivalent to this solution, applying on v6.17, or > > the attached patch achieving the same on v6.16.4? > I can confirm your patch fixes the issue on v6.16.4. > > Also it would help if you could add a dmesg log on the ticket taken > > after booting with drm.debug=0x100 and reproducing the problem (vs. two > > other drm.debug=0x100 logs, one with the above DP_TRAINING_PATTERN_SET > > -> DP_LANE0_1_STATUS change and another one with DPCD probing disabled > > as I requested above, taken after booting up and connecting the > > dock/monitor). > Done. I attached 3 dmesg logs to the ticket:
Thanks for the testing. > - GOOD: Linux 6.16.4 with DPCD probing disabled > - BAD: Linux 6.17.0-rc4 This is expected, as it still does DPCD probing leading to the original TBT firmware issue tracked on the above ticket. > - GOOD: Linux 6.17.0-rc4 with the probe address set to DP_LANE0_1_STATUS Switching the DPCD probing address to DP_LANE0_1_STATUS is not a viable solution, as it causes an issue for at least one other (eDP) panel. The probing should be disabled according to the following AMD patch: https://gitlab.freedesktop.org/-/project/4522/uploads/5205fd4e2bdc396088836bafcac176b6/0004-drm-amd-display-Disable-DPCD-Probe-Quirk.patch --Imre > Regards, > > -- > Wolfgang Frisch <wolfgang.fri...@suse.com> > Security Engineer > OpenPGP fingerprint: A2E6 B7D4 53E9 544F BC13 D26B D9B3 56BD 4D4A 2D15 > SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg >
