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
