From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Cc: gregory.f.germano@intel.com,
Jonathan Cavitt <jonathan.cavitt@intel.com>,
Matt Roper <matthew.d.roper@intel.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [RFC PATCH] drm/i915/gt: Do not treat MCR locking timeouts as errors
Date: Wed, 4 Oct 2023 11:49:48 +0100 [thread overview]
Message-ID: <eefc8c62-1ac5-6604-2ee5-576ca87c2be5@linux.intel.com> (raw)
In-Reply-To: <20231004094357.634895-1-andi.shyti@linux.intel.com>
On 04/10/2023 10:43, Andi Shyti wrote:
> The MCR steering semaphore is a shared lock entry between i915
> and various firmware components.
>
> Getting the lock might sinchronize on some shared resources.
> Sometimes though, it might happen that the firmware forgets to
> unlock causing unnecessary noise in the driver which keeps doing
> what was supposed to do, ignoring the problem.
>
> Do not consider this failure as an error, but just print a debug
> message stating that the MCR locking has been skipped.
>
> On the driver side we still have spinlocks that make sure that
> the access to the resources is serialized.
>
> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Nirmoy Das <nirmoy.das@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 6 ++----
> 1 file changed, 2 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 326c2ed1d99b..51eb693df39b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -395,10 +395,8 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
> * would indicate some hardware/firmware is misbehaving and not
> * releasing it properly.
> */
> - if (err == -ETIMEDOUT) {
> - gt_err_ratelimited(gt, "hardware MCR steering semaphore timed out");
> - add_taint_for_CI(gt->i915, TAINT_WARN); /* CI is now unreliable */
> - }
> + if (err == -ETIMEDOUT)
> + gt_dbg(gt, "hardware MCR steering semaphore timed out");
> }
>
> /**
Are we sure this does not warrant a level higher than dbg, such as
notice/warn? Because how can we be sure the two entities will not stomp
on each other toes if we failed to obtain lock? (How can we be sure
about "forgot to unlock" vs "in prolonged active use"? Or if we can be
sure, can we force unlock and take the lock for the driver explicitly?)
Regards,
Tvrtko
next prev parent reply other threads:[~2023-10-04 10:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-04 9:43 [RFC PATCH] drm/i915/gt: Do not treat MCR locking timeouts as errors Andi Shyti
2023-10-04 10:49 ` Tvrtko Ursulin [this message]
2023-10-04 14:08 ` [Intel-gfx] " Andi Shyti
2023-10-04 19:19 ` John Harrison
2023-10-04 19:35 ` Andi Shyti
2023-10-04 19:50 ` John Harrison
2023-10-04 20:09 ` Andi Shyti
2023-10-04 21:15 ` John Harrison
2023-10-04 20:05 ` Matt Roper
2023-10-04 20:58 ` Andi Shyti
2023-10-04 21:21 ` John Harrison
2023-10-04 21:36 ` 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=eefc8c62-1ac5-6604-2ee5-576ca87c2be5@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregory.f.germano@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=nirmoy.das@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