From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH] drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. Date: Thu, 04 Jan 2018 22:06:34 -0800 Message-ID: <2833053.qSqlkIgcHP@kirito> References: <20180104193805.3872-1-kenneth@whitecape.org> <2209082.bMokASrcsY@kirito> <20180105004135.pvx46g6mwpm5v3rp@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0977932399==" Return-path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id B4E236E2C0 for ; Fri, 5 Jan 2018 06:11:46 +0000 (UTC) In-Reply-To: <20180105004135.pvx46g6mwpm5v3rp@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Rodrigo Vivi Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org --===============0977932399== Content-Type: multipart/signed; boundary="nextPart1566249.NKaYIOeC83"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart1566249.NKaYIOeC83 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 > > > > 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 --nextPart1566249.NKaYIOeC83 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAlpPFeoACgkQW1vaBx1J zDibFhAAoQyHCe4akooSUmH10wSZVdSEaw59nEYYMveM7oB9huj2IuxRFZhDQ9yq XGgHgd5w0G4NI5KshnnrJb3aive3e7TvWerLNm/6FU2oG0B8WwfbUk6mZIiFjlLB jzh2phaV3K9tIrnXNYw6037PyfsTRBpemeX5xPhu2eFir+7SybeYGDeEJSRQiJGT ZCz+pEJFrIn9LykP4BwQquuBdUrYo6vYbezaxt1jzZHdMHac9ebVLfkAk6/JfJvt zfO57sRjV0hwxfTQlHeWfVXChR7YPbdeWy+5k8vVf2IZ60FSjkbyz/EijirjrMyB R/TtHMowNlXk7XiWLXQGcFiOu5B0itrkYcaxvkf2sASDPXlFqMBsMpdUw5756eQD yICe8o4JoSTNMnoxK1Isg0BmFJUqKatg8FF5i3mWwNK0VWVRgnzfHLQlO++qCTip oVa+Cndjun3i0EpFTxUjkz+sTxMPpkF5P2t9K6QAMtX5V5ctyGrSQ22VK6kYTF0S xYgwkaeTjnx+K0lASlG7v2Yo7fV/v1btVsk54WvfALgbyp5LICn7GfIm6R+BdgE5 05vOB9FX2f126y8qDomxRskx/AYIczEv6i1FFIk0CK0fv6/twziMGLL/OXfIlZ/2 GyT7WlJdsgTgQfziLE/Lkb0GF3/5GMwGQ189NLX+VGM5HvwWJC8= =unub -----END PGP SIGNATURE----- --nextPart1566249.NKaYIOeC83-- --===============0977932399== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0977932399==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp67.iad3a.emailsrvr.com ([173.203.187.67]:38082 "EHLO smtp67.iad3a.emailsrvr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751234AbeAEGLq (ORCPT ); Fri, 5 Jan 2018 01:11:46 -0500 From: Kenneth Graunke To: Rodrigo Vivi Cc: Chris Wilson , 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 Message-ID: <2833053.qSqlkIgcHP@kirito> In-Reply-To: <20180105004135.pvx46g6mwpm5v3rp@intel.com> References: <20180104193805.3872-1-kenneth@whitecape.org> <2209082.bMokASrcsY@kirito> <20180105004135.pvx46g6mwpm5v3rp@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1566249.NKaYIOeC83"; micalg="pgp-sha256"; protocol="application/pgp-signature" Sender: stable-owner@vger.kernel.org List-ID: --nextPart1566249.NKaYIOeC83 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 > > > > 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 --nextPart1566249.NKaYIOeC83 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAlpPFeoACgkQW1vaBx1J zDibFhAAoQyHCe4akooSUmH10wSZVdSEaw59nEYYMveM7oB9huj2IuxRFZhDQ9yq XGgHgd5w0G4NI5KshnnrJb3aive3e7TvWerLNm/6FU2oG0B8WwfbUk6mZIiFjlLB jzh2phaV3K9tIrnXNYw6037PyfsTRBpemeX5xPhu2eFir+7SybeYGDeEJSRQiJGT ZCz+pEJFrIn9LykP4BwQquuBdUrYo6vYbezaxt1jzZHdMHac9ebVLfkAk6/JfJvt zfO57sRjV0hwxfTQlHeWfVXChR7YPbdeWy+5k8vVf2IZ60FSjkbyz/EijirjrMyB R/TtHMowNlXk7XiWLXQGcFiOu5B0itrkYcaxvkf2sASDPXlFqMBsMpdUw5756eQD yICe8o4JoSTNMnoxK1Isg0BmFJUqKatg8FF5i3mWwNK0VWVRgnzfHLQlO++qCTip oVa+Cndjun3i0EpFTxUjkz+sTxMPpkF5P2t9K6QAMtX5V5ctyGrSQ22VK6kYTF0S xYgwkaeTjnx+K0lASlG7v2Yo7fV/v1btVsk54WvfALgbyp5LICn7GfIm6R+BdgE5 05vOB9FX2f126y8qDomxRskx/AYIczEv6i1FFIk0CK0fv6/twziMGLL/OXfIlZ/2 GyT7WlJdsgTgQfziLE/Lkb0GF3/5GMwGQ189NLX+VGM5HvwWJC8= =unub -----END PGP SIGNATURE----- --nextPart1566249.NKaYIOeC83--