summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_oa_hsw.h
diff options
context:
space:
mode:
authorRobert Bragg <robert@sixbynine.org>2016-11-08 12:51:48 +0000
committerDaniel Vetter <daniel.vetter@ffwll.ch>2016-11-22 14:32:42 +0100
commit10ff401df041e57afc2b1619cd252b86d0ae5f30 (patch)
tree03b51b9b355c821fc43f88b6980b063051210062 /drivers/gpu/drm/i915/i915_oa_hsw.h
parent9bbeaedb664a6d3e1cfbe6b0c2f07bf667512456 (diff)
drm/i915: don't whitelist oacontrol in cmd parser
Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL via a batch buffer isn't able to report useable data without a more complete OA unit configuration. Mesa handles the possibility that writes to OACONTROL may not be allowed and so only advertises the extension after explicitly testing that a write to OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist should be ok for userspace. Removing this simplifies adding a new kernel api for configuring the OA unit without needing to consider the possibility that userspace might trample on OACONTROL state which we'd like to start managing within the kernel instead. In particular running any Mesa based GL application currently results in clearing OACONTROL when initializing which would disable the capturing of metrics. v2: This bumps the command parser version from 8 to 9, as the change is visible to userspace. Signed-off-by: Robert Bragg <robert@sixbynine.org> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161108125148.25007-1-robert@sixbynine.org
Diffstat (limited to 'drivers/gpu/drm/i915/i915_oa_hsw.h')
0 files changed, 0 insertions, 0 deletions