[PATCH 14/17] drm/msm: add atomic support

Rob Clark robdclark at gmail.com
Wed May 28 08:19:16 PDT 2014


On Wed, May 28, 2014 at 9:21 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Tue, May 27, 2014 at 07:32:46PM -0400, Rob Clark wrote:
>> On Tue, May 27, 2014 at 6:09 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> > On Tue, May 27, 2014 at 04:06:28PM -0400, Rob Clark wrote:
>> >> On Tue, May 27, 2014 at 3:26 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> >
>> > [snip]
>> >
>> >> Well, there was the NONBLOCK atomic flag.. I'm not entirely sure if we
>> >> should hang so much off of that one flag.
>> >
>> > Yeah, a separate VBLANK_SYNCED might be useful. Apparently people also
>> > want non-blocking modesets.
>>
>> random-diverging-from-original-topic-thought.. seems like userspace
>> just wants a deadline/timeout (hopefully in units of vblanks).. at
>> least to the level of "I want this to happen on the next vblank (after
>> rendering completes), or give me an error" vs "I want this to complete
>> atomically even if it takes a few extra vblanks for things to sort
>> out"..
>>
>> I guess that amounts to what you mean by VBLANK_SYNCED flag, but
>> VBLANKED_SYNCED might not be a good name.. at least for some hw all
>> you can do is vblank sync'd..
>
> Hm, we might as well go full monty and allow userspace to request a
> specific vblank counter. Would be useful for e.g. queuing up a bunch of
> video frames, which some hw can do. But that would then require cancelling
> of existing flips, so I guess for now a simple VBLANK_SYNCED flag which
> emulates pageflip behaviour should be good enough.

The full on vblank counter and queue stuff up could be interesting..
not entirely sure how we'd manage ->atomic_check() against a not yet
applied base state.  I suppose it is just a matter of copying the
previous-state values for new state objects from the not-yet applied
state, rather than {plane,crtc,etc}->state..

And since state objects are refcnt'd I guess forming a linked list out
of 'em would not be hard.

Probably we should not allow queuing in the beginning.  But does kinda
seem like some magic is possible to handle this.

> That would also be useful if userspace attempts an atomic update on
> drivers which only support atomic modeset (through the crtc helpers), but
> can't do vblank synced updates. Then they could easily reject those. After
> all current drivers also often lack a pageflip implementation ...

yeah.. but I guess this mainly the server chips and old stuff?  I
wonder how many drivers support multiple crtcs but not pageflip?

BR,
-R

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


More information about the dri-devel mailing list