All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/4] drm/i915: Fix system resume if PCI device remained enabled
Date: Mon, 18 Apr 2016 11:16:34 +0300	[thread overview]
Message-ID: <1460967394.3172.11.camel@intel.com> (raw)
In-Reply-To: <20160418080646.GD10708@nuc-i3427.alporthouse.com>

On ma, 2016-04-18 at 09:06 +0100, Chris Wilson wrote:
> On Mon, Apr 18, 2016 at 10:04:20AM +0300, Imre Deak wrote:
> > During system resume we depended on pci_enable_device() also
> > putting the
> > device into PCI D0 state. This won't work if the PCI device was
> > already
> > enabled but still in D3 state. This is because pci_enable_device()
> > is
> > refcounted and will not change the HW state if called with a non-
> > zero
> > refcount. Leaving the device in D3 will make all subsequent device
> > accesses fail.
> > 
> > This didn't cause a problem most of the time, since we resumed with
> > an
> > enable refcount of 0. But it fails at least after module reload
> > because
> > after that we also happen to leak a PCI device enable reference:
> > During
> > probing we call drm_get_pci_dev() which will enable the PCI device,
> > but
> > during device removal drm_put_dev() won't disable it. This is a bug
> > of
> > its own in DRM core, but without much harm as it only leaves the
> > PCI
> > device enabled. Fixing it is also a bit more involved, due to DRM
> > mid-layering and because it affects non-i915 drivers too. The fix
> > in
> > this patch is valid regardless of the problem in DRM core.
> > 
> > CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > CC: stable@vger.kernel.org
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index d550ae2..7eaa93e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -803,7 +803,7 @@ static int i915_drm_resume(struct drm_device
> > *dev)
> >  static int i915_drm_resume_early(struct drm_device *dev)
> >  {
> >  	struct drm_i915_private *dev_priv = dev->dev_private;
> > -	int ret = 0;
> > +	int ret;
> >  
> >  	/*
> >  	 * We have a resume ordering issue with the snd-hda driver
> > also
> > @@ -814,6 +814,13 @@ static int i915_drm_resume_early(struct
> > drm_device *dev)
> >  	 * FIXME: This should be solved with a special hdmi sink
> > device or
> >  	 * similar so that power domains can be employed.
> >  	 */
> > +
> > +	ret = pci_set_power_state(dev->pdev, PCI_D0);
> > +	if (ret) {
> > +		DRM_ERROR("failed to set PCI D0 power state
> > (%d)\n", ret);
> > +		goto out;
> > +	}
> 
> The device should be enabled first, otherwise we are not meant to be
> touching its IO space at all (such as twiddling power state). At
> least
> that is the order pci_enable_device() uses.

It's not MMIO or (port) IO but only a PCI config space access
that pci_set_power_state() requires, so doesn't need the enabling 
of PCI resources. AFAICS pci_enable_device() enables power as the first
thing.

> Either way, upon failure we should be unwinding.

I'd rather wouldn't put back the device to D3 state, as further device
access may still possible even though resume failed.

--Imre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix system resume if PCI device remained enabled
Date: Mon, 18 Apr 2016 11:16:34 +0300	[thread overview]
Message-ID: <1460967394.3172.11.camel@intel.com> (raw)
In-Reply-To: <20160418080646.GD10708@nuc-i3427.alporthouse.com>

On ma, 2016-04-18 at 09:06 +0100, Chris Wilson wrote:
> On Mon, Apr 18, 2016 at 10:04:20AM +0300, Imre Deak wrote:
> > During system resume we depended on pci_enable_device() also
> > putting the
> > device into PCI D0 state. This won't work if the PCI device was
> > already
> > enabled but still in D3 state. This is because pci_enable_device()
> > is
> > refcounted and will not change the HW state if called with a non-
> > zero
> > refcount. Leaving the device in D3 will make all subsequent device
> > accesses fail.
> > 
> > This didn't cause a problem most of the time, since we resumed with
> > an
> > enable refcount of 0. But it fails at least after module reload
> > because
> > after that we also happen to leak a PCI device enable reference:
> > During
> > probing we call drm_get_pci_dev() which will enable the PCI device,
> > but
> > during device removal drm_put_dev() won't disable it. This is a bug
> > of
> > its own in DRM core, but without much harm as it only leaves the
> > PCI
> > device enabled. Fixing it is also a bit more involved, due to DRM
> > mid-layering and because it affects non-i915 drivers too. The fix
> > in
> > this patch is valid regardless of the problem in DRM core.
> > 
> > CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > CC: stable@vger.kernel.org
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index d550ae2..7eaa93e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -803,7 +803,7 @@ static int i915_drm_resume(struct drm_device
> > *dev)
> >  static int i915_drm_resume_early(struct drm_device *dev)
> >  {
> >  	struct drm_i915_private *dev_priv = dev->dev_private;
> > -	int ret = 0;
> > +	int ret;
> >  
> >  	/*
> >  	 * We have a resume ordering issue with the snd-hda driver
> > also
> > @@ -814,6 +814,13 @@ static int i915_drm_resume_early(struct
> > drm_device *dev)
> >  	 * FIXME: This should be solved with a special hdmi sink
> > device or
> >  	 * similar so that power domains can be employed.
> >  	 */
> > +
> > +	ret = pci_set_power_state(dev->pdev, PCI_D0);
> > +	if (ret) {
> > +		DRM_ERROR("failed to set PCI D0 power state
> > (%d)\n", ret);
> > +		goto out;
> > +	}
> 
> The device should be enabled first, otherwise we are not meant to be
> touching its IO space at all (such as twiddling power state). At
> least
> that is the order pci_enable_device() uses.

It's not MMIO or (port) IO but only a PCI config space access
that pci_set_power_state() requires, so doesn't need the enabling 
of PCI resources. AFAICS pci_enable_device() enables power as the first
thing.

> Either way, upon failure we should be unwinding.

I'd rather wouldn't put back the device to D3 state, as further device
access may still possible even though resume failed.

--Imre

  reply	other threads:[~2016-04-18  8:16 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18  7:04 [PATCH 0/4] drm/i915: Fix a few suspend/resume and driver unload bugs Imre Deak
2016-04-18  7:04 ` [PATCH 1/4] drm/i915: Fix error path in i915_drm_resume_early Imre Deak
2016-04-18  8:00   ` Chris Wilson
2016-04-18  8:06     ` Imre Deak
2016-04-18  7:04 ` [PATCH 2/4] drm/i915: Fix system resume if PCI device remained enabled Imre Deak
2016-04-18  8:06   ` [Intel-gfx] " Chris Wilson
2016-04-18  8:06     ` Chris Wilson
2016-04-18  8:16     ` Imre Deak [this message]
2016-04-18  8:16       ` Imre Deak
2016-04-18  8:24       ` Chris Wilson
2016-04-18  8:24         ` Chris Wilson
2016-04-18  8:37         ` Imre Deak
2016-04-18  8:52           ` Chris Wilson
2016-04-18 11:05             ` Imre Deak
2016-04-18  8:28   ` Ville Syrjälä
2016-04-18  8:28     ` Ville Syrjälä
2016-04-18  8:32     ` Imre Deak
2016-04-18  8:44       ` Ville Syrjälä
2016-04-18  8:44         ` Ville Syrjälä
2016-04-18  8:54         ` Imre Deak
2016-04-18  9:04           ` Ville Syrjälä
2016-04-18  9:04             ` Ville Syrjälä
2016-04-18 11:44   ` [PATCH v2 " Imre Deak
2016-04-18 11:45   ` Imre Deak
2016-04-18 11:45     ` Imre Deak
2016-04-18 14:59     ` Ville Syrjälä
2016-04-18 14:59       ` Ville Syrjälä
2016-04-18  7:04 ` [PATCH 3/4] drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume Imre Deak
2016-04-18 11:05   ` Ville Syrjälä
2016-04-18 11:05     ` Ville Syrjälä
2016-04-18  7:04 ` [PATCH 4/4] drm/i915/gen9: Fix runtime PM refcounting in case DMC firmware isn't loaded Imre Deak
2016-04-18  7:49   ` Chris Wilson
2016-04-18  7:59     ` Imre Deak
2016-04-18 11:48   ` [PATCH v2 " Imre Deak
2016-04-18 12:07     ` Chris Wilson
2016-04-20 13:02     ` Daniel Vetter
2016-04-20 13:13       ` Imre Deak
2016-04-20 13:16         ` Daniel Vetter
2016-04-20 13:35           ` Imre Deak
2016-04-20 14:11             ` Daniel Vetter
2016-04-18  7:24 ` ✓ Fi.CI.BAT: success for drm/i915: Fix a few suspend/resume and driver unload bugs Patchwork
2016-04-18 13:57 ` ✗ Fi.CI.BAT: failure for drm/i915: Fix a few suspend/resume and driver unload bugs (rev3) Patchwork
2016-04-18 15:45   ` Imre Deak
2016-04-19  9:42     ` Imre Deak

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=1460967394.3172.11.camel@intel.com \
    --to=imre.deak@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.