On Thu, Mar 08, 2018 at 10:07:05AM -0800, Pandiyan, Dhinakaran wrote: > > > > On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote: > > Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > > > > > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > > >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: > > >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: > > >>>> Similar to enable_fbc, enable_psr was ignored at runtime if it was > > >>>> changed. The easiest fix is to pretend enable_psr is ignored at > > >>>> configure time, and never activate it for !enable_psr, so both cases > > >>>> are handled without modesets. > > >>> What about cases where psr_flush() is not called and consequently the > > >>> module parameter is not checked? With HW tracking, PSR is > > >>> enabled/disabled during modeset and the hardware is expected to exit and > > >>> activate PSR without driver intervention. > > >> It looks like intel_frontbuffer_flush always calls intel_psr_flush, > > >> so we at least get a PSR toggle after every atomic commit? > > > I have a patch to remove flush() from legacy_cursor_update(). We end up > > > with an inconsistent behavior when that patch gets merged, > > > cursor moves -> trigger psr exit but don't read module parameter > > > commits -> trigger psr exit but read module parameter > > Legacy cursor updates are special, I don't mind them not changing PSR. > > > Eventually, when we get to removing flush() from commits, then this > > > patch won't really be useful. And tests disabling/enabling PSR at > > > runtime will probably fail. > > Could we transition to debugfs for changing it at runtime? > > That does sound like a better idea. +1 > > > > > ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
