| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
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.
v2:
* Use ErrorF instead of xf86DrvMsg with hard-coded screen 0.
Bugzilla: https://bugs.freedesktop.org/109364
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> # v1
|
|
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.
v2:
* Refactor drm_handle_vblank_signalled helper function, less code
duplication => better readability (Alex Deucher)
Bugzilla: https://bugs.freedesktop.org/108600
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
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.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
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.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
No need to process any events in that case.
v2:
* Re-check drmmode_crtc->flip_pending after processing each event
|
|
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.
|
|
We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.
|
|
This is to avoid submitting more flips while we are waiting for pending
ones to complete.
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.
|
|
Replacing the drmmode_crtc_wait_pending_event macro.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
And make amdgpu_drm_queue_handler not directly accessible outside of
amdgpu_drm_queue.c.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This allows a following change to be slightly simpler.
|
|
xserver 1.13.0 was released on September 6th, 2012, almost 5 years ago.
This allows cleaning up a bunch of backwards compatibility code.
(Ported from radeon commit 5cdd334b3402c2431deb3a87a8d04ef590da53ee)
Reviewed-by: Alex Deucher <alexander.deucher@amd.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 amdgpu_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.
(Ported from radeon commit 3e24770b1b472fc15df56d06f5f04778c9db63dd)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Should make the amdgpu_drm_queue_alloc error handling clearer, and gets
rid of a compile warning about it returning NULL.
(Ported from radeon commit a37af701768b12d86868a831a79f1e02ee4968cf)
Reviewed-by: Alex Deucher <alexander.deucher@amd.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.
(Ported from radeon commit 4693b1bd5b5c381e8b7b68a6f7f0c6696d6a68df)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This allows for a minor simplification of the code.
(Ported from radeon commit f5d968cbba3c9b7ec202161f2157d8d64778c817)
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.
(Ported from radeon commit 3989766edde85d1abe7024577b98fc9b007bc02a)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
(Cherry picked from radeon commit b4af8a327ed8420f0ff4ea0f113f4a59406ed4d3)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
