From: "Siluvery, Arun" <arun.siluvery@linux.intel.com>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915/bdw: Export workaround data to debugfs
Date: Sun, 31 Aug 2014 20:43:49 +0100 [thread overview]
Message-ID: <54037AF5.5030304@linux.intel.com> (raw)
In-Reply-To: <20140830151035.GA30509@strange.ger.corp.intel.com>
On 30/08/2014 16:10, Damien Lespiau wrote:
> On Tue, Aug 26, 2014 at 02:44:51PM +0100, Arun Siluvery wrote:
>> The workarounds that are applied are exported to a debugfs file;
>> this is used to verify their state after the test case (reset or
>> suspend/resume etc). This patch is only required to support i-g-t.
>
> I'm really, really confused. Please bear with me.
I have reworked all the patches hopefully things will be more clear this
time :)
>
> 1. We only deal with masked registers AFAICS. Those registers have the
> high 16 bits masking the writes.
>
> 2. The values given to intel_ring_emit_wa() are the actual values we're going
> to write in the register, so they include those mask bits. say:
>
> intel_ring_emit_wa(ring, GEN7_ROW_CHICKEN2,
> _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
>
> 3. We then record in intel_wa_regs the reg address and two fields named mask
> and value.
>
> 3. a) mask
>
> intel_wa_regs[dev_priv->num_wa_regs].mask = value & 0xFFFF;
>
> You're selecting the low 16bits and put it in mask. But the masked bits are the
> upper 16bits? This may work when the W/A is about setting bits, but we have a
> bug if we ever have a W/A that is about clearing a bit. It would seem better to
> me to grab the upper bits which are, after all, the bitmask we're interested in.
>
it is a valid issue, changed to use upper 16-bits as mask.
> 3. b) value
>
> /* value is updated with the status of remaining bits of this
> * register when it is read from debugfs file
> */
> dev_priv->intel_wa_regs[dev_priv->num_wa_regs].value = value;
>
> I don't understand what the comment explains. The *why* we need to do that is
> missing and, frankly, having to update the reference values we capture at
> intel_ring_emit_wa() time sounds like a bug to me.
>
> I also take a note that, at this, point, intel_wa_regs.value contains both the
> value and the mask. Weird.
>
I agree the why part is missing.
The idea is value represents the status of other bits in this register
besides w/a bit; this is actually redundant here, I guess I added
because I wanted to initialize all members.
This change is not applicable in the new patches.
> 4. Time to expose that intel_wa_regs array to user space
>
> 4. a) mask
>
> mask = dev_priv->intel_wa_regs[i].mask
>
> Straigthforward enough, except that these are still the lower 16 bits, so the
> value really.
>
> 4. b) value
>
> dev_priv->intel_wa_regs[i].value = I915_READ(addr) | mask;
>
> Hum? This really started my journey to dig futher. So we:
>
> - override the reference value from intel_ring_emit_wa() with whatever we
> have in the register at that moment
>
> - Or it with a mask that's not really a mask (but the reference value)
>
> 5. igt test
>
> So you grab those mask and value fields from the debugs file and read the
> register through mapped MMIO. and then
>
> status = (current_wa[i].value & current_wa[i].mask) !=
> (wa_regs[i].value & wa_regs[i].mask);
>
> So that's where I'm starting to put things back together and understand what
> the intention is. I still think that's not quite right, especially how we get
> the mask and why we read back the register in the debugfs file.
>
We read the register value after the test case (eg reset) and compare it
with a known value that is exported to debugfs file.
regards
Arun
> Or am I just missing something? In any case, having to spend that much time
> trying to understand what's going on is a maintainability problem, we need code
> that a least looks straightforward.
>
> HTH,
>
next prev parent reply other threads:[~2014-08-31 19:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 13:44 [PATCH 0/2] Apply BDW workarounds using LRIs in render init fn Arun Siluvery
2014-08-26 13:44 ` [PATCH 1/2] drm/i915/bdw: Apply workarounds in render ring init function Arun Siluvery
2014-08-26 14:37 ` Ville Syrjälä
2014-08-26 14:47 ` Siluvery, Arun
2014-08-26 15:32 ` Ville Syrjälä
2014-08-26 16:06 ` Chris Wilson
2014-08-27 14:33 ` [PATCH] drm/i915: Init some CHV workarounds via LRIs in ring->init_context() ville.syrjala
2014-08-27 15:02 ` Chris Wilson
2014-08-29 15:43 ` Barbalho, Rafael
2014-08-29 16:01 ` Daniel Vetter
2014-08-26 13:44 ` [PATCH 2/2] drm/i915/bdw: Export workaround data to debugfs Arun Siluvery
2014-08-27 15:44 ` Daniel Vetter
2014-08-27 15:54 ` Chris Wilson
2014-08-27 15:59 ` Siluvery, Arun
2014-08-27 16:19 ` Chris Wilson
2014-08-30 15:10 ` Damien Lespiau
2014-08-31 19:43 ` Siluvery, Arun [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-08-26 9:33 [PATCH 0/2] Apply BDW workarounds using LRIs in render init fn Arun Siluvery
2014-08-26 9:33 ` [PATCH 2/2] drm/i915/bdw: Export workaround data to debugfs Arun Siluvery
2014-08-22 19:39 [PATCH 0/2] Apply BDW workarounds using LRIs in render init fn Arun Siluvery
2014-08-22 19:39 ` [PATCH 2/2] drm/i915/bdw: Export workaround data to debugfs Arun Siluvery
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=54037AF5.5030304@linux.intel.com \
--to=arun.siluvery@linux.intel.com \
--cc=damien.lespiau@intel.com \
--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.