From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 09/10] drm/i915: add support for checking RPM atomic sections
Date: Thu, 17 Dec 2015 00:53:15 +0200 [thread overview]
Message-ID: <1450306395.28091.13.camel@intel.com> (raw)
In-Reply-To: <20151216111853.GJ30437@phenom.ffwll.local>
On Wed, 2015-12-16 at 12:18 +0100, Daniel Vetter wrote:
> On Tue, Dec 15, 2015 at 08:10:37PM +0200, Imre Deak wrote:
> > In some cases we want to check whether we hold an RPM wakelock
> > reference
> > for the whole duration of a sequence. To achieve this add a new RPM
> > atomic sequence
> > counter that we increment any time the wakelock refcount drops to
> > zero.
> > Check whether the sequence number stays the same during the atomic
> > section and that we hold the wakelock at the beginning of the
> > section.
> >
> > Motivated by Chris.
> >
> > v2-v3:
> > - unchanged
> > v4:
> > - swap the order of atomic_read() and assert_rpm_wakelock_held() in
> > assert_rpm_atomic_begin() to avoid race
> >
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
>
> Can we employ lockdep for some of this? In general lockdep doesn't
> mesh
> with rpm references, since rpm references can be transferred between
> processes. And lockdep doesn't like that.
>
> But in many cases, and this one here sounds like one, we don't do
> that.
> And those cases could be annotated/validated with the help of
> lockdep.
> The bonus of lockdep is that we could then also tell lockdep that the
> rpm
> suspend/resume functionsa acquire this lock context, which would
> catch
> bugs like mutex_lock(dev->struct_mutex); before rpm_get().
>
> Just a thought really.
Yes, as I mentioned I also played with the idea and it could be done by
separating the RPM wakelock users into "prolonged" and short time
users. Yea, couldn't think of a better name. I explained what I mean in
the top three patch of:
https://github.com/ideak/linux/commits/rpm-lockdep-annotations
But I would still need to do more testing with this, making sure the
annotations work as expected, in particular that I call lock_acquire()
with the proper parameters. So until that we could use this simpler
check that could reveal some issues already now.
--Imre
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_drv.h | 17 +++++++++++++++++
> > drivers/gpu/drm/i915/intel_pm.c | 1 +
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 3 ++-
> > 4 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 2894716..00ce627 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1603,6 +1603,7 @@ struct skl_wm_level {
> > */
> > struct i915_runtime_pm {
> > atomic_t wakeref_count;
> > + atomic_t atomic_seq;
> > bool suspended;
> > bool irqs_enabled;
> > };
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index d8e4aca..88d37eb 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1446,6 +1446,23 @@ assert_rpm_wakelock_held(struct
> > drm_i915_private *dev_priv)
> > "RPM wakelock ref not held during HW access");
> > }
> >
> > +static inline int
> > +assert_rpm_atomic_begin(struct drm_i915_private *dev_priv)
> > +{
> > + int seq = atomic_read(&dev_priv->pm.atomic_seq);
> > +
> > + assert_rpm_wakelock_held(dev_priv);
> > +
> > + return seq;
> > +}
> > +
> > +static inline void
> > +assert_rpm_atomic_end(struct drm_i915_private *dev_priv, int
> > begin_seq)
> > +{
> > + WARN_ONCE(atomic_read(&dev_priv->pm.atomic_seq) !=
> > begin_seq,
> > + "HW access outside of RPM atomic section\n");
> > +}
> > +
> > /**
> > * disable_rpm_wakeref_asserts - disable the RPM assert checks
> > * @dev_priv: i915 device instance
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 6c08537..6eb9606 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7248,4 +7248,5 @@ void intel_pm_setup(struct drm_device *dev)
> >
> > dev_priv->pm.suspended = false;
> > atomic_set(&dev_priv->pm.wakeref_count, 0);
> > + atomic_set(&dev_priv->pm.atomic_seq, 0);
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 82c55a9..cee54ea 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2283,7 +2283,8 @@ void intel_runtime_pm_put(struct
> > drm_i915_private *dev_priv)
> > struct device *device = &dev->pdev->dev;
> >
> > assert_rpm_wakelock_held(dev_priv);
> > - atomic_dec(&dev_priv->pm.wakeref_count);
> > + if (atomic_dec_and_test(&dev_priv->pm.wakeref_count))
> > + atomic_inc(&dev_priv->pm.atomic_seq);
> >
> > pm_runtime_mark_last_busy(device);
> > pm_runtime_put_autosuspend(device);
> > --
> > 2.5.0
> >
> > _______________________________________________
> > 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:[~2015-12-16 22:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 18:10 [PATCH v4 00/10] drm/i915: improve the RPM device suspended assert Imre Deak
2015-12-15 18:10 ` [PATCH 01/10] drm/i915: clarify comment about mandatory RPM put/get during driver load/unload Imre Deak
2015-12-16 10:44 ` Joonas Lahtinen
2015-12-15 18:10 ` [PATCH 02/10] drm/i915: disable power well support on platforms without runtime PM support Imre Deak
2015-12-15 20:57 ` Ville Syrjälä
2015-12-15 22:55 ` Imre Deak
2015-12-16 11:12 ` Daniel Vetter
2015-12-16 13:21 ` Imre Deak
2015-12-16 17:31 ` Ville Syrjälä
2015-12-16 18:13 ` Imre Deak
2015-12-15 18:10 ` [PATCH 03/10] drm/i915: refactor RPM disabling due to RC6 being disabled Imre Deak
2015-12-16 10:54 ` Joonas Lahtinen
2015-12-16 11:01 ` Joonas Lahtinen
2015-12-15 18:10 ` [PATCH 04/10] drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers Imre Deak
2015-12-16 10:56 ` Joonas Lahtinen
2015-12-16 13:49 ` [PATCH 4.1/10] drm/i915: get a permanent RPM reference on platforms w/o RPM support Imre Deak
2015-12-16 13:53 ` [PATCH v2 " Imre Deak
2015-12-16 17:26 ` Ville Syrjälä
2015-12-16 18:22 ` Imre Deak
2015-12-17 11:44 ` [PATCH v3.1/10] " Imre Deak
2015-12-17 11:48 ` [PATCH v5 04/10] drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers Imre Deak
2015-12-17 12:46 ` Joonas Lahtinen
2015-12-15 18:10 ` [PATCH 05/10] drm/i915: add assert_rpm_wakelock_held helper Imre Deak
2015-12-16 12:11 ` Chris Wilson
2015-12-16 12:54 ` Imre Deak
2015-12-16 13:02 ` Chris Wilson
2015-12-16 13:39 ` Joonas Lahtinen
2015-12-16 13:43 ` Imre Deak
2015-12-15 18:10 ` [PATCH 06/10] drm/i915: use assert_rpm_wakelock_held instead of opencoding it Imre Deak
2015-12-15 18:10 ` [PATCH 07/10] drm/i915: add support for checking if we hold an RPM reference Imre Deak
2015-12-15 21:07 ` Chris Wilson
2015-12-15 22:52 ` Imre Deak
2015-12-16 0:14 ` Chris Wilson
2015-12-16 0:52 ` [PATCH v5 " Imre Deak
2015-12-15 18:10 ` [PATCH 08/10] drm/i915: check that we hold an RPM wakelock ref before we put it Imre Deak
2015-12-16 11:00 ` Joonas Lahtinen
2015-12-16 11:07 ` Chris Wilson
2015-12-16 12:49 ` Imre Deak
2015-12-15 18:10 ` [PATCH 09/10] drm/i915: add support for checking RPM atomic sections Imre Deak
2015-12-16 11:06 ` Joonas Lahtinen
2015-12-16 11:18 ` Daniel Vetter
2015-12-16 22:53 ` Imre Deak [this message]
2015-12-15 18:10 ` [PATCH 10/10] drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters Imre Deak
2015-12-17 14:44 ` [PATCH v4 00/10] drm/i915: improve the RPM device suspended assert 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=1450306395.28091.13.camel@intel.com \
--to=imre.deak@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.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.