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
