public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: John Harrison <John.C.Harrison@Intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Intel-GFX@Lists.FreeDesktop.Org
Subject: Re: [PATCH 4/4] drm/i915: Update workarounds selftest for read only regs
Date: Tue, 18 Jun 2019 06:43:37 -0700	[thread overview]
Message-ID: <eb2f23ee-248a-fbb2-7f5e-32aea1c87f90@Intel.com> (raw)
In-Reply-To: <3d1523cd-0e41-7bf1-b398-2710c2148168@linux.intel.com>

On 6/17/2019 23:42, Tvrtko Ursulin wrote:
> On 18/06/2019 02:01, John.C.Harrison@Intel.com wrote:
>> From: "Robert M. Fosha" <robert.m.fosha@intel.com>
>>
>> Updates the live_workarounds selftest to handle whitelisted
>> registers that are flagged as read only.
>>
>> Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   .../gpu/drm/i915/gt/selftest_workarounds.c    | 43 +++++++++++++++++--
>>   1 file changed, 39 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c 
>> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> index c8d335d63f9c..eb6d3aa2c8cc 100644
>> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
>> @@ -408,6 +408,29 @@ static bool wo_register(struct intel_engine_cs 
>> *engine, u32 reg)
>>       return false;
>>   }
>>   +static bool ro_register(u32 reg)
>> +{
>> +    if (reg & RING_FORCE_TO_NONPRIV_RD)
>> +        return true;
>> +
>> +    return false;
>> +}
>> +
>> +static int whitelist_writable_count(struct intel_engine_cs *engine)
>> +{
>> +    int count = engine->whitelist.count;
>> +    int i;
>> +
>> +    for (i = 0; i < engine->whitelist.count; i++) {
>> +        u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
>> +
>> +        if (ro_register(reg))
>> +            count--;
>> +    }
>> +
>> +    return count;
>> +}
>> +
>>   static int check_dirty_whitelist(struct i915_gem_context *ctx,
>>                    struct intel_engine_cs *engine)
>>   {
>> @@ -463,6 +486,9 @@ static int check_dirty_whitelist(struct 
>> i915_gem_context *ctx,
>>           if (wo_register(engine, reg))
>>               continue;
>>   +        if (ro_register(reg))
>> +            continue;
>> +
>>           srm = MI_STORE_REGISTER_MEM;
>>           lrm = MI_LOAD_REGISTER_MEM;
>>           if (INTEL_GEN(ctx->i915) >= 8)
>> @@ -734,9 +760,13 @@ static int read_whitelisted_registers(struct 
>> i915_gem_context *ctx,
>>         for (i = 0; i < engine->whitelist.count; i++) {
>>           u64 offset = results->node.start + sizeof(u32) * i;
>> +        u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
>> +
>> +        /* Clear RD only and WR only flags */
>> +        reg &= ~(RING_FORCE_TO_NONPRIV_RD | RING_FORCE_TO_NONPRIV_WR);
>>             *cs++ = srm;
>> -        *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
>> +        *cs++ = reg;
>>           *cs++ = lower_32_bits(offset);
>>           *cs++ = upper_32_bits(offset);
>>       }
>> @@ -769,9 +799,14 @@ static int scrub_whitelisted_registers(struct 
>> i915_gem_context *ctx,
>>           goto err_batch;
>>       }
>>   -    *cs++ = MI_LOAD_REGISTER_IMM(engine->whitelist.count);
>> +    *cs++ = MI_LOAD_REGISTER_IMM(whitelist_writable_count(engine));
>>       for (i = 0; i < engine->whitelist.count; i++) {
>> -        *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
>> +        u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
>> +
>> +        if (ro_register(reg))
>> +            continue;
>> +
>
> Are we not able to test the read-only property at all?
>
I am sure it would be possible to make such work. But can that wait 
until the next round when we add support for ranges? And write only 
access too if any registers actually use that and there is a way to test 
that it really does do something?

I believe Robert was looking at getting something going but it wasn't 
immediately working and we urgently need to get the HUC whitelist 
updates merged to hit the next release window. So right now, it is 
sufficient to say that the user land media driver works with these 
changes and therefore the whitelisting must be working. The kernel 
selftest is just a belt and braces check on top of that and therefore 
can wait until later.

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

  reply	other threads:[~2019-06-18 13:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-18  1:01 [PATCH 0/4] Update whitelist support for new hardware John.C.Harrison
2019-06-18  1:01 ` [PATCH 1/4] drm/i915: Support flags in whitlist WAs John.C.Harrison
2019-06-18  6:27   ` Tvrtko Ursulin
2019-06-18  6:35   ` Tvrtko Ursulin
2019-06-18 13:48     ` John Harrison
2019-06-18 16:10   ` Tvrtko Ursulin
2019-06-18  1:01 ` [PATCH 2/4] drm/i915: Support whitelist workarounds on all engines John.C.Harrison
2019-06-18  6:29   ` Tvrtko Ursulin
2019-06-18  1:01 ` [PATCH 3/4] drm/i915: Add whitelist workarounds for ICL John.C.Harrison
2019-06-18  6:30   ` Tvrtko Ursulin
2019-06-18  1:01 ` [PATCH 4/4] drm/i915: Update workarounds selftest for read only regs John.C.Harrison
2019-06-18  6:42   ` Tvrtko Ursulin
2019-06-18 13:43     ` John Harrison [this message]
2019-06-18 16:14       ` Tvrtko Ursulin
2019-06-18  1:50 ` ✓ Fi.CI.BAT: success for Update whitelist support for new hardware (rev2) Patchwork
2019-06-18 16:33   ` Tvrtko Ursulin
2019-06-18 19:54     ` [PATCH] drm/i915: Implement read-only support in whitelist selftest John.C.Harrison
2019-06-18 20:08       ` John Harrison
2019-06-19  6:41         ` Tvrtko Ursulin
2019-06-19  6:49       ` Tvrtko Ursulin
2019-06-20 15:43       ` Tvrtko Ursulin
2019-06-25  8:33         ` Tvrtko Ursulin
2019-07-03  2:20           ` John Harrison
2019-06-18 20:51     ` ✗ Fi.CI.BAT: failure for " Patchwork
2019-06-18 16:22 ` ✓ Fi.CI.IGT: success for Update whitelist support for new hardware (rev2) 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=eb2f23ee-248a-fbb2-7f5e-32aea1c87f90@Intel.com \
    --to=john.c.harrison@intel.com \
    --cc=Intel-GFX@Lists.FreeDesktop.Org \
    --cc=tvrtko.ursulin@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