From: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>,
<intel-gfx@lists.freedesktop.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/mtl: Add hardware-level lock for steering
Date: Fri, 2 Dec 2022 20:16:42 +0530 [thread overview]
Message-ID: <Y4oMtrT1nwFvihw/@bala-ubuntu> (raw)
In-Reply-To: <20221128233014.4000136-5-matthew.d.roper@intel.com>
On 28.11.2022 15:30, Matt Roper wrote:
> Starting with MTL, the driver needs to not only protect the steering
> control register from simultaneous software accesses, but also protect
> against races with hardware/firmware agents. The hardware provides a
> dedicated locking mechanism to support this via the MTL_STEER_SEMAPHORE
> register. Reading the register acts as a 'trylock' operation; the read
> will return 0x1 if the lock is acquired or 0x0 if something else is
> already holding the lock; once acquired, writing 0x1 to the register
> will release the lock.
>
> We'll continue to grab the software lock as well, just so lockdep can
> track our locking; assuming the hardware lock is behaving properly,
> there should never be any contention on the software lock in this case.
>
> v2:
> - Extend hardware semaphore timeout and add a taint for CI if it ever
> happens (this would imply misbehaving hardware/firmware). (Mika)
> - Add "MTL_" prefix to new steering semaphore register. (Mika)
>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Regards,
Bala
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 38 ++++++++++++++++++++++---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> 2 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index aa070ae57f11..087e4ac5b68d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -347,10 +347,9 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
> * @flags: storage to save IRQ flags to
> *
> * Performs locking to protect the steering for the duration of an MCR
> - * operation. Depending on the platform, this may be a software lock
> - * (gt->mcr_lock) or a hardware lock (i.e., a register that synchronizes
> - * access not only for the driver, but also for external hardware and
> - * firmware agents).
> + * operation. On MTL and beyond, a hardware lock will also be taken to
> + * serialize access not only for the driver, but also for external hardware and
> + * firmware agents.
> *
> * Context: Takes gt->mcr_lock. uncore->lock should *not* be held when this
> * function is called, although it may be acquired after this
> @@ -359,12 +358,40 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
> void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
> {
> unsigned long __flags;
> + int err = 0;
>
> lockdep_assert_not_held(>->uncore->lock);
>
> + /*
> + * Starting with MTL, we need to coordinate not only with other
> + * driver threads, but also with hardware/firmware agents. A dedicated
> + * locking register is used.
> + */
> + if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> + err = wait_for(intel_uncore_read_fw(gt->uncore,
> + MTL_STEER_SEMAPHORE) == 0x1, 100);
> +
> + /*
> + * Even on platforms with a hardware lock, we'll continue to grab
> + * a software spinlock too for lockdep purposes. If the hardware lock
> + * was already acquired, there should never be contention on the
> + * software lock.
> + */
> spin_lock_irqsave(>->mcr_lock, __flags);
>
> *flags = __flags;
> +
> + /*
> + * In theory we should never fail to acquire the HW semaphore; this
> + * would indicate some hardware/firmware is misbehaving and not
> + * releasing it properly.
> + */
> + if (err == -ETIMEDOUT) {
> + drm_err_ratelimited(>->i915->drm,
> + "GT%u hardware MCR steering semaphore timed out",
> + gt->info.id);
> + add_taint_for_CI(gt->i915, TAINT_WARN); /* CI is now unreliable */
> + }
> }
>
> /**
> @@ -379,6 +406,9 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
> void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags)
> {
> spin_unlock_irqrestore(>->mcr_lock, flags);
> +
> + if (GRAPHICS_VER(gt->i915) >= IP_VER(12, 70))
> + intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE, 0x1);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 784152548472..1618d46cb8c7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -67,6 +67,7 @@
> #define GMD_ID_MEDIA _MMIO(MTL_MEDIA_GSI_BASE + 0xd8c)
>
> #define MCFG_MCR_SELECTOR _MMIO(0xfd0)
> +#define MTL_STEER_SEMAPHORE _MMIO(0xfd0)
> #define MTL_MCR_SELECTOR _MMIO(0xfd4)
> #define SF_MCR_SELECTOR _MMIO(0xfd8)
> #define GEN8_MCR_SELECTOR _MMIO(0xfdc)
> --
> 2.38.1
>
next prev parent reply other threads:[~2022-12-02 14:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 23:30 [Intel-gfx] [PATCH v2 0/5] i915: dedicated MCR locking and hardware semaphore Matt Roper
2022-11-28 23:30 ` Matt Roper
2022-11-28 23:30 ` [Intel-gfx] [PATCH v2 1/5] drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg() Matt Roper
2022-11-28 23:30 ` Matt Roper
2022-11-30 15:42 ` [Intel-gfx] " Balasubramani Vivekanandan
2022-11-30 15:42 ` Balasubramani Vivekanandan
2022-11-28 23:30 ` [Intel-gfx] [PATCH v2 2/5] drm/i915/gt: Pass gt rather than uncore to lowest-level reads/writes Matt Roper
2022-11-28 23:30 ` Matt Roper
2022-11-30 15:43 ` [Intel-gfx] " Balasubramani Vivekanandan
2022-11-30 15:43 ` Balasubramani Vivekanandan
2022-11-28 23:30 ` [Intel-gfx] [PATCH v2 3/5] drm/i915/gt: Add dedicated MCR lock Matt Roper
2022-11-28 23:30 ` Matt Roper
2022-11-30 15:45 ` [Intel-gfx] " Balasubramani Vivekanandan
2022-11-30 15:45 ` Balasubramani Vivekanandan
2022-11-28 23:30 ` [Intel-gfx] [PATCH v2 4/5] drm/i915/mtl: Add hardware-level lock for steering Matt Roper
2022-11-28 23:30 ` Matt Roper
2022-12-02 14:46 ` Balasubramani Vivekanandan [this message]
2022-12-05 8:58 ` [Intel-gfx] " Tvrtko Ursulin
2022-12-05 15:52 ` Matt Roper
2022-12-05 18:16 ` Tvrtko Ursulin
2022-11-28 23:30 ` [Intel-gfx] [PATCH v2 5/5] drm/i915/mtl: Hold forcewake and MCR lock over PPAT setup Matt Roper
2022-11-28 23:30 ` Matt Roper
2022-11-30 15:51 ` [Intel-gfx] " Balasubramani Vivekanandan
2022-11-30 15:51 ` Balasubramani Vivekanandan
2022-11-30 15:58 ` [Intel-gfx] [PATCH v3 " Matt Roper
2022-11-30 15:58 ` Matt Roper
2022-12-01 9:26 ` [Intel-gfx] " Balasubramani Vivekanandan
2022-12-01 9:26 ` Balasubramani Vivekanandan
2022-12-01 21:01 ` [Intel-gfx] " Matt Roper
2022-12-01 21:01 ` Matt Roper
2022-11-30 16:05 ` [Intel-gfx] [PATCH v2 " Matt Roper
2022-11-30 16:05 ` Matt Roper
2022-11-29 0:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: dedicated MCR locking and hardware semaphore (rev2) Patchwork
2022-11-29 0:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-11-29 6:15 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-11-30 17:13 ` Matt Roper
2022-11-30 16:24 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: dedicated MCR locking and hardware semaphore (rev3) Patchwork
2022-11-30 16:46 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-11-30 22:40 ` Matt Roper
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=Y4oMtrT1nwFvihw/@bala-ubuntu \
--to=balasubramani.vivekanandan@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.d.roper@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.