From: Kenneth Graunke <kenneth@whitecape.org>
To: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
Matt Roper <matthew.d.roper@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/gt: Remove bogus comment on IVB_FBC_RT_BASE_UPPER
Date: Tue, 27 Jun 2023 11:30:26 -0700 [thread overview]
Message-ID: <1781954.dNn8tgRAG2@mizzik> (raw)
In-Reply-To: <20230624171757.3906095-7-lucas.demarchi@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
On Saturday, June 24, 2023 10:17:57 AM PDT Lucas De Marchi wrote:
> The comment on the parameter being 0 to avoid the read back doesn't
> apply as this is not a call to wa_mcr_add(), but rather to
> wa_mcr_clr_set(). So, this register is actually checked and it's
> according to the Bspec that the register is RW, not RO.
I think you mean wa_add and wa_write_clr_set here (not mcr).
One thing I've been confused about while reading this code:
static void
wa_write_clr_set(struct i915_wa_list *wal, i915_reg_t reg, u32 clear, u32 set)
{
wa_add(wal, reg, clear, set, clear, false);
}
The second to last parameter is read_mask aka wa->read. We're
initializing it to the...bits to clear. (I would think it should be
(clear | set) to pick up all modified bits.)
wa_verify seems to balk at ((cur ^ wa->set) & wa->read). But...if
wa->read is just the clear mask, that wouldn't actually verify that
any bits were set at all. Or am I misunderstanding something?
If not, we may be failing to verify the majority of our workarounds :(
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 848519b58e45..5fe85fad91c1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -666,7 +666,7 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs *engine,
> /* Wa_1604278689:icl,ehl */
> wa_write(wal, IVB_FBC_RT_BASE, 0xFFFFFFFF & ~ILK_FBC_RT_VALID);
> wa_write_clr_set(wal, IVB_FBC_RT_BASE_UPPER,
> - 0, /* write-only register; skip validation */
> + 0,
> 0xFFFFFFFF);
>
> /* Wa_1406306137:icl,ehl */
In this particular example, since clear bits are 0, I don't think any
verification is happening at all.
--Ken
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Kenneth Graunke <kenneth@whitecape.org>
To: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
Matt Roper <matthew.d.roper@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 6/6] drm/i915/gt: Remove bogus comment on IVB_FBC_RT_BASE_UPPER
Date: Tue, 27 Jun 2023 11:30:26 -0700 [thread overview]
Message-ID: <1781954.dNn8tgRAG2@mizzik> (raw)
In-Reply-To: <20230624171757.3906095-7-lucas.demarchi@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
On Saturday, June 24, 2023 10:17:57 AM PDT Lucas De Marchi wrote:
> The comment on the parameter being 0 to avoid the read back doesn't
> apply as this is not a call to wa_mcr_add(), but rather to
> wa_mcr_clr_set(). So, this register is actually checked and it's
> according to the Bspec that the register is RW, not RO.
I think you mean wa_add and wa_write_clr_set here (not mcr).
One thing I've been confused about while reading this code:
static void
wa_write_clr_set(struct i915_wa_list *wal, i915_reg_t reg, u32 clear, u32 set)
{
wa_add(wal, reg, clear, set, clear, false);
}
The second to last parameter is read_mask aka wa->read. We're
initializing it to the...bits to clear. (I would think it should be
(clear | set) to pick up all modified bits.)
wa_verify seems to balk at ((cur ^ wa->set) & wa->read). But...if
wa->read is just the clear mask, that wouldn't actually verify that
any bits were set at all. Or am I misunderstanding something?
If not, we may be failing to verify the majority of our workarounds :(
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 848519b58e45..5fe85fad91c1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -666,7 +666,7 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs *engine,
> /* Wa_1604278689:icl,ehl */
> wa_write(wal, IVB_FBC_RT_BASE, 0xFFFFFFFF & ~ILK_FBC_RT_VALID);
> wa_write_clr_set(wal, IVB_FBC_RT_BASE_UPPER,
> - 0, /* write-only register; skip validation */
> + 0,
> 0xFFFFFFFF);
>
> /* Wa_1406306137:icl,ehl */
In this particular example, since clear bits are 0, I don't think any
verification is happening at all.
--Ken
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-06-27 18:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-24 17:17 [Intel-gfx] [PATCH v2 0/6] Fix ctx workarounds for non-masked regs Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-24 17:17 ` [Intel-gfx] [PATCH v2 1/6] drm/i915/gt: Move wal_get_fw_for_rmw() Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-24 17:17 ` [Intel-gfx] [PATCH v2 2/6] drm/i915/gt: Clear all bits from GEN12_FF_MODE2 Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-25 18:39 ` [Intel-gfx] " Matt Roper
2023-06-25 18:39 ` Matt Roper
2023-06-24 17:17 ` [Intel-gfx] [PATCH v2 3/6] drm/i915/gt: Fix context workarounds with non-masked regs Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-27 18:32 ` [Intel-gfx] " Kenneth Graunke
2023-06-27 18:32 ` Kenneth Graunke
2023-06-24 17:17 ` [Intel-gfx] [PATCH v2 4/6] drm/i915/gt: Drop read from GEN8_L3CNTLREG in ICL workaround Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-24 17:17 ` [Intel-gfx] [PATCH v2 5/6] drm/i915/gt: Enable read back on XEHP_FF_MODE2 Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-24 17:17 ` [Intel-gfx] [PATCH v2 6/6] drm/i915/gt: Remove bogus comment on IVB_FBC_RT_BASE_UPPER Lucas De Marchi
2023-06-24 17:17 ` Lucas De Marchi
2023-06-27 18:30 ` Kenneth Graunke [this message]
2023-06-27 18:30 ` Kenneth Graunke
2023-06-28 4:02 ` [Intel-gfx] " Lucas De Marchi
2023-06-28 4:02 ` Lucas De Marchi
2023-06-25 6:42 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for Fix ctx workarounds for non-masked regs Patchwork
2023-06-29 3:42 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for Fix ctx workarounds for non-masked regs (rev2) Patchwork
2023-06-29 8:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-06-29 16:56 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=1781954.dNn8tgRAG2@mizzik \
--to=kenneth@whitecape.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.d.roper@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 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.