[RFC 1/7] drm/atomic: initial support for asynchronous plane update

[Daniel Vetter]

On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote:
> 2017-04-11 Daniel Vetter <daniel at ffwll.ch>:
> 
> > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote:
> > > Gustavo Padovan <gustavo at padovan.org> writes:
> > > 
> > > > From: Gustavo Padovan <gustavo.padovan at collabora.com>
> > Some async cursor updates are not 100% async, as in the hw might still
> > scan out the old buffer until the next vblank. Could/should we handle this
> > in core? Or are we going to shrug this off with "meh, you asked for
> > tearing, you got tearing"?
> 
> Do you know which hw would that be? I don't know. Maybe we should just
> don't care for now and see how drivers will solve this to then extract
> helpers like we did for atomic nonblocking commits.

i915 is one. The only way to do true async updates is throught the CS flip
command with a special bit set, and that one only works for the primary
plane. All other updates are synced to vblank, i.e. the hw will keep
scanning out the old address.

But I checked the current code, it's no better than what you've done.

More special is iirc rockchip (or some other arm-soc display ip), which on top
also has an iommu which falls over if the mapping disappears right away.
Easy solution is to not allow fb changes (but that kinda sucks), more
involved is delaying the fb cleanup into a worker (but since we don't
rate-limit this is tricky too ...).

Maybe just go with a FIXME comment here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch