Op 01-06-15 om 23:47 schreef Matt Roper: > On Mon, Jun 01, 2015 at 12:50:03PM +0200, Maarten Lankhorst wrote: >> From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@xxxxxxxxx> >> >> To make this work we load the new hardware state into the >> atomic_state, then swap it with the sw state. >> >> This lets us change the force restore path in setup_hw_state() >> to use a single call to intel_mode_set() to restore all the >> previous state. >> >> As a nice bonus this kills off encoder->new_encoder, >> connector->new_enabled and crtc->new_enabled. They were used only >> to restore the state after a modeset. >> >> Changes since v1: >> - Make sure all possible planes are added with their crtc set, >> so they will be turned off on first modeset. > Correct me if I'm wrong, but I don't think we're actually doing this > yet. We're using drm_atomic_add_affected_planes() which looks at the > current (and possibly incomplete) software state to figure out what an > 'affected' plane is. If pre-driver firmware has enabled a sprite or > cursor plane, that's not going to be reflected in our state's > plane_mask fields, so those planes won't be added by the helper. > > I think what you want is an i915-specific loop that operates over *all* > drm_plane's and compares intel_plane->pipe to intel_crtc->pipe to > determine which ones need to be pulled into the state. Then the > sprites/cursors will be automatically turned off on the first modeset, > ensuring our hardware and software state stay in sync. > > The other alternative is to actually look at the hardware state for each > sprite/cursor and try to inherit their real state as we do for the > primary plane. But I'm not sure it's worth putting in that effort right > now. All these interdepencies make it hard. I think what I'm doing here is no worse than what we were doing previously, and cursors will still be unconditionally disabled until part 3 of converting to atomic. So for now this is good enough, but in part 3 I will have to resolve this issue, I'll work on it today. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
