All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: "Ruhl, Michael J" <michael.j.ruhl@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Sripada, Radhakrishna" <radhakrishna.sripada@intel.com>
Subject: Re: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Date: Tue, 6 Sep 2022 10:08:37 -0700	[thread overview]
Message-ID: <Yxd+lQRGriwsyJjX@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <DM5PR11MB13245A45A7277B9548CADFB5C17E9@DM5PR11MB1324.namprd11.prod.outlook.com>

On Tue, Sep 06, 2022 at 06:39:14AM -0700, Ruhl, Michael J wrote:
> >-----Original Message-----
> >From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> >Matt Roper
> >Sent: Friday, September 2, 2022 7:33 PM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: dri-devel@lists.freedesktop.org; Sripada, Radhakrishna
> ><radhakrishna.sripada@intel.com>
> >Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
> >mmio_debug_{suspend, resume}
> >
> >Moving the locking for MMIO debug (and the final check for unclaimed
> >accesses when resuming debug after a userspace-initiated forcewake) will
> >make it simpler to completely skip MMIO debug handling on uncores that
> >don't support it in future patches.
> >
> >Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> >---
> > drivers/gpu/drm/i915/intel_uncore.c | 41 +++++++++++++++--------------
> > 1 file changed, 21 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> >b/drivers/gpu/drm/i915/intel_uncore.c
> >index 9b81b2543ce2..e717ea55484a 100644
> >--- a/drivers/gpu/drm/i915/intel_uncore.c
> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
> >@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
> >intel_uncore_mmio_debug *mmio_debug)
> > 	mmio_debug->unclaimed_mmio_check = 1;
> > }
> >
> >-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
> >*mmio_debug)
> >+static void mmio_debug_suspend(struct intel_uncore *uncore)
> 
> /bike-shedding...
> 
> It seems like there has been a tend to name functions with the
> 
> _unlocked
> 
> postfix when the lock is being taken within the function.
> 
> Would this be a reasonable name update for these changes?

I think foo_unlocked() naming is usually used when there's also a
separate foo() that can be called if/when locks are already held (or
sometimes it's foo() and foo_locked() if the situation is the other way
around).  In this case we still only have one version of the function,
and it's only called from a single place in the code
(intel_uncore_forcewake_user_get) so I don't think the special naming is
necessary.  It might actually add confusion here since there's a
different lock (the general uncore lock) that is still held by the
caller.  It's just the mmio_debug-specific lock that's been moved into
the mmio-debug specific function here.


Matt

