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

[Stanislaw Gruszka]

Hi

On Tue, Aug 08, 2023 at 06:45:51PM -0600, Jeffrey Hugo wrote:
> 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?

You have right, this should be documented. I'll send separate patch for
this. 

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

I looked at git log from files in include/uapi/drm/ and seems that individual
driver uAPI changes are up to the driver maintainer for drm misc drivers.

At least there is no NACK from Oded so far :-) so I'm going to apply this,
since want the changes to be merged in 6.6 merge window.

Regards
Stanislaw