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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
