[PATCH v3] drm/tidss: dispc: Rewrite naive plane positioning code

Jyri Sarha jsarha at ti.com
Thu Feb 13 11:52:33 UTC 2020


On 13/02/2020 12:49, Tomi Valkeinen wrote:
> On 13/02/2020 12:44, Jyri Sarha wrote:
> 
>> +    /*
>> +     * If a plane on a CRTC changes add all active planes on that
>> +     * CRTC to the atomic state. This is needed for updating the
>> +     * plane positions in tidss_crtc_position_planes() which is
>> +     * called from crtc_atomic_enable() and crtc_atomic_flush().
>> +     * The update is needed for x,y-position changes too, so
>> +     * zpos_changed condition is not enough and we need this if
>> +     * planes_changed is true too.
>> +     */
>> +    for_each_new_crtc_in_state(state, crtc, cstate, i) {
>> +        if (cstate->zpos_changed || cstate->planes_changed) {
>> +            ret = drm_atomic_add_affected_planes(state, crtc);
>> +            if (ret)
>> +                return ret;
>> +        }
>> +    }
> 
> I think 99.99...% of the commits are such where only planes' fb address
> is changed. I think "planes_changed" is true for these. I wonder if it
> would be a sensible optimization to skip this for those 99.99...% cases.
> Can we detect that easily?
> 

Sure by looping all planes in the state through with
for_each_oldnew_plane_in_state() and checking if crtc_x or crtc_y has
changed. But then again writing the positions of max 4 planes is really
not that heavy operation. There is more calculation to do and more
registers to write when updating the fp, so I do not think avoiding the
OVR update justifies the extra complexity.

> Well, we haven't optimized for those 99.99...% cases anywhere else
> either, so it's possible it doesn't matter.
> 





-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the dri-devel mailing list