| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
(Cherry picked from radeon commit b4af8a327ed8420f0ff4ea0f113f4a59406ed4d3)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
