[PATCH 4/6] accel/ivpu: Add param ioctl to identify capabilities

[Jeffrey Hugo]

On 8/8/2023 2:52 AM, Stanislaw Gruszka wrote:
> On Thu, Aug 03, 2023 at 10:37:37AM +0200, Stanislaw Gruszka wrote:
>>> Seems like we might want to decide this now, because if we define a iVPU
>>> specific ioctl as proposed here, but then switch to an Accel-wide mechanism
>>> later, iVPU is going to be stuck supporting both.
>>
>> For the record, we do not add new ioctl in this patch, we just extend
>> existing DRM_IOCTL_IVPU_GET_PARAM one.
> 
> To avoid confusion, I'll change the topic and commit massage
> before applying:
> 
> accel/ivpu: Extend get_param ioctl to identify capabilities
> 
> Add DRM_IVPU_PARAM_CAPABILITIES parameters to get_param ioctl to query
> driver capabilities. For now use it for identify metric streamer and
> new dma memory range features. Currently upstream version of intel_vpu
> does not have those, they will be added it the future.

This is perhaps slightly better.  I didn't find the original one confusing.

Seems like no opinions on pushing this up to the framework.  You did 
point out DRM drivers have driver level ones, so carry-on I guess.

Seems ok to me.  I'd prefer to see some comments in the uapi header 
describing what the DRM_IVPU_CAP_* values mean.  A bit more than "device 
has metric streamer support" - what is metric streamer, and why might 
userspace care?

However, as a uAPI change, is Oded's Ack not required?  I thought that 
was the rule.

-Jeff