On 03/10/2016 12:08 AM, Maarten Lankhorst wrote:
Op 09-03-16 om 22:58 schreef clinton.a.taylor@xxxxxxxxx:From: Clint Taylor <clinton.a.taylor@xxxxxxxxx> WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected to DDI1 the system will hard hang during a cold boot. Occurs when DDI1 is enabled when the cdclk is less then required. DP connected to DDI2 and HPD on either port works correctly. Set cdclk based on the max required pixel clock based on VCO selected. Track boot vco instead of boot cdclk. The vco is now tracked at the atomic level and all CRTCs updated if the required vco is changed. Not tested with eDP v1.4 panels that require 8640 vco due to availability. V1: initial version V2: add vco tracking in intel_dp_compute_config(), rename skl_boot_cdclk. V3: rebase, V2 feedback not possible as encoders are not aware of atomic. V4: track target vco is atomic state. modeset all CRTCs if vco changes V5: rename atomic variable, cleaner if/else logic, use existing vco if encoder does not return a new vco value. check_patch.pl cleanup V6: simplify logic in intel_modeset_checks. V7: reorder an IF for readability and whitespace fix. V8: use dev_cdclk for tracking new cdclk during atomic Signed-off-by: Clint Taylor <clinton.a.taylor@xxxxxxxxx>Is the hang in the commit message introduced by this commit, or fixed by this commit?
The hang is introduced by this commit. The hang isn't reproducible using Arch Linux this appears to be an existing issue that is exposed for the first time now that cdclk can change on SKL. This warning will only affect ChromeOS users using drm-intel-nightly as the backport to ChromeOS removes many of the atomic specific changes. It's also very strange that the issue only affects the encoder attached to DDI1 and its computation of dev_cdclk during a cold boot.
~Maarten
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
