Re: [Intel-gfx] [PATCH 3/3] drm/i915: Enable polling when we don't have hpd

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Jun 17, 2016 at 05:58:24PM -0400, Lyude wrote:
> Unfortunately, there's two situations where we lose hpd right now:
> - Runtime suspend
> - When we've shut off all of the power wells on Valleyview/Cherryview
> 
> While it would be nice if this didn't cause issues, this has the
> ability to get us in some awkward states where a user won't be able to
> get their display to turn on. For instance; if we boot a Valleyview
> system without any monitors connected, it won't need any of it's power
> wells and thus shut them off. Since this causes us to lose HPD, this
> means that unless the user knows how to ssh into their machine and do a
> manual reprobe for monitors, none of the monitors they connect after
> booting will actually work.
> 
> Eventually we should come up with a better fix then having to enable
> polling for this, since this makes rpm a lot less useful, but for now
> the infrastructure in i915 just isn't there yet to get hpd in these
> situations.
> 
> Cc: stable@vger.kernel.org
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Signed-off-by: Lyude <cpaul@redhat.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.c         |  7 +++-
>  drivers/gpu/drm/i915/i915_drv.h         |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h        |  2 +
>  drivers/gpu/drm/i915/intel_hotplug.c    | 69 ++++++++++++++++++++++++++++-----
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++
>  5 files changed, 73 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f313b4d..a593889 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1574,6 +1574,9 @@ static int intel_runtime_suspend(struct device *device)
>  
>  	assert_forcewakes_inactive(dev_priv);
>  
> +	if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
> +		intel_hpd_poll_enable(dev_priv, true);
> +
>  	DRM_DEBUG_KMS("Device suspended\n");
>  	return 0;
>  }
> @@ -1629,8 +1632,10 @@ static int intel_runtime_resume(struct device *device)
>  	 * power well, so hpd is reinitialized from there. For
>  	 * everyone else do it here.
>  	 */
> -	if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> +	if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
>  		intel_hpd_init(dev_priv);
> +		intel_hpd_poll_enable(dev_priv, false);
> +	}
>  
>  	intel_enable_gt_powersave(dev);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7c334e9..3062d55 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -281,6 +281,9 @@ struct i915_hotplug {
>  	u32 short_port_mask;
>  	struct work_struct dig_port_work;
>  
> +	struct work_struct poll_enable_work;
> +	bool poll_enabled;
> +
>  	/*
>  	 * if we get a HPD irq from DP and a HPD irq from non-DP
>  	 * the non-DP HPD could block the workqueue on a mode config
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index fdec45d..80cd626 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1348,6 +1348,8 @@ void intel_dsi_init(struct drm_device *dev);
>  
>  /* intel_dvo.c */
>  void intel_dvo_init(struct drm_device *dev);
> +/* intel_hotplug.c */
> +void intel_hpd_poll_enable(struct drm_i915_private *dev_priv, bool enabled);
>  
>  
>  /* legacy fbdev emulation in intel_fbdev.c */
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c
> index bee6730..0fc2fe0 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -465,20 +465,25 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
>  		dev_priv->hotplug.stats[i].count = 0;
>  		dev_priv->hotplug.stats[i].state = HPD_ENABLED;
>  	}
> -	list_for_each_entry(connector, &mode_config->connector_list, head) {
> -		struct intel_connector *intel_connector = to_intel_connector(connector);
> -		connector->polled = intel_connector->polled;
> +	if (!mode_config->poll_running) {

Why do we need this new condition?

> +		list_for_each_entry(connector, &mode_config->connector_list, head) {
> +			struct intel_connector *intel_connector =
> +				to_intel_connector(connector);
> +			connector->polled = intel_connector->polled;
>  
> -		/* MST has a dynamic intel_connector->encoder and it's reprobing
> -		 * is all handled by the MST helpers. */
> -		if (intel_connector->mst_port)
> -			continue;
> +			/* MST has a dynamic intel_connector->encoder and it's
> +			 * reprobing is all handled by the MST helpers. */
> +			if (intel_connector->mst_port)
> +				continue;
>  
> -		if (!connector->polled && I915_HAS_HOTPLUG(dev) &&
> -		    intel_connector->encoder->hpd_pin > HPD_NONE)
> -			connector->polled = DRM_CONNECTOR_POLL_HPD;
> +			if (!connector->polled && I915_HAS_HOTPLUG(dev) &&
> +			    intel_connector->encoder->hpd_pin > HPD_NONE)
> +				connector->polled = DRM_CONNECTOR_POLL_HPD;
> +		}
>  	}
>  
> +	intel_hpd_poll_enable(dev_priv, false);
> +
>  	/*
>  	 * Interrupt setup is already guaranteed to be single-threaded, this is
>  	 * just to make the assert_spin_locked checks happy.
> @@ -489,10 +494,54 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
>  	spin_unlock_irq(&dev_priv->irq_lock);
>  }
>  
> +void i915_hpd_poll_init_work(struct work_struct *work) {
> +	struct drm_i915_private *dev_priv =
> +		container_of(work, struct drm_i915_private,
> +			     hotplug.poll_enable_work);
> +	struct drm_device *dev = dev_priv->dev;
> +	struct intel_connector *intel_connector;
> +
> +	/* Don't let this run before we setup polling in the driver */
> +	if (!dev->mode_config.poll_enabled)
> +		return;

Same here, why this check? rpm/power-well handling only starts once the
driver is fully loaded. We unconditionally hold a ref to every power well
while loading the driver, to avoid such complications.

> +
> +	mutex_lock(&dev->mode_config.mutex);

One issue Ville noticed: When we go from polling->hpd we might have missed
a hotplug between the last poll round and before hpd was working again. So
for that case I think we need to manually probe everything once more.
Calling drm_helper_hpd_irq_event() should get the job done.

> +
> +	for_each_intel_connector(dev, intel_connector) {
> +		struct drm_connector *connector = &intel_connector->base;
> +
> +		if (dev_priv->hotplug.poll_enabled) {
> +			connector->polled = DRM_CONNECTOR_POLL_CONNECT |
> +				DRM_CONNECTOR_POLL_DISCONNECT;
> +
> +		} else if (!intel_connector->polled && I915_HAS_HOTPLUG(dev) &&
> +			   intel_connector->encoder->hpd_pin > HPD_NONE) {
> +			connector->polled = DRM_CONNECTOR_POLL_HPD;
> +		}
> +	}
> +
> +	if (dev_priv->hotplug.poll_enabled)
> +		drm_kms_helper_poll_enable_locked(dev);
> +
> +	mutex_unlock(&dev->mode_config.mutex);
> +}
> +
> +void intel_hpd_poll_enable(struct drm_i915_private *dev_priv, bool enabled)
> +{
> +	dev_priv->hotplug.poll_enabled = enabled;
> +
> +	/*
> +	 * We might already be holding dev->mode_config.mutex, so do this in a
> +	 * seperate worker
> +	 */
> +	schedule_work(&dev_priv->hotplug.poll_enable_work);

Need a cancel_work_sync in system suspend and driver unload paths to make
sure we don't leak this one here accidentlly.

Beside these nitpicks looks good, and if it works would be surprisingly
simple indeed. I'd say so better safe than sorry, and we should soak this
for at least 1 week in -next before cherry-picking over to -fixes. It is
rather risky, and the bug has been around since a long time so not worth
it much to rush too much.

Also, I'll be going on vacation. With the above issues addresss,
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> on the entire series.
-Daniel

> +}
> +
>  void intel_hpd_init_work(struct drm_i915_private *dev_priv)
>  {
>  	INIT_WORK(&dev_priv->hotplug.hotplug_work, i915_hotplug_work_func);
>  	INIT_WORK(&dev_priv->hotplug.dig_port_work, i915_digport_work_func);
> +	INIT_WORK(&dev_priv->hotplug.poll_enable_work, i915_hpd_poll_init_work);
>  	INIT_DELAYED_WORK(&dev_priv->hotplug.reenable_work,
>  			  intel_hpd_irq_storm_reenable_work);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 4a3fd3a..0090e88 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -986,6 +986,7 @@ static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
>  	if (dev_priv->power_domains.initializing)
>  		return;
>  
> +	intel_hpd_poll_enable(dev_priv, false);
>  	intel_hpd_init(dev_priv);
>  
>  	/* Re-enable the ADPA, if we have one */
> @@ -1007,6 +1008,8 @@ static void vlv_display_power_well_deinit(struct drm_i915_private *dev_priv)
>  	synchronize_irq(dev_priv->dev->irq);
>  
>  	vlv_power_sequencer_reset(dev_priv);
> +
> +	intel_hpd_poll_enable(dev_priv, true);
>  }
>  
>  static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
> -- 
> 2.5.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel