Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: "José Roberto de Souza" <jose.souza@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915/icl: Release TC ports when unloading or suspending driver
Date: Wed, 28 Nov 2018 13:34:23 +0200	[thread overview]
Message-ID: <20181128113423.GC3349@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <20181108000554.18678-1-jose.souza@intel.com>

On Wed, Nov 07, 2018 at 04:05:52PM -0800, José Roberto de Souza wrote:
> When suspending or unloading the driver, it needs to release the
> TC ports so HW can change it state without wait for driver handshake.

According to 
https://bugs.freedesktop.org/show_bug.cgi?id=108070#c26

this patch should fix the bug reported at
https://bugs.freedesktop.org/show_bug.cgi?id=108070#c17

but, I can't see how the change here would fix the corresponding problem
described in
https://bugs.freedesktop.org/show_bug.cgi?id=108070#c18

Would you explain?

I think there are more fundamental problems in TypeC HPD handling as we
discussed earlier here on the list, which should be fixed first:

- Switching to/from type C mode from the interrupt handler without
  considering if we have an active mode or an ongoing AUX transfer.

- Not having any way for handling the case where we'd do a modeset after
  an HPD disconnect interrupt, like in the case of
  common-hpd-after-suspend in the bug report.

More comments below:

> 
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.c      |  1 +
>  drivers/gpu/drm/i915/i915_drv.h      |  1 +
>  drivers/gpu/drm/i915/i915_irq.c      |  1 +
>  drivers/gpu/drm/i915/intel_dp.c      | 19 +++++++++++++++++++
>  drivers/gpu/drm/i915/intel_drv.h     |  1 +
>  drivers/gpu/drm/i915/intel_hotplug.c |  9 +++++++++
>  6 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index acb516308262..14331c396278 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1911,6 +1911,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>  
>  	intel_runtime_pm_disable_interrupts(dev_priv);
>  	intel_hpd_cancel_work(dev_priv);
> +	intel_hpd_suspend(dev_priv);

What about runtime suspend? We won't receive HPD interrupts after that
either, so we'd need to disconnect in that case too according to the
spec.

And how are we handling resume then where we'll be in a disconnected
state due to the change in this patch and would continue to do a
modeset (to restore the mode we had before suspend).

>  
>  	intel_suspend_encoders(dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0c8438de3c1b..96d5ddc36f4e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2792,6 +2792,7 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
>  				   enum port port);
>  bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
> +void intel_hpd_suspend(struct drm_i915_private *dev_priv);
>  
>  /* i915_irq.c */
>  static inline void i915_queue_hangcheck(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d7e47d6082de..23084d227e2a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4996,6 +4996,7 @@ void intel_irq_uninstall(struct drm_i915_private *dev_priv)
>  {
>  	drm_irq_uninstall(&dev_priv->drm);
>  	intel_hpd_cancel_work(dev_priv);
> +	intel_hpd_suspend(dev_priv);
>  	dev_priv->runtime_pm.irqs_enabled = false;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5258c9d654f4..27c6163426d6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5043,6 +5043,25 @@ bool intel_digital_port_connected(struct intel_encoder *encoder)
>  	return false;
>  }
>  
> +/*
> + * intel_digital_port_force_disconnection - Used to force port disconnection or
> + * release any control from display driver before going to a state that driver
> + * will not handle interruptions.
> + */
> +void intel_digital_port_force_disconnection(struct intel_encoder *encoder)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +	struct intel_digital_port *dig_port;
> +
> +	dig_port = enc_to_dig_port(&encoder->base);
> +	/* Skip fake MST ports */
> +	if (!dig_port)
> +		return;
> +
> +	if (INTEL_GEN(dev_priv) >= 11)
> +		icl_tc_phy_disconnect(dev_priv, dig_port);
> +}
> +
>  static struct edid *
>  intel_dp_get_edid(struct intel_dp *intel_dp)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 6772e9974751..bc30f107b430 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1851,6 +1851,7 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
>  int intel_dp_link_required(int pixel_clock, int bpp);
>  int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
>  bool intel_digital_port_connected(struct intel_encoder *encoder);
> +void intel_digital_port_force_disconnection(struct intel_encoder *encoder);
>  
>  /* intel_dp_aux_backlight.c */
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c
> index 42e61e10f517..d6745b7b79d5 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -655,3 +655,12 @@ void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
>  	dev_priv->hotplug.stats[pin].state = HPD_ENABLED;
>  	spin_unlock_irq(&dev_priv->irq_lock);
>  }
> +
> +void intel_hpd_suspend(struct drm_i915_private *dev_priv)
> +{
> +	struct drm_device *dev = &dev_priv->drm;
> +	struct intel_encoder *encoder;
> +
> +	for_each_intel_encoder(dev, encoder)
> +		intel_digital_port_force_disconnection(encoder);
> +}
> -- 
> 2.19.1
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-11-28 11:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08  0:05 [PATCH 1/3] drm/i915/icl: Release TC ports when unloading or suspending driver José Roberto de Souza
2018-11-08  0:05 ` [PATCH 2/3] drm/i915: Call intel_hpd_cancel_work() from intel_hpd_suspend() José Roberto de Souza
2018-11-08  0:05 ` [PATCH 3/3] drm/i915/icl: Delay hotplug processing for tc ports José Roberto de Souza
2018-11-08  0:30 ` ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/icl: Release TC ports when unloading or suspending driver Patchwork
2018-11-08  0:49 ` ✓ Fi.CI.BAT: success " Patchwork
2018-11-08 14:01 ` ✓ Fi.CI.IGT: " Patchwork
2018-11-16 18:42 ` ✓ Fi.CI.BAT: " Patchwork
2018-11-28 11:34 ` Imre Deak [this message]
2018-11-28 21:54   ` [PATCH 1/3] " Souza, Jose
2018-11-29 13:52     ` Imre Deak
2018-11-29 20:18       ` Souza, Jose
2018-11-29 21:03         ` Imre Deak
2018-11-28 23:39 ` ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/icl: Release TC ports when unloading or suspending driver (rev2) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181128113423.GC3349@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jose.souza@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox