AMD General

Hi Christian,

> -----Original Message-----
> From: Koenig, Christian <[email protected]>
> Sent: Friday, June 5, 2026 6:51 PM
> To: SHANMUGAM, SRINIVASAN <[email protected]>;
> Deucher, Alexander <[email protected]>
> Cc: [email protected]
> Subject: Re: [PATCH v9 05/11] drm/amdgpu/uapi: Define kernel event types for
> EVENTFD subscriptions
>
> On 6/3/26 18:33, Srinivasan Shanmugam wrote:
> > The current EVENTFD UAPI describes subscriptions using a
> > userspace-defined event_id and reserves queue_id for future use.
> >
> > That no longer matches the intended render-node event model. Userspace
> > should subscribe to kernel-defined event types, while the kernel keeps
> > control of event semantics and signaling sources.
> >
> > Add a shared UAPI enum for AMDGPU EVENTFD event types and update the
> > EVENTFD ioctl documentation to describe subscriptions as notification-only.
> >
> > queue_id remains part of the UAPI and is now used to distinguish
> > queue-scoped subscriptions from GPU/device-scoped subscriptions.
> >
> > USERQ_EOP, QUEUE_RESET, and SCRATCH may use queue_id for
> > queue-specific subscriptions. MEMORY_EXCEPTION is currently GPU-scoped
> > and requires queue_id = 0.
> >
> > Cc: Alex Deucher <[email protected]>
> > Cc: Christian König <[email protected]>
> > Signed-off-by: Srinivasan Shanmugam <[email protected]>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  6 +++---
> >  include/uapi/drm/amdgpu_drm.h           | 25 +++++++++++++++++++------
> >  2 files changed, 22 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index cd127a271c19..75fc3a74db28 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -643,7 +643,7 @@ int amdgpu_eventfd_ioctl(struct drm_device *dev, void
> *data,
> >     if (!fpriv)
> >             return -EINVAL;
> >
> > -   if (args->flags || !args->event_id || args->eventfd < 0)
> > +   if (args->flags || !args->event_type || args->eventfd < 0)
> >             return -EINVAL;
> >
> >     /*
> > @@ -656,11 +656,11 @@ int amdgpu_eventfd_ioctl(struct drm_device *dev, void
> *data,
> >     switch (args->op) {
> >     case DRM_AMDGPU_EVENTFD_OP_BIND:
> >             return amdgpu_eventfd_bind(&fpriv->eventfd_mgr,
> > -                                      args->event_id,
> > +                                      args->event_type,
> >                                        args->eventfd);
> >     case DRM_AMDGPU_EVENTFD_OP_UNBIND:
> >             return amdgpu_eventfd_unbind(&fpriv->eventfd_mgr,
> > -                                        args->event_id,
> > +                                        args->event_type,
> >                                          args->eventfd);
> >     default:
> >             return -EINVAL;
> > diff --git a/include/uapi/drm/amdgpu_drm.h
> > b/include/uapi/drm/amdgpu_drm.h index 63cde4487c47..3dffd9e581a1
> > 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> > +++ b/include/uapi/drm/amdgpu_drm.h
> > @@ -207,28 +207,41 @@ union drm_amdgpu_gem_create {
> >     struct drm_amdgpu_gem_create_out        out;
> >  };
> >
> > +enum drm_amdgpu_event_type {
> > +   DRM_AMDGPU_EVENT_TYPE_INVALID = 0,
>
> What exactly is the invalid event_type?

INVALID was not intended to be a real event. It was only there to reserve value 
0.
Since the kernel already rejects 0, the enum entry is unnecessary. I will 
remove it.

Thanks!,
Srini



Reply via email to