[Intel-xe] [PATCH] drm/xe/uapi: Remove DRM_IOCTL_XE_EXEC_QUEUE_SET_PROPERTY
Lucas De Marchi
lucas.demarchi at intel.com
Wed Dec 6 17:48:03 UTC 2023
On Wed, Dec 06, 2023 at 12:42:27PM -0500, Rodrigo Vivi wrote:
>On Wed, Dec 06, 2023 at 10:33:35AM -0600, Lucas De Marchi wrote:
>> On Wed, Dec 06, 2023 at 11:26:18AM -0500, Rodrigo Vivi wrote:
>> > On Wed, Dec 06, 2023 at 10:16:22AM -0600, Lucas De Marchi wrote:
>> > > On Wed, Dec 06, 2023 at 04:06:17PM +0000, Francois Dugast wrote:
>> > > > The exec_queue_set_property feature was removed in a previous
>> > > > commit ("drm/xe/uapi: Kill exec_queue_set_property") and is no
>> > > > longer usable, struct drm_xe_exec_queue_set_property does not
>> > > > exist anymore, so let's remove this.
>> >
>> > my bad, sorry
>> >
>> > > >
>> > > > Signed-off-by: Francois Dugast <francois.dugast at intel.com>
>> > >
>> > > should probably be a fixup to that patch? Anyway,
>> >
>> > no because it is in the uapi header that gets "copied" by the UMDs
>> > and IGT already merged and Mesa likely... and we cannot do fixup
>> > on their sides.
>>
>> wat?
>>
>> any UMDs would just copy the header and point to the commit it came
>> from. It doesn't matter if we used a fixup or not.
>
>But history wouldn't align. If they have already merged the commit with
>the sync pointing to a kernel commit that we do a later fixup, there
>would be a mismatch. Anyone looking the history in a later time would
>think that the UMD code was wrong.
>
>And instead of blaming me for having missed this line in the first
>commit they would unfairly blame whoever authored the UMD patch
>
>right Jose?
>
>But I would be okay with a fixup if that is okay for Jose.
when a fixup is amended, it's not like the commit remains the same. You
will have a different hash for the new commit. Just point to the new
commit which has the same commit message as the previous one.
And we are still on top of drm-tip. All these commits will still be
rebased and have their hashes changed anyway.
As long as we keep saving the tags so commits don't eventually
disappear from the remote, we should be fine.
Lucas De Marchi
>
>>
>> Lucas De Marchi
>>
>> >
>> > Acked-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
>> >
>> > >
>> > > Reviewed-by: Lucas De Marchi <lucas.demarchi at intel.com>
>> > >
>> > > Lucas De Marchi
>> > >
>> > > > ---
>> > > > include/uapi/drm/xe_drm.h | 1 -
>> > > > 1 file changed, 1 deletion(-)
>> > > >
>> > > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
>> > > > index dee750385161..346007e8074d 100644
>> > > > --- a/include/uapi/drm/xe_drm.h
>> > > > +++ b/include/uapi/drm/xe_drm.h
>> > > > @@ -53,7 +53,6 @@ extern "C" {
>> > > > #define DRM_IOCTL_XE_VM_BIND DRM_IOW(DRM_COMMAND_BASE + DRM_XE_VM_BIND, struct drm_xe_vm_bind)
>> > > > #define DRM_IOCTL_XE_EXEC_QUEUE_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_EXEC_QUEUE_CREATE, struct drm_xe_exec_queue_create)
>> > > > #define DRM_IOCTL_XE_EXEC_QUEUE_DESTROY DRM_IOW(DRM_COMMAND_BASE + DRM_XE_EXEC_QUEUE_DESTROY, struct drm_xe_exec_queue_destroy)
>> > > > -#define DRM_IOCTL_XE_EXEC_QUEUE_SET_PROPERTY DRM_IOW(DRM_COMMAND_BASE + DRM_XE_EXEC_QUEUE_SET_PROPERTY, struct drm_xe_exec_queue_set_property)
>> > > > #define DRM_IOCTL_XE_EXEC_QUEUE_GET_PROPERTY DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_EXEC_QUEUE_GET_PROPERTY, struct drm_xe_exec_queue_get_property)
>> > > > #define DRM_IOCTL_XE_EXEC DRM_IOW(DRM_COMMAND_BASE + DRM_XE_EXEC, struct drm_xe_exec)
>> > > > #define DRM_IOCTL_XE_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_WAIT_USER_FENCE, struct drm_xe_wait_user_fence)
>> > > > --
>> > > > 2.34.1
>> > > >
More information about the Intel-xe
mailing list