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

[Jeffrey Hugo]

On 8/9/2023 5:24 AM, Stanislaw Gruszka wrote:
> 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.

Sounds good.

If you like, Reviewed-by: Jeffrey Hugo <quic_jhugo at quicinc.com>

> 
>> 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.

I was referencing this -

"<snip> bugfixes for the qaic driver can be pushed directly by the qaic 
team. Still with acks/r-b requirements as per usual, and I guess for 
anything bigger/new uapi an ack from oded is needed."

https://lore.kernel.org/dri-devel/ZC13QdSRybIe3nvk@phenom.ffwll.local/

Maybe that is qaic specific rules since we are rather new to the 
community and still learning.

> 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