On Tue, 03 Mar 2020 14:19:04 -0800, Umesh Nerlige Ramappa wrote: > > From: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> > > This let's the application choose to be driven by the interrupt > mechanism of the HW. In conjuction with long periods for checks for > the availability of data on the CPU, this can reduce the CPU load when > doing capture of OA data. > > v2: Version the new parameter (Joonas) > v3: Rebase (Umesh) > > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> > Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@xxxxxxxxx> [snip] > + /** > + * Specifying this property sets up the interrupt mechanism for the OA > + * buffer in i915. This option in conjuction with a long polling delay > + * for avaibility of OA data can reduce CPU load significantly if you > + * do not care about OA data being read as soon as it's available. > + * > + * This property is available in perf revision 5. > + */ > + DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT, What if we do not expose this parameter in the uapi at all and internally decide in i915 whether to leave the interrupt either always enabled or always disabled (and in that case always use the hrtimer)? This way we retain flexibility in i915 if hardware evolves in the future e.g. to use watermarks for the interrupt, without yielding control to userspace. Overall I feel we should avoid exposing unnecessary details of the internal implemenation to userspace, they would be neither interested in knowing internal details nor know how to properly use these parameters. Shouldn't the driver be able to make these kinds of decisions internally? At this point the only parameter which implicitly exposed to userspace is the hrtimer poll period, so perhaps all we need to do is to expose that in the uapi? Thoughts? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
