intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
Date: Wed, 11 Mar 2020 14:16:56 +0200 (EET)	[thread overview]
Message-ID: <alpine.DEB.2.21.2003111310030.2957@eliteleevi.tm.intel.com> (raw)
In-Reply-To: <s5htv2w9g5n.wl-tiwai@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-03-11 12:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
2019-12-31 14:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2) Patchwork
2019-12-31 20:06 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-02 18:28 ` [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Rodrigo Vivi
2020-01-03 15:28   ` Kai Vehmanen
2020-01-06 16:49     ` Matt Roper
2020-03-06 16:45       ` Kai Vehmanen
2020-03-09 10:54         ` Takashi Iwai
2020-03-10 11:20           ` Kai Vehmanen
2020-03-10 13:41           ` Ville Syrjälä
2020-03-10 17:18             ` Kai Vehmanen
2020-03-10 18:25               ` Ville Syrjälä
2020-03-10 19:13                 ` Takashi Iwai
2020-03-11 12:16                   ` Kai Vehmanen [this message]
     [not found]                     ` <s5hk13q7uf6.wl-tiwai@suse.de>
2020-03-11 17:04                       ` Kai Vehmanen
2020-03-11 17:21                         ` Takashi Iwai
2020-03-12 17:27                 ` Kai Vehmanen
2020-03-12 17:48                   ` Ville Syrjälä
2020-03-12 17:50                   ` Ville Syrjälä
2020-03-13 14:54                     ` Kai Vehmanen
2020-03-11 20:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3) Patchwork
2020-03-11 20:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-12 13:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2003111310030.2957@eliteleevi.tm.intel.com \
    --to=kai.vehmanen@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).