[Intel-gfx] [PATCH] drm/i915: Avoid fluctuating to UNKNOWN connector status during forced probes

[Chris Wilson]

On Mon, Jun 15, 2015 at 03:03:39PM +0200, Daniel Vetter wrote:
> On Mon, Jun 15, 2015 at 01:35:21PM +0100, Chris Wilson wrote:
> > On Mon, Jun 15, 2015 at 02:29:28PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 05, 2015 at 08:46:19AM +0100, Chris Wilson wrote:
> > > > For old-school component TV and CRT connectors, we require a heavyweight
> > > > load-detection mechanism. This involves setting up a CRTC and sending a
> > > > signal to the output, before reading back any response. As that is quite
> > > > slow and CPU heavy, the process is only performed when the output
> > > > detection is forced by user request. As it requires a driving CRTC, we
> > > > often don't have the resources to complete the probe. This leaves us in
> > > > a quandary where the unforced path just returns the old connector
> > > > status, but the forced detection path elects to return UNKNOWN. If we
> > > > have an active connection, we likely have the resources available to
> > > > complete the probe - but if it is currently disconnected, then it
> > > > becomes unknown and triggers a hotplug event, with often quite unfortunate
> > > > userspace behaviour (e.g. one output is blanked and the spurious TV
> > > > turned on).
> > > > 
> > > > To reduce spurious hotplug events on older devices, we can prevent
> > > > transitions between disconnected <-> unknown.
> > > > 
> > > > v2: Convert tv_type to use proper unknown enum (Ville)
> > > > 
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=87049
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> [v1]
> > > > Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com> [v1]
> > > 
> > > This solution is at odds with
> > > 
> > > commit b7703726251191cd9f3ef3a80b2d9667901eec95
> > > Author: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > Date:   Wed Jan 21 08:45:22 2015 +0100
> > > 
> > >     drm/probe-helper: clamp unknown connector status in the poll work
> > > 
> > > We're missing this bit of logic from the hotplug handlers, but that was
> > > somewhat intentional since a hotplug should indicate that something has
> > > changed. And in the i915 hpd handler we filter by source.
> > > 
> > > Given that the report is older than me having resurrect that patch can we
> > > close it as fixed or do I miss something?
> > 
> > It's a different path. This also concerns the actual forced reprobe
> > fluctuating between two states.
> 
> In that case I still think it should be in the probe helpers. Which raises
> the policy decision whether we should ever hand unkown back to userspace
> since apparently it just can't cope sensible with it. But that call should
> be done consistently accross drivers.

Hmm, the probe helper is not the central arbiter here which is a problem
in moving it entirely into its domain. UNKNOWN makes a sense form the hw
perspective, and we still need to report that status before any probes
are made at all (whether that is init/resume) and the problem in this
case is not so much as userspace mishandling it, but the fluctuation
between UNKNOWN/DISCONNECTED is causing activity and reconfiguration not
entirely of its own fault.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre