On Tue, 9 Dec 2014 22:16:33 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Tue, Dec 9, 2014 at 6:51 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 11 Nov 2014 12:30:47 -0800 > > Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > > >> This should allow us to avoid mode sets for some panel fitter config > >> changes. > >> > >> v2: > >> - fixup pfit comment (Ander) > >> v3: > >> - fixup pfit disable shortcut, only apply to gen4 for now (Jesse) > >> > > > > Daniel pointed out offline that in the !fastboot case, this will fail > > to do the pipe size update if we ever try to skip the mode set when > > changing the pfit state. > > > > To address that we'll need to handle the pfit changes more generally > > anyway, which gets tricky when we're trying to discard the BIOS state. > > > > Ander, if you want to tackle this as part of your multi-pipe stuff, > > feel free, otherwise I'll get to it after the holidays. > > Quick addition with two more smaller things we've discussed a bit too: > - We need a dedicated testcase for this special pfit path. Currently > all igts disable the pipe again before applying changes, so won't > exercise this. We need new testcase which does direct mode changes > (i.e. native -> scaled, scaled->native and scaled->scaled) to make > sure this works well. With atomc we could even make sure it happens in > just 1 vblank, but current interfaces don't allow a pageflip > completion event for setCrtc, so that part has to wait. > > - I think the overall decision logic for modeset-or-not should switch > over to comparing the entire hw state (as stored in > intel_crtc_config). That way we can drop the fastboot hack which > copies the adjusted_mode from the pipe config to crtc->mode since we > only compare the resulting adjusted mode. This should also be more > robust in handling corner cases like the hdmi infoframes logic that we > had to take out again. > > Anyway just these two to summarize our offline discussion. Yeah thanks... more tests as usual are needed. We just need a way in igt to see whether a full mode set happened, then we can check against our assumptions that one should or shouldn't happen for a given config change. And yeah the logic needs to be shuffled around a lot more. I meant to grab more stuff from compute_mode_changes; right now it's just a set of special cases, and not very complete. If we add a new pipe config compare function, we can just special case the fast paths like you mentioned, and add a custom pfit path as well (somewhere in between a simple flip and a full mode set, at least for some platforms). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
