drm/i915: don't whitelist oacontrol in cmd parser
authorRobert Bragg <robert@sixbynine.org>
Tue, 8 Nov 2016 12:51:48 +0000 (12:51 +0000)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 22 Nov 2016 13:32:42 +0000 (14:32 +0100)
commit10ff401df041e57afc2b1619cd252b86d0ae5f30
tree03b51b9b355c821fc43f88b6980b063051210062
parent9bbeaedb664a6d3e1cfbe6b0c2f07bf667512456
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
drivers/gpu/drm/i915/i915_cmd_parser.c