Re: [PATCH v4] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

From: Daniel Scheller <d.scheller.oss@gmail.com>
To: imre.deak@intel.com, clinton.a.taylor@intel.com
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
Date: Wed, 4 Jul 2018 23:28:26 +0200	[thread overview]
Message-ID: <20180704232826.59fe5b71@lt530> (raw)
In-Reply-To: <20180704100559.GA25286@ideak-desk.fi.intel.com>

Hi Imre, Clinton,

Am Wed, 4 Jul 2018 13:05:59 +0300
schrieb Imre Deak <imre.deak@intel.com>:

> On Tue, Jul 03, 2018 at 01:16:40PM -0700, clinton.a.taylor@intel.com wrote:
> > From: Clint Taylor <clinton.a.taylor@intel.com>
> > 
> > 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@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
> > Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
> > ---
> >  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@gmail.com>

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx