[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Use the full hammer when shutting down the rcu tasks

== Series Details == Series: series starting with [1/2] drm/i915: Use the full hammer when shutting down the rcu tasks URL : https://patchwork.freedesktop.org/series/14575/ State : failure == Summary == Series 14575v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/serie

[Intel-gfx] [PATCH 2/2] drm/i915: Avoid accessing request->timeline outside of its lifetime

Whilst waiting on a request, we may do so without holding any locks or any guards beyond a reference to the request. In order to avoid taking locks within request deallocation, we drop references to its timeline (via the context and ppgtt) upon retirement. We should avoid chasing such pointers outs

[Intel-gfx] [PATCH 1/2] drm/i915: Use the full hammer when shutting down the rcu tasks

To flush all call_rcu() tasks (here from i915_gem_free_object()) we need to call rcu_barrier() (not synchronize_rcu()). If we don't then we may still have objects being freed as we continue to teardown the driver - in particular, the recently released rings may race with the memory manager shutdown

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm: Track drm_mm allocators and show leaks on shutdown

== Series Details == Series: series starting with [1/2] drm: Track drm_mm allocators and show leaks on shutdown URL : https://patchwork.freedesktop.org/series/14571/ State : warning == Summary == Series 14571v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/14571

[Intel-gfx] [PATCH 1/2] drm: Track drm_mm allocators and show leaks on shutdown

We can use the kernel's stack tracer and depot to record the allocation site of every drm_mm user and then on shutdown as well as warning that allocated nodes still reside with the drm_mm range manager, we can also display who allocated them to aide tracking down the leak. Signed-off-by: Chris Wil

[Intel-gfx] [PATCH 2/2] drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG

A frequent issue that arises on shutdown is the drm_mm range manager complaining of a leak. To aide debugging those, drm can now track the allocation callsite and print those for the leaks. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + 1 file changed, 1 insertion(+)

Re: [Intel-gfx] xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0

On Sat, Oct 29, 2016 at 10:13:25AM -0300, Gaston Gonzalez wrote: > On Fri, Oct 28, 2016 at 07:23:24PM +0300, Ville Syrjälä wrote: > > On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote: > > > On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote: > > > > On Wed, Oct 05, 2016 at 07:23

Re: [Intel-gfx] xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0

On Fri, Oct 28, 2016 at 07:23:24PM +0300, Ville Syrjälä wrote: > On Fri, Oct 28, 2016 at 11:53:40AM -0400, Greg KH wrote: > > On Fri, Oct 07, 2016 at 10:38:17AM -0300, Gaston Gonzalez wrote: > > > On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote: > > > > On Tue, Oct 04, 2016 at 08:43:03PM -0

Re: [Intel-gfx] [PATCH] MAINTAINERS: drop dri-devel list for i915

On Wed, 26 Oct 2016, Jani Nikula wrote: > In practice, none of the i915 developers Cc dri-devel for strictly i915 > specific patches. Make MAINTAINERS reflect reality, and reduce random > i915 specific noise on dri-devel. > > Also, we have a fairly large crowd reading and responding on intel-gfx,

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Prevent enabling hpd polling in late suspend

On Wed, 26 Oct 2016, Ville Syrjälä wrote: > On Wed, Oct 26, 2016 at 12:36:09PM -0400, Lyude wrote: >> One of the CI machines began to run into issues with the hpd poller >> suddenly waking up in the midst of the late suspend phase. It looks like >> this is getting caused by the fact we now deiniti

[Intel-gfx] [PATCH 5/5] drm/i915: Set crtc_state->fb_changed whenever a VMA is changed

Since an fb may have multiple VMA (due to rotations etc), we need to wait a vblank and unpin the old VMA not if the fb itself is changed, but if the underlying VMA is changed. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 10 +++--- 1 file changed, 7 insertions(+), 3

[Intel-gfx] [PATCH 3/5] drm/i915: Track pinned vma in intel_plane_state

With atomic plane states we are able to track an allocation right from preparation, during use and through to the final free after being swapped out for a new plane. We can couple the VMA we pin for the framebuffer (and its rotation) to this lifetime and avoid all the clumsy lookups in between. Si

[Intel-gfx] [PATCH 1/5] drm/i915: Move intel_prepare_plane_fb() and intel_cleanup_plane_fb()

In the next patch, a few rearrangements are made to make these static. First, we move them so the changes are not lost in the noise. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 256 +-- drivers/gpu/drm/i915/intel_drv.h | 2 + 2 fil

[Intel-gfx] [PATCH 2/5] drm/i915: Always prepare planes at the start of an atomic commit

The generic atomic helper likes to skip a prepare_plane_fb() if it decides that the plane->fb is unchanged. This is wrong for us for a couple of reasons: - if the pipe is reconfigured (i.e. a size change) but the framebuffer is untouched, we still have to flush any rendering prior to the re

[Intel-gfx] [PATCH 4/5] drm/i915: Quick spring clean of intel_prepare_plane_fb()

Just a quick tidy now to make the next patch neater. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 38 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_