[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: extract engine WA programming to common resume function

Daniele Ceraolo Spurio daniele.ceraolospurio at intel.com
Thu Jan 30 19:20:00 UTC 2020



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 at 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
> 


More information about the Intel-gfx mailing list