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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
