On Tue, Jan 21, 2014 at 02:15:51PM +0100, Daniel Vetter wrote: > On Sun, Jan 19, 2014 at 1:47 PM, Ramalingam C <ramalingam.c@xxxxxxxxx> wrote: > > To remove the wait_for_vblank from the plane switch execution path, > > this change implements a function which will add a delayed work to > > defer the IPS enable. > > > > The delay is nothing but frame length, which is calculated based on > > vrefresh of the hwmode. i.e IPS enable will be scheduled after a frame. > > If mode is not set during the plane switch (__unlikely__), delay will > > fallback to a default value 100mSec (can handle the FPS >= 10). > > > > Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx> > > We have a general need to do abitrary stuff in both irq and process > context on future vblanks. Chris started with such infrastructure > already: > > http://lists.freedesktop.org/archives/intel-gfx/2012-April/016557.html > > We've had a fair bit of discussion about where to go to with all this, > but atm this is stalled. I also think we should have this bit of > infrastructure generally available for drivers in drm_vblank.c. > > The other thing to keep in mind is to make this fit with Ville's plan > for nuclear pageflips. I think in the end the modeset code should only > fire up the pipe itself (i.e. we'll display a nice black) and enabling > pipes, sprites and cursors should happen with the nuclear pageflip > code. Otherwise we need to duplicate this logic, which usually means > twice the bugs. Another thing we'd need there is a similar mechanism but for GPU. So get a callback when your target seqno has passed. I have something along those lines in the atomic branch but maybe it could be generalized. For FBC I'd more or less like to have both since I need actually first wait for a seqno, and then for the vblank. But maybe I can make it work with just the current wait_seqno. Didn't actually try yet. Also my watermark update code has another vblank work mechanism which actually looks at the frame counter to make sure work gets executed after the target frame count has passed. Maybe there's another possibility for unification here. I'll need to post those patches first though. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
