diff options
| author | Maíra Canal <mcanal@igalia.com> | 2026-05-31 09:49:59 -0300 |
|---|---|---|
| committer | Christian König <christian.koenig@amd.com> | 2026-06-01 10:27:22 +0200 |
| commit | e84b07e0a30b371117f9a1120a4645c213f39cd9 (patch) | |
| tree | 0d98abda97207c862581ed2fb44d1fb8c11bdeb1 /include/uapi/drm | |
| parent | 21fcb222f0d1e1c9f5b04c09e9fb3408e13a0264 (diff) | |
| download | linux-next-e84b07e0a30b371117f9a1120a4645c213f39cd9.tar.gz linux-next-e84b07e0a30b371117f9a1120a4645c213f39cd9.zip | |
dma-fence: Clarify external lock use case in dma_fence_init() docs
The kerneldoc comment on dma_fence_init() and dma_fence_init64() describe
the legacy reason to pass an external lock as a need to prevent multiple
fences "from signaling out of order". However, this wording is a bit
misleading: a shared spinlock does not (and cannot) prevent the signaler
from signaling out of order. Signaling order is the driver's responsibility
regardless of whether the lock is shared or per-fence.
Reword both comments to better describe the legacy use cases where a
shared lock was needed.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260531125115.1136036-1-mcanal@igalia.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Diffstat (limited to 'include/uapi/drm')
0 files changed, 0 insertions, 0 deletions