> 
> M
> 
> > {
> >-	lockdep_assert_held(&mmio_debug->lock);
> >+	spin_lock(&uncore->debug->lock);
> >
> > 	/* Save and disable mmio debugging for the user bypass */
> >-	if (!mmio_debug->suspend_count++) {
> >-		mmio_debug->saved_mmio_check = mmio_debug-
> >>unclaimed_mmio_check;
> >-		mmio_debug->unclaimed_mmio_check = 0;
> >+	if (!uncore->debug->suspend_count++) {
> >+		uncore->debug->saved_mmio_check = uncore->debug-
> >>unclaimed_mmio_check;
> >+		uncore->debug->unclaimed_mmio_check = 0;
> > 	}
> >+
> >+	spin_unlock(&uncore->debug->lock);
> > }
> >
> >-static void mmio_debug_resume(struct intel_uncore_mmio_debug
> >*mmio_debug)
> >+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
> >+
> >+static void mmio_debug_resume(struct intel_uncore *uncore)
> > {
> >-	lockdep_assert_held(&mmio_debug->lock);
> >+	spin_lock(&uncore->debug->lock);
> >+
> >+	if (!--uncore->debug->suspend_count)
> >+		uncore->debug->unclaimed_mmio_check = uncore->debug-
> >>saved_mmio_check;
> >
> >-	if (!--mmio_debug->suspend_count)
> >-		mmio_debug->unclaimed_mmio_check = mmio_debug-
> >>saved_mmio_check;
> >+	if (check_for_unclaimed_mmio(uncore))
> >+		drm_info(&uncore->i915->drm,
> >+			 "Invalid mmio detected during user access\n");
> >+
> >+	spin_unlock(&uncore->debug->lock);
> > }
> >
> > static const char * const forcewake_domain_names[] = {
> >@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
> >intel_uncore *uncore)
> > 	spin_lock_irq(&uncore->lock);
> > 	if (!uncore->user_forcewake_count++) {
> > 		intel_uncore_forcewake_get__locked(uncore,
> >FORCEWAKE_ALL);
> >-		spin_lock(&uncore->debug->lock);
> >-		mmio_debug_suspend(uncore->debug);
> >-		spin_unlock(&uncore->debug->lock);
> >+		mmio_debug_suspend(uncore);
> > 	}
> > 	spin_unlock_irq(&uncore->lock);
> > }
> >@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
> >intel_uncore *uncore)
> > {
> > 	spin_lock_irq(&uncore->lock);
> > 	if (!--uncore->user_forcewake_count) {
> >-		spin_lock(&uncore->debug->lock);
> >-		mmio_debug_resume(uncore->debug);
> >-
> >-		if (check_for_unclaimed_mmio(uncore))
> >-			drm_info(&uncore->i915->drm,
> >-				 "Invalid mmio detected during user
> >access\n");
> >-		spin_unlock(&uncore->debug->lock);
> >-
> >+		mmio_debug_resume(uncore);
> > 		intel_uncore_forcewake_put__locked(uncore,
> >FORCEWAKE_ALL);
> > 	}
> > 	spin_unlock_irq(&uncore->lock);
> >--
> >2.37.2
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

WARNING: multiple messages have this Message-ID (diff)
From: Matt Roper <matthew.d.roper@intel.com>
To: "Ruhl, Michael J" <michael.j.ruhl@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
Date: Tue, 6 Sep 2022 10:08:37 -0700	[thread overview]
Message-ID: <Yxd+lQRGriwsyJjX@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <DM5PR11MB13245A45A7277B9548CADFB5C17E9@DM5PR11MB1324.namprd11.prod.outlook.com>

On Tue, Sep 06, 2022 at 06:39:14AM -0700, Ruhl, Michael J wrote:
> >-----Original Message-----
> >From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> >Matt Roper
> >Sent: Friday, September 2, 2022 7:33 PM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: dri-devel@lists.freedesktop.org; Sripada, Radhakrishna
> ><radhakrishna.sripada@intel.com>
> >Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
> >mmio_debug_{suspend, resume}
> >
> >Moving the locking for MMIO debug (and the final check for unclaimed
> >accesses when resuming debug after a userspace-initiated forcewake) will
> >make it simpler to completely skip MMIO debug handling on uncores that
> >don't support it in future patches.
> >
> >Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> >Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> >---
> > drivers/gpu/drm/i915/intel_uncore.c | 41 +++++++++++++++--------------
> > 1 file changed, 21 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> >b/drivers/gpu/drm/i915/intel_uncore.c
> >index 9b81b2543ce2..e717ea55484a 100644
> >--- a/drivers/gpu/drm/i915/intel_uncore.c
> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
> >@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
> >intel_uncore_mmio_debug *mmio_debug)
> > 	mmio_debug->unclaimed_mmio_check = 1;
> > }
> >
> >-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
> >*mmio_debug)
> >+static void mmio_debug_suspend(struct intel_uncore *uncore)
> 
> /bike-shedding...
> 
> It seems like there has been a tend to name functions with the
> 
> _unlocked
> 
> postfix when the lock is being taken within the function.
> 
> Would this be a reasonable name update for these changes?

I think foo_unlocked() naming is usually used when there's also a
separate foo() that can be called if/when locks are already held (or
sometimes it's foo() and foo_locked() if the situation is the other way
around).  In this case we still only have one version of the function,
and it's only called from a single place in the code
(intel_uncore_forcewake_user_get) so I don't think the special naming is
necessary.  It might actually add confusion here since there's a
different lock (the general uncore lock) that is still held by the
caller.  It's just the mmio_debug-specific lock that's been moved into
the mmio-debug specific function here.


Matt

