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