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

Kai Vehmanen kai.vehmanen at linux.intel.com
Tue Mar 24 15:52:27 UTC 2020


Hi Ville and others,

On Fri, 13 Mar 2020, Kai Vehmanen wrote:

> 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.

given the not-so-great options on the table, I went back (again) looking 
for other solutions and came with a curious finding. The forced Codec Wake 
interface added to gen9 in 2015, seems to fix the gen12 codec probe issues 
as well, without the cdclk bump.

So it looks like the problem is not about the CDCLK being high enough, but 
something in hardware state that is fixed by doing a modeset. Or, as it 
seems to be the case, by using the chickebits to force the codec wake (and 
no need for modeset).

Based on hw specs, there is no valid reason to limit the forced codec wake 
only to gen9, so I went and sent a patch for this now. I've tested this on 
various gen9/10/11/12 platforms and also asked our validation to test it 
out, and seems everything seems good.

I also tried an experiment where I added the codec wake patch, but removed 
the forced cdclk bump on GLK, but that still fails, so on GLK, the CDCLK 
bump is still mandatory, and likely a separate problem. So this doesn't 
solve all the problems, but at least we can fix the currently reported 
bugs without causing any new compromises at system level.

Br, Kai


More information about the Intel-gfx mailing list