On Wed, 23 Sep 2020 11:26:39 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> I'm really not awake yet ...
> 
> On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 22 Sep 2020 20:18:34 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >  
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).

> > If yes, and *if* userspace is single-threaded wrt. to KMS updates,
> > that might offer a way to work around it in userspace. But if userspace
> > is flipping other CRTCs from other threads, TEST_ONLY commit does not
> > help because another thread may cut in and make a CRTC busy.  
> 
> This is not a legit programming model for atomic. An atomic commit is
> always relative to the current state. If that state changes, then you
> need to re-run your TEST_ONLY commit. So multiple threads changing
> state in parallel isn't really a good idea anyway. Minimally we'd need
> some kind of TEST_ONLY pile-up, so you can validate a change assuming
> another commit has already happened. That's even harder than deep
> queues on the commit side, we'd probably need full rollback of
> commits.

Yes, very good point. I forgot that for a moment.


Thanks,
pq