On Tue, 10 Apr 2018, Jani Nikula <jani.nik...@intel.com> wrote:
> On Mon, 09 Apr 2018, "Kumar, Abhay" <abhay.ku...@intel.com> wrote:
>> Dynamic cdclk is disabled in BIOS/GOP hence gop makes it to highest 
>> clock i.e 316.8. Will attach logs with drm debug enabled in bug.
>> I am also inclined towards 192 which will make max cdclk..
> Please also attach /sys/kernel/debug/dri/0/i915_vbt to the bug.
> It doesn't look like we look at the VBT dynamic cdclk field. Does
> dynamic debug disabled mean we should go for max?

Ville, I tried to look at how to disable dynamic cdclk for some
platforms based on the VBT, but it gets a bit hairy. The code seems
pretty wired for going to lowest possible. I've got the trivial VBT
parsing part, but plugging that into the cdclk code in a clean way that
could *also* be backported to stable is driving me nuts. Any ideas? I'd
like to fix the issue first, and (then have you ;) embark on the
refactoring afterwards.

It's trivial to plug the check into intel_crtc_compute_min_cdclk() and
return dev_priv->max_cdclk_freq, but a) I think that place should be
reserved for crtc_state related limitations, and seems the completely
wrong place to do system level things, b) it's not optimal to go through
all the cdclk code to do nothing in the end, and c) it doesn't work for
the no crtc's active case at init time.

Just setting the .set_cdclk and .modeset_calc_cdclk hooks to NULL was
another idea, but the hooks get initialized before VBT parsing. And I
don't think that works for init either.


Jani Nikula, Intel Open Source Technology Center
Intel-gfx mailing list

Reply via email to