Re: [PATCH v4 19/27] drm/i915: Read hw state into an atomic state struct, v2.

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

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@intel.com>
>>
>> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx