[PATCH v10 0/5] drm/amdgpu: Add WAIT_EVENT ioctl for render-node events

Srinivasan Shanmugam <[email protected]>
Newsgroups org.freedesktop.lists.amd-gfx
Message-ID <[email protected]>
This series introduces a render-node WAIT_EVENT ioctl for retrieving
AMDGPU event records and their associated metadata.

WAIT_EVENT complements the EVENTFD notification interface rather than
replacing it. EVENTFD provides lightweight readiness notifications,
while WAIT_EVENT allows userspace to retrieve the corresponding event
type, queue identity, and event-specific metadata.

This series builds on the render-node EVENTFD infrastructure introduced
in:

  https://patchwork.freedesktop.org/series/164618/

It also depends on the EVENTFD producer series:

  drm/amdgpu: Wire GPU events into EVENTFD notifications
  https://patchwork.freedesktop.org/series/168402/

The WAIT_EVENT manager is maintained per drm_file. Queue-scoped requests
resolve the userspace queue_id to the corresponding user queue at the
ioctl boundary. Pending records are matched internally using queue
pointer equality, while queue_id remains a userspace identifier used at
the UAPI boundary and returned in event metadata.

The initial producer set records USERQ_EOP and QUEUE_RESET events by
reusing the existing queue-resolution paths:

  - USERQ_EOP records are generated from
    amdgpu_userq_process_fence_irq(), reusing the existing
    doorbell-to-queue lookup.

  - QUEUE_RESET records are generated from
    amdgpu_userq_handle_hung_queue(), where successful queue reset
    handling already converges.

This avoids additional queue lookups, queue scans, or changes to the
existing interrupt handling paths.

MEMORY_EXCEPTION and SCRATCH WAIT_EVENT producers are intentionally not
included in this series. MEMORY_EXCEPTION depends on separate PASID to
file-private lookup work, while SCRATCH follows a different notification
path and will be addressed separately.

Changes since v9
================

- Replace the relative timeout with an absolute CLOCK_MONOTONIC
  deadline, as suggested by Christian.

- Recompute the remaining timeout after every wakeup so interrupted or
  spurious wakeups continue to honor the original userspace deadline.

- Add kerneldoc for the WAIT_EVENT manager, timeout conversion,
  matching helpers, producer helpers, and teardown paths.

- Clarify the lifetime of the per-file WAIT_EVENT manager. The USERQ
  manager is torn down before the embedded WAIT_EVENT manager is
  finalized, so queues are removed from producer lookup paths before the
  manager can go out of scope.

- Keep queue pointers as the internal routing and matching key for
  queue-scoped events.

- Populate queue_id only at the WAIT_EVENT ioctl boundary after a record
  is matched, keeping queue_id as a userspace identifier rather than an
  internal routing key.

- Simplify queue reference cleanup by relying on
  amdgpu_userq_put() to handle NULL pointers.

- Improve documentation describing manager state, event matching, and
  teardown ordering.

Srinivasan Shanmugam (5):
  drm/amdgpu/uapi: Add WAIT_EVENT ioctl and metadata structures
  drm/amdgpu: Add wait-event manager and per-file lifetime plumbing
  drm/amdgpu: Remove queue-scoped WAIT_EVENT records on queue teardown
  drm/amdgpu: Record USERQ_EOP WAIT_EVENT notifications
  drm/amdgpu: Record QUEUE_RESET WAIT_EVENT notifications

 drivers/gpu/drm/amd/amdgpu/Makefile           |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h           |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c       |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c       |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c     |  33 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h     |   2 +
 .../gpu/drm/amd/amdgpu/amdgpu_wait_event.c    | 508 ++++++++++++++++++
 .../gpu/drm/amd/amdgpu/amdgpu_wait_event.h    | 101 ++++
 include/uapi/drm/amdgpu_drm.h                 | 115 ++++
 9 files changed, 769 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_wait_event.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_wait_event.h

-- 
2.34.1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.