From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Kenneth Graunke <kenneth@whitecape.org>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Jani Nikula <jani.nikula@intel.com>
Subject: [PATCH 4.9 05/31] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.
Date: Sun, 16 Apr 2017 10:03:56 +0200 [thread overview]
Message-ID: <20170416080222.095964576@linuxfoundation.org> (raw)
In-Reply-To: <20170416080221.808058771@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kenneth Graunke <kenneth@whitecape.org>
commit 0f5418e564ac6452b9086295646e602a9addc4bf upstream.
This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
(indicating the optional feature is not supported), and makes execbuf
always return -EINVAL if the flags are used.
Apparently, no userspace ever shipped which used this optional feature:
I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
and there were zero commits showing a use of these flags. Kernel commit
72bfa19c8deb4 apparently introduced the feature prematurely. According
to Chris, the intention was to use this in cairo-drm, but "the use was
broken for gen6", so I don't think it ever happened.
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync with the hardware per-context value. This meant that using
them is actually unsafe: a client which tried to use them could damage
the state of other clients, causing the GPU to interpret their BO
offsets as absolute pointers, leading to bogus memory reads.
These flags were also never ported to execlist mode, making them no-ops
on Gen9+ (which requires execlists), and Gen8 in the default mode.
On Gen8+, userspace can write these registers directly, achieving the
same effect. On Gen6-7.5, it likely makes sense to extend the command
parser to support them. I don't think anyone wants this on Gen4-5.
Based on a patch by Dave Gordon.
v3: Return -ENODEV for the getparam, as this is what we do for other
obsolete features. Suggested by Chris Wilson.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.org
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170313170433.26843-1-chris@chris-wilson.co.uk
(cherry picked from commit ef0f411f51475f4eebf9fc1b19a85be698af19ff)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.c | 4 --
drivers/gpu/drm/i915/i915_drv.h | 2 -
drivers/gpu/drm/i915/i915_gem.c | 2 -
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 52 +----------------------------
4 files changed, 3 insertions(+), 57 deletions(-)
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -240,6 +240,7 @@ static int i915_getparam(struct drm_devi
case I915_PARAM_IRQ_ACTIVE:
case I915_PARAM_ALLOW_BATCHBUFFER:
case I915_PARAM_LAST_DISPATCH:
+ case I915_PARAM_HAS_EXEC_CONSTANTS:
/* Reject all old ums/dri params. */
return -ENODEV;
case I915_PARAM_CHIPSET_ID:
@@ -266,9 +267,6 @@ static int i915_getparam(struct drm_devi
case I915_PARAM_HAS_BSD2:
value = intel_engine_initialized(&dev_priv->engine[VCS2]);
break;
- case I915_PARAM_HAS_EXEC_CONSTANTS:
- value = INTEL_GEN(dev_priv) >= 4;
- break;
case I915_PARAM_HAS_LLC:
value = HAS_LLC(dev_priv);
break;
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1751,8 +1751,6 @@ struct drm_i915_private {
const struct intel_device_info info;
- int relative_constants_mode;
-
void __iomem *regs;
struct intel_uncore uncore;
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4587,8 +4587,6 @@ i915_gem_load_init(struct drm_device *de
init_waitqueue_head(&dev_priv->gpu_error.wait_queue);
init_waitqueue_head(&dev_priv->gpu_error.reset_queue);
- dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
-
init_waitqueue_head(&dev_priv->pending_flip_queue);
dev_priv->mm.interruptible = true;
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1454,10 +1454,7 @@ execbuf_submit(struct i915_execbuffer_pa
struct drm_i915_gem_execbuffer2 *args,
struct list_head *vmas)
{
- struct drm_i915_private *dev_priv = params->request->i915;
u64 exec_start, exec_len;
- int instp_mode;
- u32 instp_mask;
int ret;
ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas);
@@ -1468,56 +1465,11 @@ execbuf_submit(struct i915_execbuffer_pa
if (ret)
return ret;
- instp_mode = args->flags & I915_EXEC_CONSTANTS_MASK;
- instp_mask = I915_EXEC_CONSTANTS_MASK;
- switch (instp_mode) {
- case I915_EXEC_CONSTANTS_REL_GENERAL:
- case I915_EXEC_CONSTANTS_ABSOLUTE:
- case I915_EXEC_CONSTANTS_REL_SURFACE:
- if (instp_mode != 0 && params->engine->id != RCS) {
- DRM_DEBUG("non-0 rel constants mode on non-RCS\n");
- return -EINVAL;
- }
-
- if (instp_mode != dev_priv->relative_constants_mode) {
- if (INTEL_INFO(dev_priv)->gen < 4) {
- DRM_DEBUG("no rel constants on pre-gen4\n");
- return -EINVAL;
- }
-
- if (INTEL_INFO(dev_priv)->gen > 5 &&
- instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
- DRM_DEBUG("rel surface constants mode invalid on gen5+\n");
- return -EINVAL;
- }
-
- /* The HW changed the meaning on this bit on gen6 */
- if (INTEL_INFO(dev_priv)->gen >= 6)
- instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
- }
- break;
- default:
- DRM_DEBUG("execbuf with unknown constants: %d\n", instp_mode);
+ if (args->flags & I915_EXEC_CONSTANTS_MASK) {
+ DRM_DEBUG("I915_EXEC_CONSTANTS_* unsupported\n");
return -EINVAL;
}
- if (params->engine->id == RCS &&
- instp_mode != dev_priv->relative_constants_mode) {
- struct intel_ring *ring = params->request->ring;
-
- ret = intel_ring_begin(params->request, 4);
- if (ret)
- return ret;
-
- intel_ring_emit(ring, MI_NOOP);
- intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
- intel_ring_emit_reg(ring, INSTPM);
- intel_ring_emit(ring, instp_mask << 16 | instp_mode);
- intel_ring_advance(ring);
-
- dev_priv->relative_constants_mode = instp_mode;
- }
-
if (args->flags & I915_EXEC_GEN7_SOL_RESET) {
ret = i915_reset_gen7_sol_offsets(params->request);
if (ret)
next prev parent reply other threads:[~2017-04-16 8:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-16 8:03 [PATCH 4.9 00/31] 4.9.23-stable review Greg Kroah-Hartman
2017-04-16 8:03 ` Greg Kroah-Hartman [this message]
2017-04-16 8:03 ` [PATCH 4.9 06/31] drm/i915: Stop using RP_DOWN_EI on Baytrail Greg Kroah-Hartman
2017-04-16 8:03 ` [PATCH 4.9 07/31] drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker) Greg Kroah-Hartman
2017-04-16 8:03 ` [PATCH 4.9 08/31] orangefs: fix memory leak of string new on exit path Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 09/31] orangefs: Dan Carpenter influenced cleanups Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 10/31] orangefs: fix buffer size mis-match between kernel space and user space Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 12/31] rt2x00usb: fix anchor initialization Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 13/31] rt2x00usb: do not anchor rx and tx urbs Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 14/31] rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 16/31] MIPS: Introduce irq_stack Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 17/31] MIPS: Stack unwinding while on IRQ stack Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 18/31] MIPS: Only change $28 to thread_info if coming from user mode Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 19/31] MIPS: Switch to the irq_stack in interrupts Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 20/31] MIPS: Select HAVE_IRQ_EXIT_ON_IRQ_STACK Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 21/31] MIPS: IRQ Stack: Fix erroneous jal to plat_irq_dispatch Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 24/31] [PATCH] Revert "drm/i915/execlists: Reset RING registers upon resume" Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 25/31] net/packet: fix overflow in check for priv area size Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 26/31] blk-mq: Avoid memory reclaim when remapping queues Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 27/31] usb: hub: Wait for connection to be reestablished after port reset Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 28/31] net/mlx4_en: Fix bad WQE issue Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 29/31] net/mlx4_core: Fix racy CQ (Completion Queue) free Greg Kroah-Hartman
2017-04-16 8:04 ` [PATCH 4.9 30/31] net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions Greg Kroah-Hartman
2017-04-16 21:29 ` [PATCH 4.9 00/31] 4.9.23-stable review Guenter Roeck
2017-04-17 18:21 ` Shuah Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170416080222.095964576@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=jani.nikula@intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kenneth@whitecape.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).