On 1/7/22 11:51, Limonciello, Mario wrote:
[AMD Official Use Only]
I think the revert is fine once we figure out where we're missing calls to:
.optimize_pwr_state = dcn21_optimize_pwr_state,
.exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
These are already part of dc_link_detect, so I suspect there's another interface
in DC that should be using these.
I think the best way to debug this is to revert the patch locally and add a stack
dump when DMCUB hangs our times out.
OK so I did this on top of amd-staging-drm-next with my v5 patch (this revert in place)
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
index 9280f2abd973..0bd32f82f3db 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c
@@ -789,8 +789,10 @@ enum dmub_status dmub_srv_cmd_with_reply_data(struct dmub_srv *dmub,
// Execute command
status = dmub_srv_cmd_execute(dmub);
- if (status != DMUB_STATUS_OK)
+ if (status != DMUB_STATUS_OK) {
+ ASSERT(0);
return status;
+ }
// Wait for DMUB to process command
status = dmub_srv_wait_for_idle(dmub, 100000);
That way you can know where the PHY was trying to be accessed without the
refclk being on.
We had a similar issue in DCN31 which didn't require a W/A like DCN21.
I'd like to hold off on merging this until that hang is verified as gone.
Then I took a RN laptop running DMUB 0x01010019 and disabled eDP, and confirmed
no CRTC was configured but plugged in an HDMI cable:
connector[78]: eDP-1
crtc=(null)
self_refresh_aware=0
connector[85]: HDMI-A-1
crtc=crtc-1
self_refresh_aware=0
I triggered 100 hotplugs like this:
#!/bin/bash
for i in {0..100..1}
do
echo 1 | tee /sys/kernel/debug/dri/0/HDMI-A-1/trigger_hotplug
sleep 3
done
Unfortunately, no hang or traceback to be seen (and HDMI continues to work).
I also manually pulled the plug a handful of times I don't know the specifics that Lillian had the
failure though, so this might not be a good enough check.
I'll try to upgrade DMUB to 0x101001c (the latest version) and double check that as well.
I applied patch v5 and the above ASSERT patch, on top of both Linux
5.16-rc8 and 5.16.
Result: no problems with suspend/resume, 16+ cycles.
As far as the hang goes:
I plugged in an HDMI cable connected to my TV, and configured Gnome to
use the external display only.
connectors from /sys/kernel/debug/dri/0/state:
connector[78]: eDP-1
crtc=(null)
self_refresh_aware=0
connector[85]: HDMI-A-1
crtc=crtc-1
self_refresh_aware=0
connector[89]: DP-1
crtc=(null)
self_refresh_aware=0
I manually unplugged/plugged the HDMI cable 16+ times, and also ran:
$ sudo sh -c 'for ((i=0;i<100;i++)); do echo 1 | tee
/sys/kernel/debug/dri/0/HDMI-A-1/trigger_hotplug; sleep 3; done'
The system did not hang, and I saw no kernel log output from the ASSERT.
I also tried a USB-C dock with an HDMI port, with the same results,
though there are other issues with this (perhaps worthy of other bug
reports).
Is there some reason to use amd-staging-drm-next for this test?
I don't use the HDMI connection much and I have never experienced a hang
with HDMI in the first place. Can someone send a link to an
issue/discussion where this hang is being discussed?
HW: HP ENVY x360 Convertible 15-ds1xxx, AMD Ryzen 7 4700U with Radeon
Graphics
OS/Desktop: Arch Linux, Gnome 41.3 (Wayland)
FW: linux-firmware-git 20211229.57d6b95-1, DMUB version=0x0101001C
