On Tue, 10 Apr 2018, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > On Mon, 09 Apr 2018, "Kumar, Abhay" <abhay.kumar@xxxxxxxxx> 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. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
