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
next prev parent 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: linkBe 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.