[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Daniel Vetter]

On Mon, Oct 10, 2016 at 3:32 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
>> <ville.syrjala at linux.intel.com> wrote:
>> >> I think the
>> >> proper way is to keep track of a per-plane zpos changed (or compute
>> >> that ad-hoc, we have both states). And only grab more planes if a zpos
>> >> value changed.
>> >
>> > Doesn't work with normalized zpos. The plane's actual zpos may be
>> > unchanged even if the normalized zpos changes.
>>
>> Well I meant to do a first loop to check for any zpos changes, and
>> only then add all the planes. If no one touched zpos, then also no
>> normalized zpos can change. I think at least ... Or what am I missing?
>
> Enabling planes can change zpos. Which is what's currently causing all
> the planes to be added to the state every time the cursor is
> enabled/disabled on i915. Which isn't nice.
>
> And anyway adding all the planes to the state when some zpos change
> happens is entirely pointless on i915. There's no need to run through
> any of .check_plane() hooks in this case. The only thing we need to
> do is rewrite the sprite control registers (+ base addresses of course
> to arm the update). So we could just add the sprite planes to state
> after the .check_plane() stuff has been done so that we'll just get the
> .commit_plane(). So knowing somehting about the hardware allows us to
> do a much better job of this.

Ok, I buy it ;-)

So we only need this if we have a driver that's using
plane_state->normalized_zpos. Having all combinatorials of
atomic_check_with_featureA_featureB will get ugly. I think it'd be
better to just split it out and dump it only into drivers's
atomic_check that need it. Plus add a very big warning to
drm_plane_state->normalized_zpos that without calling that helper it
will be invalid. Bit more copypaste, but I think that's actually good
(since we don't want to support all combinatorial variations with
pre-made helpers imo).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch