On 1/30/20 6:08 AM, Chris Wilson wrote:
Quoting Ville Syrjälä (2020-01-30 13:58:13)
On Thu, Jan 30, 2020 at 01:37:49PM +0000, Chris Wilson wrote:
Quoting Patchwork (2020-01-30 06:49:28)
#### Possible regressions ####
* igt@i915_selftest@live_active:
- fi-bwr-2160: [PASS][1] -> [DMESG-WARN][2] +12 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7840/fi-bwr-2160/igt@i915_selftest@live_active.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16327/fi-bwr-2160/igt@i915_selftest@live_active.html
Well it works on Crestline. Broadwater snafu?
Does the w/a thing actually work correctly for masked registers?
It look to use rmw even for masked registers and IIRC some masked
registers return 0xffff for the mask when read. I lost track of the
values and masks being passed around before I got down that deep so
can't immediatly see if the code is guaranteed to set only the
expected mask bit(s) for the write.
But does it make any difference is the mask is returned or not with rmw?
if it is, we reprogram the lower 16 bits with the original value + our
diff, while if it isn't we just toggle in place the bit we're interested
in. The result should be the same in both cases.
The read back gives 0x10101, the w/a is to 0x400040 (and we expect to
see 0x40 set in the readback).
Looks like the result is also not constant. Initial load and a few of
the reloads are fine and in some cases we also see the register being
zeroed:
(209c=0/0, expected 400040, mask=40)
Maybe something weird happening post-reset?
Daniele
That part looks consistent (and is passing on gen4-gen6 except for CI's
bw).
Hmm, don't recall that it used rmw for setting the masked mmio, so lets
check that.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
