On Wed, Feb 12, 2020 at 09:06:11AM +, Chris Wilson wrote:
> BIT(14) is not sticking in 0xe4f4 so we have no idea if the w/a is still
> in effect when it needs to be. Until that is resolved, remove the
> failing bit.
The headline for the patch you're reverting was somewhat confusing since
it
Chris Wilson writes:
> BIT(14) is not sticking in 0xe4f4 so we have no idea if the w/a is still
Now we have some idea. It was in mcr range register thus verification
was doomed to fail. Fix in list.
-Mika
> in effect when it needs to be. Until that is resolved, remove the
> failing bit.
>
>
Chris Wilson writes:
> BIT(14) is not sticking in 0xe4f4 so we have no idea if the w/a is still
> in effect when it needs to be. Until that is resolved, remove the
> failing bit.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
BIT(14) is not sticking in 0xe4f4 so we have no idea if the w/a is still
in effect when it needs to be. Until that is resolved, remove the
failing bit.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1169
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---