From: Imre Deak <imre.deak@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 24/25] drm/i915: propagate the error code from runtime PM callbacks
Date: Mon, 05 May 2014 16:18:49 +0300 [thread overview]
Message-ID: <1399295929.7584.5.camel@ideak-mobl> (raw)
In-Reply-To: <20140505124448.GY18465@intel.com>
On Mon, 2014-05-05 at 15:44 +0300, Ville Syrjälä wrote:
> On Wed, Apr 30, 2014 at 09:53:08PM +0300, Imre Deak wrote:
> > On Wed, 2014-04-30 at 21:05 +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 15, 2014 at 04:39:45PM +0300, Imre Deak wrote:
> > > > Atm, none of the RPM callbacks can fail, but the next patch adding
> > > > RPM support for VLV changes this, so prepare for it.
> > > >
> > > > In case one of these callbacks return error RPM will get permanently
> > > > disabled until the error is explicitly cleared. In the future we could
> > > > add support for re-enabling it, for example after resetting the HW, but
> > > > for now - hopefully - we can live with the simpler solution.
> > > >
> > > > v2:
> > > > - propagate the error from the resume callbacks too (Paulo)
> > > > v3:
> > > > - fix rebase fail typo around IS_GEN6() check in intel_runtime_suspend()
> > > >
> > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.c | 57 ++++++++++++++++++++++++++++++-----------
> > > > 1 file changed, 42 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 845e1e1..aeb7dec 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -888,21 +888,27 @@ static int i915_pm_poweroff(struct device *dev)
> > > > return i915_drm_freeze(drm_dev);
> > > > }
> > > >
> > > > -static void hsw_runtime_suspend(struct drm_i915_private *dev_priv)
> > > > +static int hsw_runtime_suspend(struct drm_i915_private *dev_priv)
> > > > {
> > > > hsw_enable_pc8(dev_priv);
> > > > +
> > > > + return 0;
> > > > }
> > > >
> > > > -static void snb_runtime_resume(struct drm_i915_private *dev_priv)
> > > > +static int snb_runtime_resume(struct drm_i915_private *dev_priv)
> > > > {
> > > > struct drm_device *dev = dev_priv->dev;
> > > >
> > > > intel_init_pch_refclk(dev);
> > > > +
> > > > + return 0;
> > > > }
> > > >
> > > > -static void hsw_runtime_resume(struct drm_i915_private *dev_priv)
> > > > +static int hsw_runtime_resume(struct drm_i915_private *dev_priv)
> > > > {
> > > > hsw_disable_pc8(dev_priv);
> > > > +
> > > > + return 0;
> > > > }
> > > >
> > > > int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool force_on)
> > > > @@ -947,6 +953,7 @@ static int intel_runtime_suspend(struct device *device)
> > > > struct pci_dev *pdev = to_pci_dev(device);
> > > > struct drm_device *dev = pci_get_drvdata(pdev);
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + int ret;
> > > >
> > > > if (WARN_ON_ONCE(!(dev_priv->rps.enabled && intel_enable_rc6(dev))))
> > > > return -ENODEV;
> > > > @@ -959,12 +966,21 @@ static int intel_runtime_suspend(struct device *device)
> > > > intel_runtime_pm_disable_interrupts(dev);
> > > > cancel_work_sync(&dev_priv->rps.work);
> > > >
> > > > - if (IS_GEN6(dev))
> > > > - ;
> > > > - else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> > > > - hsw_runtime_suspend(dev_priv);
> > > > - else
> > > > + if (IS_GEN6(dev)) {
> > > > + ret = 0;
> > > > + } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> > > > + ret = hsw_runtime_suspend(dev_priv);
> > > > + } else {
> > > > + ret = -ENODEV;
> > > > WARN_ON(1);
> > > > + }
> > > > +
> > > > + if (ret) {
> > > > + DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
> > > > + intel_runtime_pm_restore_interrupts(dev);
> > > > +
> > > > + return ret;
> > > > + }
> > > >
> > > > i915_gem_release_all_mmaps(dev_priv);
> > >
> > > Not strictly related to this patch, but shouldn't we nuke the mmaps before
> > > calling the platform specific runtime suspend function?
> >
> > We take an RPM ref on the fault path, so at least this couldn't race
> > with user space either way. But if you meant that the platform hooks
> > could save/restore some stale state because of this ordering, then I
> > agree it'd be safer to move it before calling the platform hook. But I
> > don't see what this state would be.
>
> My main worry is that something may get turned off in the platform
> specific code which is required by the hardware to service GTT
> accesses. A concurrect GTT access may then happen after the platform
> spefic code has turned off the hardware but before the mmaps have been
> released and hence there's no fault when the access happens.
Right, for existing maps this may be a problem. I'll follow-up with a
patch moving i915_gem_release_all_mmaps() earlier.
> > --Imre
> >
> > > This patch itself looks ok to me:
> > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > >
> > > > @@ -989,6 +1005,7 @@ static int intel_runtime_resume(struct device *device)
> > > > struct pci_dev *pdev = to_pci_dev(device);
> > > > struct drm_device *dev = pci_get_drvdata(pdev);
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + int ret;
> > > >
> > > > WARN_ON(!HAS_RUNTIME_PM(dev));
> > > >
> > > > @@ -997,21 +1014,31 @@ static int intel_runtime_resume(struct device *device)
> > > > intel_opregion_notify_adapter(dev, PCI_D0);
> > > > dev_priv->pm.suspended = false;
> > > >
> > > > - if (IS_GEN6(dev))
> > > > - snb_runtime_resume(dev_priv);
> > > > - else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> > > > - hsw_runtime_resume(dev_priv);
> > > > - else
> > > > + if (IS_GEN6(dev)) {
> > > > + ret = snb_runtime_resume(dev_priv);
> > > > + } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> > > > + ret = hsw_runtime_resume(dev_priv);
> > > > + } else {
> > > > WARN_ON(1);
> > > > + ret = -ENODEV;
> > > > + }
> > > >
> > > > + /*
> > > > + * No point of rolling back things in case of an error, as the best
> > > > + * we can do is to hope that things will still work (and disable RPM).
> > > > + */
> > > > i915_gem_init_swizzling(dev);
> > > > gen6_update_ring_freq(dev);
> > > > intel_reset_gt_powersave(dev);
> > > >
> > > > intel_runtime_pm_restore_interrupts(dev);
> > > >
> > > > - DRM_DEBUG_KMS("Device resumed\n");
> > > > - return 0;
> > > > + if (ret)
> > > > + DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
> > > > + else
> > > > + DRM_DEBUG_KMS("Device resumed\n");
> > > > +
> > > > + return ret;
> > > > }
> > > >
> > > > static const struct dev_pm_ops i915_pm_ops = {
> > > > --
> > > > 1.8.4
> > > >
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> >
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-05-05 13:18 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 17:24 [PATCH v2 00/25] vlv: add support for RPM Imre Deak
2014-04-14 17:24 ` [PATCH v2 01/25] drm/i915: vlv: clean up GTLC wake control/status register macros Imre Deak
2014-04-24 21:04 ` Rodrigo Vivi
2014-04-14 17:24 ` [PATCH v2 02/25] drm/i915: vlv: clear master interrupt flag when disabling interrupts Imre Deak
2014-04-14 17:24 ` [PATCH v2 03/25] drm/i915: vlv: add RC6 residency counters Imre Deak
2014-04-14 17:24 ` [PATCH v2 04/25] drm/i915: fix the RC6 status debug print Imre Deak
2014-04-14 17:24 ` [PATCH v2 05/25] drm/i915: remove the i915_dpio debugfs entry Imre Deak
2014-04-14 17:24 ` [PATCH v2 06/25] drm/i915: get a runtime PM ref for debugfs entries where needed Imre Deak
2014-04-14 17:24 ` [PATCH v2 07/25] drm/i915: move getting struct_mutex lower in the callstack during GPU reset Imre Deak
2014-04-14 17:24 ` [PATCH v2 08/25] drm/i915: get a runtime PM ref for the deferred GT powersave enabling Imre Deak
2014-04-25 7:59 ` Daniel Vetter
2014-04-25 8:14 ` Imre Deak
2014-04-25 9:09 ` Daniel Vetter
2014-04-25 8:01 ` Daniel Vetter
2014-04-14 17:24 ` [PATCH v2 09/25] drm/i915: get a runtime PM ref for the deferred GPU reset work Imre Deak
2014-04-16 12:11 ` Ville Syrjälä
2014-04-18 12:47 ` [PATCH v3] " Imre Deak
2014-04-22 19:38 ` Daniel Vetter
2014-04-22 20:34 ` Imre Deak
2014-04-22 21:05 ` Daniel Vetter
2014-04-22 22:13 ` [PATCH v4] " Imre Deak
2014-04-23 7:07 ` Daniel Vetter
2014-04-23 7:52 ` Imre Deak
2014-04-25 8:00 ` Daniel Vetter
2014-04-14 17:24 ` [PATCH v2 10/25] drm/i915: gen2: move error capture of IER to its correct place Imre Deak
2014-04-16 12:22 ` Ville Syrjälä
2014-04-16 12:57 ` Imre Deak
2014-04-24 21:06 ` Rodrigo Vivi
2014-04-14 17:24 ` [PATCH v2 11/25] drm/i915: add missing error capturing of the PIPESTAT reg Imre Deak
2014-04-16 12:17 ` Ville Syrjälä
2014-04-18 11:44 ` Imre Deak
2014-04-18 12:55 ` [PATCH v3 " Imre Deak
2014-04-23 7:53 ` Ville Syrjälä
2014-04-14 17:24 ` [PATCH v2 12/25] drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on Imre Deak
2014-04-14 17:24 ` [PATCH v2 13/25] drm/i915: fix unbalanced GT powersave enable / disable calls Imre Deak
2014-04-14 17:24 ` [PATCH v2 14/25] drm/i915: sanitize enable_rc6 option Imre Deak
2014-04-16 12:28 ` Ville Syrjälä
2014-04-16 12:37 ` Imre Deak
2014-04-18 13:01 ` [PATCH v3 " Imre Deak
2014-04-23 7:58 ` Ville Syrjälä
2014-04-14 17:24 ` [PATCH v2 15/25] drm/i915: disable runtime PM if RC6 is disabled Imre Deak
2014-04-14 17:24 ` [PATCH v2 16/25] drm/i915: make runtime PM interrupt enable/disable platform independent Imre Deak
2014-04-14 17:24 ` [PATCH v2 17/25] drm/i915: factor out gen6_update_ring_freq Imre Deak
2014-04-16 17:31 ` Ville Syrjälä
2014-04-18 13:16 ` [PATCH v3 " Imre Deak
2014-04-23 7:59 ` Ville Syrjälä
2014-04-14 17:24 ` [PATCH v2 18/25] drm/i915: make runtime PM swizzling/ring_freq init platform independent Imre Deak
2014-04-14 17:24 ` [PATCH v2 19/25] drm/i915: reinit GT power save during resume Imre Deak
2014-04-16 17:46 ` Ville Syrjälä
2014-04-18 10:51 ` Imre Deak
2014-04-22 17:21 ` [PATCH v3 " Imre Deak
2014-04-23 8:06 ` Ville Syrjälä
2014-04-14 17:24 ` [PATCH v2 20/25] drm/i915: vlv: setup RPS min/max frequencies once during init time Imre Deak
2014-04-14 17:24 ` [PATCH v2 21/25] drm/i915: vlv: factor out vlv_force_gfx_clock Imre Deak
2014-04-16 17:49 ` Ville Syrjälä
2014-04-18 13:35 ` [PATCH v3 21/25] drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-off Imre Deak
2014-04-23 8:11 ` Ville Syrjälä
2014-04-14 17:24 ` [PATCH v2 22/25] drm/i915: vlv: increase timeout when forcing on the GFX clock Imre Deak
2014-04-25 14:04 ` Daniel Vetter
2014-04-14 17:24 ` [PATCH v2 23/25] drm/i915: add various missing GTI/Gunit register definitions Imre Deak
2014-04-24 21:17 ` Rodrigo Vivi
2014-04-24 21:49 ` Imre Deak
2014-04-30 14:32 ` Ville Syrjälä
2014-05-05 11:43 ` Imre Deak
2014-05-05 12:13 ` [PATCH v3 " Imre Deak
2014-05-05 12:21 ` Ville Syrjälä
2014-04-14 17:24 ` [PATCH v2 24/25] drm/i915: propagate the error code from runtime PM callbacks Imre Deak
2014-04-15 13:39 ` [PATCH v3 " Imre Deak
2014-04-30 18:05 ` Ville Syrjälä
2014-04-30 18:53 ` Imre Deak
2014-05-05 12:44 ` Ville Syrjälä
2014-05-05 13:18 ` Imre Deak [this message]
2014-04-14 17:24 ` [PATCH v2 25/25] drm/i915: vlv: add runtime PM support Imre Deak
2014-04-16 12:39 ` Ville Syrjälä
2014-04-16 14:53 ` Daniel Vetter
2014-04-16 16:01 ` Imre Deak
2014-04-22 17:28 ` [PATCH v3 " Imre Deak
2014-04-22 22:09 ` [PATCH v4] drm/i915: get a runtime PM ref for the deferred GPU reset work Imre Deak
2014-04-24 21:02 ` Rodrigo Vivi
2014-04-30 17:35 ` [PATCH v3 25/25] drm/i915: vlv: add runtime PM support Ville Syrjälä
2014-05-05 9:33 ` Daniel Vetter
2014-05-05 12:19 ` [PATCH v4 " Imre Deak
2014-04-14 17:41 ` [PATCH v2 26/25] drm/i915: vlv: enable runtime PM Imre Deak
2014-05-06 19:39 ` Daniel Vetter
2014-04-17 11:00 ` [PATCH v2 00/25] vlv: add support for RPM Ville Syrjälä
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=1399295929.7584.5.camel@ideak-mobl \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.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