dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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