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>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
Date: Tue, 10 Mar 2020 13:20:07 +0200 (EET)	[thread overview]
Message-ID: <alpine.DEB.2.21.2003101234220.2957@eliteleevi.tm.intel.com> (raw)
In-Reply-To: <s5h4kuxssqr.wl-tiwai@suse.de>

Hey,

On Mon, 9 Mar 2020, Takashi Iwai wrote:

> On Fri, 06 Mar 2020 17:45:44 +0100, Kai Vehmanen wrote:
>> unfortunately it seems this fix that was done is not holding up in wider 
>> testing. It now looks we need to enforce the constraint in one form or 
[...]
>> So how about: We move the glk_force_audio_cdclk() logic from 
>> intel_audio.c:i915_audio_component_get_power() to acomp init.
>> This has some notable implications:
> 
> That sounds reasonable to me.  But it's basically the i915 stuff, so
> I'd leave the decision to you guys :)

thanks Takashi --let's wait for the comments. I'll add also Ville who 
wrote the original glk_force_audio() code diretly to the thread.

> My another quick thought after reading this mail is whether we can
> simply remove glk_force_audio_cdclk(false) in
> i915_audio_component_put_power().  In this way, a flicker should be
> reduced, at most only once at boot time, and the CDCLK is lowered only
> when the audio is really used (once).

If we could really limit this to actual first-time use (i.e. only if 
actual playback to HDMI/DP is done), that would be interesting compromise 
indeed, but as the ALSA side probe will call get_power, this will have 
limited benefit. I think this is in the end same as:

> Or, similarly, it can be put into *_component_bind() and *_unbind()
> instead of *_get_power() and *_put_power().  This indicates that the
> corresponding audio device really exists.

... doing it bind. But yes, you are right, bind() and unbind() would be 
the appropriate places. Then if audio driver is not loaded, the freq 
constraint is not put into effect, and similarly if audio driver is 
unloaded, cdclk constraint is released.

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

  reply	other threads:[~2020-03-10 11:20 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 [this message]
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
     [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.2003101234220.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).