> 
> M
> 
> > {
> >-	lockdep_assert_held(&mmio_debug->lock);
> >+	spin_lock(&uncore->debug->lock);
> >
> > 	/* Save and disable mmio debugging for the user bypass */
> >-	if (!mmio_debug->suspend_count++) {
> >-		mmio_debug->saved_mmio_check = mmio_debug-
> >>unclaimed_mmio_check;
> >-		mmio_debug->unclaimed_mmio_check = 0;
> >+	if (!uncore->debug->suspend_count++) {
> >+		uncore->debug->saved_mmio_check = uncore->debug-
> >>unclaimed_mmio_check;
> >+		uncore->debug->unclaimed_mmio_check = 0;
> > 	}
> >+
> >+	spin_unlock(&uncore->debug->lock);
> > }
> >
> >-static void mmio_debug_resume(struct intel_uncore_mmio_debug
> >*mmio_debug)
> >+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
> >+
> >+static void mmio_debug_resume(struct intel_uncore *uncore)
> > {
> >-	lockdep_assert_held(&mmio_debug->lock);
> >+	spin_lock(&uncore->debug->lock);
> >+
> >+	if (!--uncore->debug->suspend_count)
> >+		uncore->debug->unclaimed_mmio_check = uncore->debug-
> >>saved_mmio_check;
> >
> >-	if (!--mmio_debug->suspend_count)
> >-		mmio_debug->unclaimed_mmio_check = mmio_debug-
> >>saved_mmio_check;
> >+	if (check_for_unclaimed_mmio(uncore))
> >+		drm_info(&uncore->i915->drm,
> >+			 "Invalid mmio detected during user access\n");
> >+
> >+	spin_unlock(&uncore->debug->lock);
> > }
> >
> > static const char * const forcewake_domain_names[] = {
> >@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
> >intel_uncore *uncore)
> > 	spin_lock_irq(&uncore->lock);
> > 	if (!uncore->user_forcewake_count++) {
> > 		intel_uncore_forcewake_get__locked(uncore,
> >FORCEWAKE_ALL);
> >-		spin_lock(&uncore->debug->lock);
> >-		mmio_debug_suspend(uncore->debug);
> >-		spin_unlock(&uncore->debug->lock);
> >+		mmio_debug_suspend(uncore);
> > 	}
> > 	spin_unlock_irq(&uncore->lock);
> > }
> >@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
> >intel_uncore *uncore)
> > {
> > 	spin_lock_irq(&uncore->lock);
> > 	if (!--uncore->user_forcewake_count) {
> >-		spin_lock(&uncore->debug->lock);
> >-		mmio_debug_resume(uncore->debug);
> >-
> >-		if (check_for_unclaimed_mmio(uncore))
> >-			drm_info(&uncore->i915->drm,
> >-				 "Invalid mmio detected during user
> >access\n");
> >-		spin_unlock(&uncore->debug->lock);
> >-
> >+		mmio_debug_resume(uncore);
> > 		intel_uncore_forcewake_put__locked(uncore,
> >FORCEWAKE_ALL);
> > 	}
> > 	spin_unlock_irq(&uncore->lock);
> >--
> >2.37.2
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

  reply	other threads:[~2022-09-06 17:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-02 23:32 [PATCH v2 00/12] i915: Add "standalone media" support for MTL Matt Roper
2022-09-02 23:32 ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume} Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-06 13:39   ` Ruhl, Michael J
2022-09-06 13:39     ` [Intel-gfx] " Ruhl, Michael J
2022-09-06 17:08     ` Matt Roper [this message]
2022-09-06 17:08       ` Matt Roper
2022-09-06 17:10       ` Ruhl, Michael J
2022-09-06 17:10         ` [Intel-gfx] " Ruhl, Michael J
2022-09-02 23:32 ` [PATCH v2 02/12] drm/i915: Only hook up uncore->debug for primary uncore Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 03/12] drm/i915: Use managed allocations for extra uncore objects Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 04/12] drm/i915: Prepare more multi-GT initialization Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 05/12] drm/i915: Rename and expose common GT early init routine Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 06/12] drm/i915: Use a DRM-managed action to release the PCI bridge device Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 07/12] drm/i915: Initialize MMIO access for each GT Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 08/12] drm/i915: Handle each GT on init/release and suspend/resume Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:32 ` [PATCH v2 09/12] drm/i915/uncore: Add GSI offset to uncore Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-06 10:44   ` Iddamsetty, Aravind
2022-09-06 19:26     ` Matt Roper
2022-09-02 23:32 ` [PATCH v2 10/12] drm/i915/xelpmp: Expose media as another GT Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-06  8:57   ` Iddamsetty, Aravind
2022-09-06  8:57     ` [Intel-gfx] " Iddamsetty, Aravind
2022-09-02 23:32 ` [PATCH v2 11/12] drm/i915/mtl: Use primary GT's irq lock for media GT Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-03  3:29   ` kernel test robot
2022-09-02 23:32 ` [PATCH v2 12/12] drm/i915/mtl: Hook up interrupts for standalone media Matt Roper
2022-09-02 23:32   ` [Intel-gfx] " Matt Roper
2022-09-02 23:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Add "standalone media" support for MTL (rev3) Patchwork
2022-09-02 23:50 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-09-03  0:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-03  1:51 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=Yxd+lQRGriwsyJjX@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michael.j.ruhl@intel.com \
    --cc=radhakrishna.sripada@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 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.