[Intel-gfx] [PATCH] drm/i915: Add Baytrail PSR Support.

[Daniel Vetter]

On Tue, Feb 04, 2014 at 11:03:25AM -0200, Rodrigo Vivi wrote:
> >> > In the case of a moving cursor that means indefinitely.
> >> That's true... So I think we really need a work queue delaying the enable.
> >> Or do you have any better idea?
> >
> > Yeah, sounds like we need a delayed work-queue to re-enable psr, also for
> > gtt mmap writes. See Chris' latest crazy example of what the X server is
> > currently allowed to do.
> 
> http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=psr-baytrail-wq&id=f356c599db47dca4966dfb173282b111ce3055f5
> 
> But I'm not sure if I should do all with delayed schedule or still
> calling this psr_update on mark_idle and just schedule work on cursor.
> what do you think?

You also need to tear down gtt mmaps to make sure we catch them, at least
for the gtt mmap write case. And add a bit of code to gem_fault to
invalidate psr if needed.

> Please notice that besides the wq it also has mutex psr added on this:
> 
> http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=psr-baytrail-wq&id=b18fb62af0d591cec593a75f7cf896b46e0cc91e

tbh I haven't thought much yet about locking, but iirc the current stuff
is hapzardous. Ville looked into fixing this, but it seems to be fairly
complicated. Not sure whether we should aim for a common locking between
fbc/psr or not (since they both are closely related wrt their interactions
between modeset code and gem stuff).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch