On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad marius.vlad@collabora.com wrote:
On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad marius.vlad@collabora.com wrote:
On Fri, Jan 31, 2020 at 07:34:00AM +0000, Daniel Stone wrote:
On Thu, 5 Jul 2018 at 11:21, 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).
But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge
For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped.
Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits.
Gentle ping. I've tried out Linus's master tree and, and like Pekka, I've noticed this isn't integrated/added.
Noticed this is fixing (also) DPMS when multiple outputs are in use. Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing the warning quite often.
On which driver/chip does this happen?
I've tried it out on i915.
lspci -nn please.
Also adding Ville, who has an idea where this can all go wrong. The one he pointed out thus far is gen12+ only though. -Daniel
-Daniel
Thanks for writing this up Daniel, and for reminding me about it some time later as well ...
Reviewed-by: Daniel Stone daniels@collabora.com
Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch