[PATCH 2/3] drm/v3d: update UAPI to match user-space for V3D 7.x

[itoral]

On 2023-09-28 15:05, Maira Canal wrote:
> Hi Iago,
> 
> On 9/28/23 08:45, Iago Toral Quiroga wrote:
>> V3D t.x takes a new parameter to configure TFU jobs that needs
> 
> I believe t.x should be 7.x.
> 
>> to be provided by user space.
> 
> As I mentioned before, please, add your s-o-b.
> 
>> ---
>>   include/uapi/drm/v3d_drm.h | 5 +++++
>>   1 file changed, 5 insertions(+)
>> 
>> diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
>> index 3dfc0af8756a..1a7d7a689de3 100644
>> --- a/include/uapi/drm/v3d_drm.h
>> +++ b/include/uapi/drm/v3d_drm.h
>> @@ -319,6 +319,11 @@ struct drm_v3d_submit_tfu {
>>     	/* Pointer to an array of ioctl extensions*/
>>   	__u64 extensions;
>> +
>> +	struct {
>> +		__u32 ioc;
>> +		__u32 pad;
>> +	} v71;
> 
> Is there any possibility that the name of the struct could be more
> meaningful?

The v71 stands for the hardware version where this field was introduced,
so I am not sure how much more meaningful we can make it :)

The idea for this was to pack version-specific fields into structs named
vXX so that you can quickly tell in which version specific fields
started being relevant directly from the code without having to look for
documentation elsewhere. I don't have a better alternative for the name,
since the point is to make the version explicit, but I am open to
suggestions if you have any.

Of course, we can also get rid of the struct if you prefer that, but
then we should document explicitly that this field only applies to v71
hardware and we would lose the explicit versioning when accessing the
field from the code (unless we decide to add the v71 as a prefix or
suffix in the ioc field, but that is kind of the same thing).

Iago

> 
> Best Regards,
> - Maíra
> 
>>   };
>>     /* Submits a compute shader for dispatch.  This job will block on any