[Intel-gfx] [PATCH v2 01/12] drm/i915: Make the force_thru workaround atomic.
Daniel Vetter
daniel at ffwll.ch
Tue Jul 28 01:25:11 PDT 2015
On Tue, Jul 28, 2015 at 09:57:37AM +0200, Maarten Lankhorst wrote:
> Op 27-07-15 om 16:04 schreef Daniel Vetter:
> > On Mon, Jul 27, 2015 at 02:35:30PM +0200, Maarten Lankhorst wrote:
> >> Set active_changed to force a modeset if the panel fitter's force
> >> enabled.
> >>
> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > Hm, shouldn't our fancy fastset logic be able to detect that we've changed
> > pfit change here and force a full modeset? Or am I blind again?
> >
> > Abusing active_changed for this feels a bit tricksy tbh, can't we use
> > mode_changed for this? mode_changed is kinda for "crtc configuration that
> > needs a full modeset changed", not just for modes. active_changed is
> > "enable/disable it, but strictly speaking no need to recompute stuff".
> >
> > At least that's how the atomic helpers treat it.
> >
> I think for !PIPE_A it's ok, but pipe_a + edp can use a different power well iirc.
> I wasn't sure how that was treated so I went for active_changed instead of mode_changed.
Following up from our irc discussion: mode_changed is indeed not a good
idea since with the fastset tricks we might accidentally ellide the
modeset if intel_pipe_config_compare doesn't catch it (and right now it
won't). But I still think active_changed is abuse since active_changed
should _not_ result in state recomputation really, the entire point of
crtc_state->active is that you can always flip it and it will never fail
due to lack of resources.
But with your latest patches we have connector_changed to track routing
changes, and force_thru is very much a routing change. I think using that
would be best.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list