[Intel-gfx] [PATCH 2/2] drm/i915: move audio CDCLK constraint setup to bind/unbind

[Kai Vehmanen]

Hey,

On Fri, 13 Mar 2020, Ville Syrjälä wrote:

> On Fri, Mar 13, 2020 at 04:48:21PM +0200, Kai Vehmanen wrote:
>> This patch moves modifying the min_cdclk at audio component bind
>> phase and extends coverage to all gen9+ platforms. This effectively
> 
> So this will now force BXT to never use the 144 MHz CDCLK too. Is that
> actually required? I don't remember any reports of failures on BXT.

yes it will force it higher.

I can't really explain why it works. 144Mhz is well above BCLK, so most of 
the time it will work, but it is still out of spec.

I do know that on more recent hardware (gen12), I will get failures if I 
don't strictly follow the requirement. GLK is a special case as it has the 
79Mhz low cdclk. I've not been able to trigger the problem on other old 
hardware though. So where to draw the line?

It's a fair point that if the old platforms have worked so far, we should 
not make the change unless there is at least one data point supporting it. 
So the constraint would then apply for gen12+ and glk.

Now thinking of another possibility, is it possible to hook code to 
power-up of power domains? E.g. can I hook custom code which is executed 
in sync with power wells going up and down?

If we could reprogram AUD_FREQ_CNTRL outside the get/put_power() flow 
(i.e. independently from audio driver), and guarantee that if the display 
side is powered on, the link params are always correct, it might be 
possible to get away without calling get_power() from audio controller 
reset. Worth a shot probably before we merge this.

>> +	if (INTEL_GEN(dev_priv) >= 9)
>> +		glk_force_audio_cdclk(dev_priv, true);
> 
> Ah, so we still keep it on the i915 side. That seems fine. We can then
> stop doing this once we get nicer hardware and put it back into to
> get/put power.

OTOH, if we restrict this to gen12+-and-glk, the glk_ prefix makes sense 
again.

Br, Kai