-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
6.10 kernel: i915 driver crash in system suspend due to wakeref from SOF code #5120
Comments
@plbossart FYI |
@rfvirgil can you clarify which endpoint was used? I would guess it's one of the HDMI endpoints but the description refers to the CS board. I am afraid I don't fully get the i915 flows, clearly we don't do anything suspending, hda_codec_i915_display_power() is only called in the resume sequence. this will most likely have to wait for @kv2019i to look at this... |
@ujfalusi FYI since you are in the middle of HDMI debugging. |
@plbossart What do you mean by "endpoint" ? We're playing audio to the CS35L56 on the EIGHT-C board. As a workaround I've set snd_hda_core.gpu_bind=0 I did start looking at the way the wakeref was implemented in i915 and snd-hda, but it was too complex for me to understand... I've found hdac_hdmi_runtime_suspend(), which seems to be releasing the wakeref when it runtime-suspends. I'm guessing that the hdac code isn't handling the case where you system-suspend while still playing audio, so you were not runtime-suspended. |
I cannot reproduce it on upx (running in HDA mode, nothing fancy connected), neither on SDW device which have HDMI (and panel, which might change things). I'm not sure what can cause this atm |
the system suspend in hdac_hdmi.c seems to rely on pm_runtime_force_suspend(). I am not sure what it does and why this would matter anyways if you are not playing audio on HDMI. the entire i915 audio path should be disabled and powered-down. Unless there's the silly keep-alive function that keeps HDMI running? |
Hrm, I have the silent |
I cannot say what is going on... On UPX-i11 HDA: it is OK under all combination With SDW device (MTL): gives With SDW device (TGL-H): it is OK under all combination 🤷 |
In a totally different i915 issue I recently discovered that DRM is polling for monitor hotplug by default even when everything is off. It's configured by You can see it with
Sorry if off-topic, I thought it was worth sharing. |
6.10 kernel
UpXtreme TGL + CDB35L56-EIGHT-C (SoundWire)
Play audio, then system-suspend while audio is still playing.
We're seeing that with the 6.10 kernel there is a WARN triggered in the i915 driver, intel_runtime_pm_driver_release() because there is a wakeref that has not been released. This happens if audio was playing when the system entered system-suspend. For example:
I enabled the debugging in the i915 driver so that wakeref requests are tracked, and printed out the references when the WARN is triggered, and I get the reftracking info below (full dmesg attached dmesg.txt)
So, snd_sof has taken a wakeref on the i915 driver during probe, but has not released it when the system went to system-suspend. The i915 driver expects that all wakerefs have been released before system-suspending.
The text was updated successfully, but these errors were encountered: