All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines
Date: Sun, 29 Sep 2019 23:25:54 +0300	[thread overview]
Message-ID: <20190929202554.GF2902@intel.intel> (raw)
In-Reply-To: <20190928100145.13165-1-chris@chris-wilson.co.uk>

Hi Chris,

> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1186,6 +1186,21 @@ static void execlists_submit_ports(struct intel_engine_cs *engine)
>  	/* we need to manually load the submit queue */
>  	if (execlists->ctrl_reg)
>  		writel(EL_CTRL_LOAD, execlists->ctrl_reg);
> +
> +	/*
> +	 * Now this is evil magic.
> +	 *
> +	 * Adding the same udelay() to process_csb before we clear
> +	 * execlists->pending (that is after we receive the HW ack for this
> +	 * submit and before we can submit again) does not relieve the symptoms
> +	 * (machine lockup). So is the active difference here the wait under
> +	 * the irq-off spinlock? That gives more credance to the theory that
> +	 * the issue is interrupt delivery. Also note that we still rely on
> +	 * disabling RPS, again that seems like an issue with simultaneous
> +	 * GT interrupts being delivered to the same CPU.
> +	 */
> +	if (IS_TIGERLAKE(engine->i915))
> +		udelay(250);

you want a delay of 250us. Two questions:

1. why 250?

2. is there any good reason for using 'udelay' for sleeping 250us
   (that is quite a long time) and not 'usleep'?

Thanks,
Andi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-09-29 20:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-28 10:01 [PATCH] drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines Chris Wilson
2019-09-28 10:20 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-09-28 10:43 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-28 20:03 ` ✓ Fi.CI.IGT: " Patchwork
2019-09-29 20:25 ` Andi Shyti [this message]
2019-09-30  7:43   ` [PATCH] " Chris Wilson
2019-09-30  9:11 ` [PATCH v2] drm/i915/tgl: Magic interrupt shadow to relieve some random lockups Chris Wilson
2019-09-30 12:02   ` Mika Kuoppala
2019-09-30 12:09     ` Chris Wilson
2019-09-30  9:57 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines (rev2) Patchwork
2019-09-30 10:23 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-30 12:20 ` ✓ Fi.CI.IGT: " 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=20190929202554.GF2902@intel.intel \
    --to=andi.shyti@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.