[Intel-gfx] [PATCH 2/2] drm/i915: calculate pfit changes in set_config v3

[Jesse Barnes]

On Tue, 9 Dec 2014 22:16:33 +0100
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Tue, Dec 9, 2014 at 6:51 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > On Tue, 11 Nov 2014 12:30:47 -0800
> > Jesse Barnes <jbarnes at virtuousgeek.org> 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