[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