[Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

Kai Vehmanen kai.vehmanen at linux.intel.com
Tue Mar 10 11:20:07 UTC 2020


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


More information about the Intel-gfx mailing list