| Age | Commit message (Collapse) | Author |
|---|
|
drm_wait_pending_flip stopped waiting if drm_handle_event returned 0,
but that might have processed only some unrelated DRM events. As long as
the flip is pending, we have to keep waiting for its completion event.
Noticed while working on the previous fix.
(Ported from amdgpu commit 9045fb310f88780e250e60b80431ca153330e61b)
|
|
drmHandleEvent can be interrupted by a signal in read(), in which case
it doesn't process any events but returns -1, which
drm_handle_event propagated to its callers. This could cause the
following failure cascade:
1. drm_wait_pending_flip stopped waiting for a pending flip.
2. Its caller cleared drmmode_crtc->flip_pending before the flip
completed.
3. Another flip was attempted but got an unexpected EBUSY error because
the previous flip was still pending.
4. TearFree was disabled due to the error.
The solution is to call drmHandleEvent if it was interrupted by a
signal. We can do that in drm_handle_event, because when that is called,
either it is known that there are events ready to be processed, or the
caller has to wait for events to arrive anyway.
Bugzilla: https://bugs.freedesktop.org/109364
(Ported from amdgpu commit 3ff2cc225f6bc08364ee007fa54e9d0150adaf11)
|
|
It was still possible for nested xorg_list_for_each_entry_safe loops
to occur over the drm_vblank_signalled list, which could mess up that
list. Moving deferred events to a separate list allows processing the
drm_vblank_signalled list without xorg_list_for_each_entry_safe.
Bugzilla: https://bugs.freedesktop.org/108600
(Ported from amdgpu commit 51ba6dddee40c3688d4c7b12eabeab516ed153b7)
|
|
When an async flip is performed, and TearFree is enabled on the CRTC
used for timing, we schedule a vblank event for completing the page
flip. The DRM event queuing code treated this event like a vblank event,
but it needs to be treated like a page flip event.
(Ported from amdgpu commit e2c7369cae65069aa93eed1c0b678f975ce5c274)
|
|
At this point, we've already established that e->handler is NULL, no
need to check again in drm_queue_handle_one. This also makes it clearer
what's happening.
(Ported from amdgpu commit eda571222f5a6be47f8897e82d85199bb9d95251)
|
|
No need to process any events in that case.
(Ported from amdgpu commit ca5eb9894fff153c0a1df7bdc4a4745713309e27)
|
|
drm_wait_pending_flip can get called from drm_handle_event, in which
case xorg_list_for_each_entry_safe can end up processing the same entry
in both. To avoid this, just process the first list entry until the list
is empty.
(Ported from amdgpu commit 26770be44b89b83bf39c28f2fe284c8cb92ed0c0)
|
|
We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.
(Ported from amdgpu commit 7eea3e2cd74eed22e982319144e18ae5b1087b78)
|
|
This is to avoid submitting more flips while we are waiting for pending
ones to complete.
(Ported from amdgpu commit e52872da69ecc84dafb3355839e35b0383f0d228)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Instead of processing DRM events directly from drmHandleEvent's
callbacks, there are three phases:
1. drmHandleEvent is called, and signalled events are re-queued to
_signalled lists from its callbacks.
2. Signalled page flip completion events are processed.
3. Signalled vblank events are processed.
This should make sure that we never call drmHandleEvent from one of its
callbacks, which would usually result in blocking forever.
(Ported from amdgpu commit 739181c8d3334ff14b5a607895dfdeb29b0d9020)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Replacing the drmmode_crtc_wait_pending_event macro.
(Ported from amdgpu commit 6029794e8a35417faf825491a89b85f713c77fc1)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
And make radeon_drm_queue_handler not directly accessible outside of
radeon_drm_queue.c.
(Ported from amdgpu commit 0148283984c77f7a6e97026edc3093497547e0a4)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This allows a following change to be slightly simpler.
(Ported from amdgpu commit 8fcc3a9b43d3907052a83a96e5a2423afab5ad3f)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
xserver 1.13.0 was released on September 6th, 2012, almost 5 years ago.
This allows cleaning up a bunch of backwards compatibility code.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
We were adding entries at the start of the list, i.e. the list was
ordered from most recently added to least recently added. However, the
corresponding DRM events are generally expected to arrive in the same
order as they are queued, which means that radeon_drm_queue_alloc would
generally have to traverse the whole list to find the entry
corresponding to an arrived event. Fix this by adding entries at the end
of the list.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Should make the radeon_drm_queue_alloc error handling clearer, and gets
rid of a compile warning about it returning NULL.
Reviewed-by: Alexandre Demers <alexandre.f.demers@gmail.com>
|
|
If the memory for an entry was allocated at the same address as that for
a previously cancelled entry, the handler could theoretically be called
prematurely, triggered by the DRM event which was submitted for the
cancelled entry.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This allows for a minor simplification of the code.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Keep them around until the DRM event arrives, but then call the abort
functions instead of the handler functions.
This is a prerequisite for the following fix.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
v2: Rename struct radeon_drm_queue to struct radeon_drm_queue_event,
thanks to Richard Wilbur <richard.wilbur@gmail.com> for the suggestion.
Also changed the corresponding parameter and local variable names from
'q' to 'e'.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
