[Intel-gfx] [PATCH igt 3/3] kms_frontbuffer_tracking: properly handle mixing GTT and WC mmaps

The new Kernel behavior is that whenever a buffer has ever been WC mmapped, the GTT mmaps will be treated as CPU operations. Because of this, if we don't issue the dirty_fb IOCTL after doing frontbuffer rendering with the GTT mmaps, FBC will remain disabled. Luckily, the only subtest that does this

[Intel-gfx] [PATCH igt 2/3] kms_frontbuffer_tracking: recreate the FBs at every subtest

This patch was originally written because of a workaround we were planning to merge. Later we improved the workaround so it wouldn't need this patch anymore. Then later we gave up on the workaround, but decided to go with a plan that would cause GTT mmap writes to invalidate FBC in case the frontbu

[Intel-gfx] [PATCH 4/4] drm/i915/fbc: enable FBC on gen 9+ too

Now that we're more protected against user space doing frontbuffer mmap rendering, the last - how many times did I say this before? - SKL problem seems to be solved. So let's give it a try. And since the other newer platforms are still under preliminary support, let's enable FBC on them too to mak

[Intel-gfx] [PATCH 2/4] drm/i915/fbc: sanitize i915.enable_fbc during FBC init

The DDX driver changes its behavior depending on the value it reads from i915.enable_fbc, so sanitize the value in order to allow it to know what's going on. It uses this in order to choose the defaults for the TearFree option. Before this patch, it will read -1 and always assume that FBC is disabl

[Intel-gfx] [PATCH igt 1/3] kms_frontbuffer_tracking: prefer the BLT drawing method

A recent Kernel fix changed the way GTT and WC mmaps behave during frontbuffer drawing. This, added with the fact that GTT mmaps are special cases for PSR, suggests that maybe we should move to BLT drawing in places where we can, in order to simplify things a little bit. v2: New commit message. S

[Intel-gfx] [PATCH] drm/i915/skl: Disable underrun reporting on MST unplug

Unplugging MST displays usually causes underruns, so turn off underrun reporting so people don't report false positives. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_display.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

== Series Details == Series: series starting with [1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs URL : https://patchwork.freedesktop.org/series/5282/ State : failure == Summary == Series 5282v1 Series without cover letter http://patchwork.freedesktop.org/a

Re: [Intel-gfx] Reviving the LPSS PWM patches

Hi On Thursday 31 March 2016 03:57 PM, Lluís Batlle i Rossell wrote: Hello, I saw that you did some work for LPSS PWM: https://lists.freedesktop.org/archives/intel-gfx/2016-January/085006.html Apart from above apply the following as well - https://patchwork.freedesktop.org/patch/70965/ This

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC reset-and-retry patches (resend)

== Series Details == Series: GuC reset-and-retry patches (resend) URL : https://patchwork.freedesktop.org/series/5287/ State : failure == Summary == Series 5287v1 GuC reset-and-retry patches (resend) http://patchwork.freedesktop.org/api/1.0/series/5287/revisions/1/mbox/ Test gem_ctx_switch:

<    1   2