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

[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.

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch