Hi Imre, Clinton, Am Wed, 4 Jul 2018 13:05:59 +0300 schrieb Imre Deak <imre.deak@xxxxxxxxx>: > On Tue, Jul 03, 2018 at 01:16:40PM -0700, clinton.a.taylor@xxxxxxxxx wrote: > > From: Clint Taylor <clinton.a.taylor@xxxxxxxxx> > > > > On GLK NUC platforms the HDMI retiming buffer needs additional disabled > > time to correctly sync to a faster incoming signal. > > > > When measured on a scope the highspeed lines of the HDMI clock turn off > > for ~400uS during a normal resolution change. The HDMI retimer on the > > GLK NUC appears to require at least a full frame of quiet time before a > > new faster clock can be correctly sync'd. Wait 100ms due to msleep > > inaccuracies while waiting for a completed frame. Add a quirk to the > > driver for GLK boards that use ITE66317 HDMI retimers. > > > > V2: Add more devices to the quirk list > > V3: Delay increased to 100ms, check to confirm crtc type is HDMI. > > V4: crtc type check extended to include _DDI and whitespace fixes > > > > Cc: Imre Deak <imre.deak@xxxxxxxxx> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887 > > Signed-off-by: Clint Taylor <clinton.a.taylor@xxxxxxxxx> > > --- > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > drivers/gpu/drm/i915/intel_ddi.c | 18 +++++++++++++++--- > > drivers/gpu/drm/i915/intel_display.c | 20 +++++++++++++++++++- > > drivers/gpu/drm/i915/intel_drv.h | 3 +-- > > 4 files changed, 36 insertions(+), 6 deletions(-) > > > > [...] > > val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK | TRANS_DDI_DP_VC_PAYLOAD_ALLOC); > > val |= TRANS_DDI_PORT_NONE; > > I915_WRITE(reg, val); > > + > > + if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME && > > + (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) || > > + intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DDI))) { > > Hm, INTEL_OUTPUT_DDI is not a possible output type, the whole encoder > enable/disable sequence would be broken with that. Even during module > loading/HW readout we should already set the proper HDMI/DP type in > intel_modeset_pipe_config(). > > Looking now at the bug report [1], the reporter is using an old kernel, > where we left encoder->type at INTEL_OUTPUT_UNKNOWN during HW readout > and set it correctly only after the first modeset. That could be > addressed by adding INTEL_OUTPUT_UNKNOWN when backporting the workaround, > but in this patch we should only check for INTEL_OUTPUT_HDMI. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=105887#c110 You're correct, this (INTEL_OUTPUT_UNKNOWN being set) indeed seems to be something with the i915 driver in kernel 4.15. I've just built a Kernel image/package from 4.17.4 with this patch applied, plus the DRM_ERROR print that logs the connector to the kernel log, and in fact on 4.17.x it's already on INTEL_OUTPUT_HDMI right after boot/driver load/hwinit (always 64), so for upstream the _UNKNOWN or _DDI check probably really isn't necessary. Posting links to the bug report in a second. Sorry for any troubles or additional work the _UNKNOWN report/suggestion might have caused. For v5, given that the logic won't change, feel free to add my Tested-by: Daniel Scheller <d.scheller.oss@xxxxxxxxx> Best regards, Daniel Scheller -- https://github.com/herrnst _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
