From: Kenneth Graunke <kenneth@whitecape.org>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.
Date: Thu, 04 Jan 2018 22:06:34 -0800 [thread overview]
Message-ID: <2833053.qSqlkIgcHP@kirito> (raw)
In-Reply-To: <20180105004135.pvx46g6mwpm5v3rp@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2784 bytes --]
On Thursday, January 4, 2018 4:41:35 PM PST Rodrigo Vivi wrote:
> On Thu, Jan 04, 2018 at 11:39:23PM +0000, Kenneth Graunke wrote:
> > On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2018-01-04 19:38:05)
> > > > Geminilake requires the 3D driver to select whether barriers are
> > > > intended for compute shaders, or tessellation control shaders, by
> > > > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
> > > > switching pipelines. Failure to do this properly can result in GPU
> > > > hangs.
> > > >
> > > > Unfortunately, this means it needs to switch mid-batch, so only
> > > > userspace can properly set it. To facilitate this, the kernel needs
> > > > to whitelist the register.
> > > >
> > > > Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
> > > > Cc: stable@vger.kernel.org
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++
> > > > 2 files changed, 7 insertions(+)
> > > >
> > > > Hello,
> > > >
> > > > We unfortunately need to whitelist an extra register for GPU hang fix
> > > > on Geminilake. Here's the corresponding Mesa patch:
> > >
> > > Thankfully it appears to be context saved. Has a w/a name been assigned
> > > for this?
> > > -Chris
> >
> > There doesn't appear to be one. The workaround page lists it, but there
> > is no name. The register description has a note saying that you need to
> > set this, but doesn't call it out as a workaround.
>
> It mentions only BXT:ALL, but not mention to GLK.
>
> Should we add to both then?
Well, that's irritating. On the workarounds page, it does indeed say
"BXT" with no mention of GLK. But the workaround text says to set
"SLICE_COMMON_CHICKEN_ECO1 Barrier Mode [...] (bit 7 of MMIO 0x731C)."
Looking at the register definition for SLICE_COMMON_ECO_CHICKEN1, bit 7
is "Barrier Mode" on [GLK] only, with no mention of BXT. It's marked
reserved PBC on [SKL+, not GLK, not KBL]. On KBL it's something else.
I believe Mark saw hangs in tessellation control shader hangs on
Geminilake only, and never saw this issue on Broxton. So, my guess is
that the workaround really is new on Geminilake, and the BXT tag on the
workarounds page is incorrect. (Mark, does that sound right to you?)
> > That's why I put a generic comment, rather than the name.
>
> On Display side we started using the row name for this case, to help
> easily finding this later.
>
> ex: "Display WA #0390: skl,kbl"
>
> The number for this apparently is:
> WA #0862
>
> Maybe we could use this one to start
> /* GT WA #0862: bxt,glk */
>
> GT? GEM?
> Unnamed WA #0862?
Including #0862 seems like a good idea. I'm happy to change the comment
to whatever you'd prefer.
--Ken
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Kenneth Graunke <kenneth@whitecape.org>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org, stable@vger.kernel.org,
mark.a.janes@intel.com
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.
Date: Thu, 04 Jan 2018 22:06:34 -0800 [thread overview]
Message-ID: <2833053.qSqlkIgcHP@kirito> (raw)
In-Reply-To: <20180105004135.pvx46g6mwpm5v3rp@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]
On Thursday, January 4, 2018 4:41:35 PM PST Rodrigo Vivi wrote:
> On Thu, Jan 04, 2018 at 11:39:23PM +0000, Kenneth Graunke wrote:
> > On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2018-01-04 19:38:05)
> > > > Geminilake requires the 3D driver to select whether barriers are
> > > > intended for compute shaders, or tessellation control shaders, by
> > > > whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
> > > > switching pipelines. Failure to do this properly can result in GPU
> > > > hangs.
> > > >
> > > > Unfortunately, this means it needs to switch mid-batch, so only
> > > > userspace can properly set it. To facilitate this, the kernel needs
> > > > to whitelist the register.
> > > >
> > > > Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
> > > > Cc: stable@vger.kernel.org
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > > drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++
> > > > 2 files changed, 7 insertions(+)
> > > >
> > > > Hello,
> > > >
> > > > We unfortunately need to whitelist an extra register for GPU hang fix
> > > > on Geminilake. Here's the corresponding Mesa patch:
> > >
> > > Thankfully it appears to be context saved. Has a w/a name been assigned
> > > for this?
> > > -Chris
> >
> > There doesn't appear to be one. The workaround page lists it, but there
> > is no name. The register description has a note saying that you need to
> > set this, but doesn't call it out as a workaround.
>
> It mentions only BXT:ALL, but not mention to GLK.
>
> Should we add to both then?
Well, that's irritating. On the workarounds page, it does indeed say
"BXT" with no mention of GLK. But the workaround text says to set
"SLICE_COMMON_CHICKEN_ECO1 Barrier Mode [...] (bit 7 of MMIO 0x731C)."
Looking at the register definition for SLICE_COMMON_ECO_CHICKEN1, bit 7
is "Barrier Mode" on [GLK] only, with no mention of BXT. It's marked
reserved PBC on [SKL+, not GLK, not KBL]. On KBL it's something else.
I believe Mark saw hangs in tessellation control shader hangs on
Geminilake only, and never saw this issue on Broxton. So, my guess is
that the workaround really is new on Geminilake, and the BXT tag on the
workarounds page is incorrect. (Mark, does that sound right to you?)
> > That's why I put a generic comment, rather than the name.
>
> On Display side we started using the row name for this case, to help
> easily finding this later.
>
> ex: "Display WA #0390: skl,kbl"
>
> The number for this apparently is:
> WA #0862
>
> Maybe we could use this one to start
> /* GT WA #0862: bxt,glk */
>
> GT? GEM?
> Unnamed WA #0862?
Including #0862 seems like a good idea. I'm happy to change the comment
to whatever you'd prefer.
--Ken
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-01-05 6:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 19:38 [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake Kenneth Graunke
2018-01-04 19:38 ` Kenneth Graunke
2018-01-04 20:24 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-01-04 21:23 ` [Intel-gfx] [PATCH] " Chris Wilson
2018-01-04 21:23 ` Chris Wilson
2018-01-04 23:39 ` Kenneth Graunke
2018-01-04 23:39 ` [Intel-gfx] " Kenneth Graunke
2018-01-05 0:41 ` Rodrigo Vivi
2018-01-05 0:41 ` [Intel-gfx] " Rodrigo Vivi
2018-01-05 6:06 ` Kenneth Graunke [this message]
2018-01-05 6:06 ` Kenneth Graunke
2018-01-05 6:53 ` Vivi, Rodrigo
2019-02-28 18:17 ` [Intel-gfx] " Chris Wilson
2018-01-04 21:53 ` ✗ Fi.CI.IGT: warning for " 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=2833053.qSqlkIgcHP@kirito \
--to=kenneth@whitecape.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
--cc=stable@vger.kernel.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.