[PATCH 3/4] drm/imx: add FB modifier support

[Lucas Stach]

Am Donnerstag, den 04.05.2017, 11:17 +0200 schrieb Daniel Vetter:
> On Thu, May 4, 2017 at 11:12 AM, Lucas Stach <l.stach at pengutronix.de> wrote:
> > Am Donnerstag, den 04.05.2017, 10:02 +0100 schrieb Daniel Stone:
> >> On 4 May 2017 at 09:59, Lucas Stach <l.stach at pengutronix.de> wrote:
> >> > Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone:
> >> >> What about planes which aren't present in this commit, but are still
> >> >> taking up a PRE unit? Will they have their PRE stolen, or am I missing
> >> >> something?
> >> >
> >> > Yes, the plane->PRE assignment is configurable by matching different AXI
> >> > IDs in the PRG. So what's happening here is that we basically construct
> >> > a new assignment for each commit. Planes without a assigned PRE will
> >> > revert back to pass-through mode in the PRG on plane commit or plane
> >> > disable.
> >>
> >> So those other planes are fine/untouched, because the PRE has already
> >> resolved to linear? Specifically if plane A has a tiled FB, then
> >> userspace does a commit which _only_ contains plane B (also with a
> >> tiled FB), and plane B steals the PRE that was previously assigned to
> >> plane A, then plane A continues displaying just fine? Sorry for the
> >> stupid questions. :)
> >
> > If userspace does a commit with only plane B it's going to disable plane
> > A, right? The PRG/PRE register sets are double buffered (or at least we
> > always use them in this mode). So if plane B steals the PRE from plane
> > A, which is going to get disabled, plane A will continue to use the PRE
> > until the end of frame, then the register set will be latched and the
> > PRE is switched to plane B for the next frame.
> 
> Atomic is incremental, if a property is unchanged it's supposed to
> keep as-is. Same with entire objects.
> 
> What's more, did you wire up the fb->dirty hook to make sure this
> stuff gets flushed correctly for frontbuffer rendering? Userspace is
> allowed to render into the current frontbuffer using gl, call all the
> flush/clear stuff and then call the DIRTY_FB ioctl, and things are
> supposed to show up on the screen. There's some ideas from the simple
> pipe helpers to essentially unify frontbuffer flushing and treat it
> like any atomic commit.

The PREs are stream processors, they are only prefetching (and
resolving) a few scanlines to internal SRAM. Any rendering to the
frontbuffer will properly show up without any additional dirty tracking.
You can think of the PREs as slightly bigger display FIFOs.

> tldr;  you need a PRE for all planes, you're looking for
> drm_atomic_add_affected_planes() to make sure all planes are in the
> update.

Thanks, I'll look at this.

Regards,
Lucas