Hey,
On Tue, 10 Mar 2020, Takashi Iwai wrote:
> On Tue, 10 Mar 2020 19:25:22 +0100, Ville Syrjälä wrote:
>> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
>>> One problematic scenario that this doesn't cover:
>>> - a single display is used (at low cdclk), and
>>> - audio block goes to runtime suspend while display stays up.
>>>
>>> Upon resume (for e.g. UI notification sound), audio will initialize the
>>> HDA bus and call get_power() on i915, even if the notification goes to
>>> internal speaker. A modeset at this point is potentially very annoying.
>>
>> :( That seems much harder to deal with.
>
> I guess it doesn't happen -- at least with the legacy HD-audio and the
> recent chip, if I understand correctly. When the stream is on the
> analog codec, the HDMI codec is kept closed / runtime-resumed. And
> the additional get_power() in the controller side is done only for
> HSW/BDW (where the HDA-bus is dedicated to HDMI).
I'm afraid it does -- I double checked the legacy driver code. Judging
from history, since commit "ALSA: hda - Fix Skylake codec timeout",
azx_runtime_resume() has called "display_power(chip, true)" on all
platforms, even if the stream is on analog codec. I just recently fixed
this logic to SOF driver as well. If you don't do this and the link
parameters are different from hw defaults on i915 side (more likely with
ICL and newer), you'll hit problems.
I don't currently know of a reliable way to recover. In theory, if HDMI/DP
monitor is connected, we could do a delayed call to i915 get_power and
reinitialize the HDA controller, but if we are actively streaming to
analog codec when this happens, this wouldn't work.
And until very recent times, this has not really been an issue. With
current i915, many conditions have to be met to actually hit this (only
affects GLK platforms, you need to be using HDA analog codec, runtime PM
needs to be enabled for HDA, etc). Problem is that going forward, there
are going to be more platforms that are affected and this starts to show
up in more places.
Ville: I'm checking your draft patch. I'll report back when I've
completed testing.
Br, Kai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
