2015-07-24 19:55:11 +08:00
|
|
|
/*
|
|
|
|
* Copyright © 2008-2015 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <drm/i915_drm.h>
|
2019-05-28 17:29:50 +08:00
|
|
|
|
2015-07-24 19:55:11 +08:00
|
|
|
#include "i915_drv.h"
|
2019-05-28 17:29:50 +08:00
|
|
|
#include "i915_scatterlist.h"
|
2019-06-13 15:32:54 +08:00
|
|
|
#include "i915_vgpu.h"
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2015-07-24 23:40:12 +08:00
|
|
|
/**
|
|
|
|
* DOC: fence register handling
|
|
|
|
*
|
|
|
|
* Important to avoid confusions: "fences" in the i915 driver are not execution
|
|
|
|
* fences used to track command completion but hardware detiler objects which
|
|
|
|
* wrap a given range of the global GTT. Each platform has only a fairly limited
|
|
|
|
* set of these objects.
|
|
|
|
*
|
|
|
|
* Fences are used to detile GTT memory mappings. They're also connected to the
|
2016-01-05 11:29:17 +08:00
|
|
|
* hardware frontbuffer render tracking and hence interact with frontbuffer
|
|
|
|
* compression. Furthermore on older platforms fences are required for tiled
|
2015-07-24 23:40:12 +08:00
|
|
|
* objects used by the display engine. They can also be used by the render
|
|
|
|
* engine - they're required for blitter commands and are optional for render
|
|
|
|
* commands. But on gen4+ both display (with the exception of fbc) and rendering
|
|
|
|
* have their own tiling state bits and don't need fences.
|
|
|
|
*
|
|
|
|
* Also note that fences only support X and Y tiling and hence can't be used for
|
|
|
|
* the fancier new tiling formats like W, Ys and Yf.
|
|
|
|
*
|
|
|
|
* Finally note that because fences are such a restricted resource they're
|
|
|
|
* dynamically associated with objects. Furthermore fence state is committed to
|
2016-01-05 11:29:17 +08:00
|
|
|
* the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore code must
|
|
|
|
* explicitly call i915_gem_object_get_fence() to synchronize fencing status
|
2015-07-24 23:40:12 +08:00
|
|
|
* for cpu access. Also note that some code wants an unfenced view, for those
|
|
|
|
* cases the fence can be removed forcefully with i915_gem_object_put_fence().
|
|
|
|
*
|
|
|
|
* Internally these functions will synchronize with userspace access by removing
|
|
|
|
* CPU ptes into GTT mmaps (not the GTT ptes themselves) as needed.
|
|
|
|
*/
|
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
#define pipelined 0
|
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
static void i965_write_fence_reg(struct i915_fence_reg *fence,
|
2016-08-19 00:17:00 +08:00
|
|
|
struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 21:33:26 +08:00
|
|
|
i915_reg_t fence_reg_lo, fence_reg_hi;
|
2015-07-24 19:55:11 +08:00
|
|
|
int fence_pitch_shift;
|
2016-08-19 00:17:00 +08:00
|
|
|
u64 val;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2018-02-10 05:58:46 +08:00
|
|
|
if (INTEL_GEN(fence->i915) >= 6) {
|
2016-08-19 00:17:00 +08:00
|
|
|
fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
|
|
|
|
fence_reg_hi = FENCE_REG_GEN6_HI(fence->id);
|
2015-09-21 23:05:14 +08:00
|
|
|
fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT;
|
2016-08-19 00:17:00 +08:00
|
|
|
|
2015-07-24 19:55:11 +08:00
|
|
|
} else {
|
2016-08-19 00:17:00 +08:00
|
|
|
fence_reg_lo = FENCE_REG_965_LO(fence->id);
|
|
|
|
fence_reg_hi = FENCE_REG_965_HI(fence->id);
|
2015-07-24 19:55:11 +08:00
|
|
|
fence_pitch_shift = I965_FENCE_PITCH_SHIFT;
|
|
|
|
}
|
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
val = 0;
|
|
|
|
if (vma) {
|
|
|
|
unsigned int stride = i915_gem_object_get_stride(vma->obj);
|
2016-08-15 17:48:52 +08:00
|
|
|
|
2017-01-10 00:16:10 +08:00
|
|
|
GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
|
2017-01-10 22:47:34 +08:00
|
|
|
GEM_BUG_ON(!IS_ALIGNED(vma->node.start, I965_FENCE_PAGE));
|
|
|
|
GEM_BUG_ON(!IS_ALIGNED(vma->fence_size, I965_FENCE_PAGE));
|
|
|
|
GEM_BUG_ON(!IS_ALIGNED(stride, 128));
|
2017-01-10 00:16:10 +08:00
|
|
|
|
2017-01-10 22:47:34 +08:00
|
|
|
val = (vma->node.start + vma->fence_size - I965_FENCE_PAGE) << 32;
|
2017-01-10 00:16:10 +08:00
|
|
|
val |= vma->node.start;
|
2016-08-15 17:48:52 +08:00
|
|
|
val |= (u64)((stride / 128) - 1) << fence_pitch_shift;
|
2017-01-10 00:16:08 +08:00
|
|
|
if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y)
|
2016-08-19 00:17:00 +08:00
|
|
|
val |= BIT(I965_FENCE_TILING_Y_SHIFT);
|
2015-07-24 19:55:11 +08:00
|
|
|
val |= I965_FENCE_REG_VALID;
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
if (!pipelined) {
|
2019-06-04 20:00:21 +08:00
|
|
|
struct intel_uncore *uncore = &fence->i915->uncore;
|
2016-08-19 00:17:00 +08:00
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* To w/a incoherency with non-atomic 64-bit register updates,
|
2016-08-19 00:17:00 +08:00
|
|
|
* we split the 64-bit update into two 32-bit writes. In order
|
|
|
|
* for a partial fence not to be evaluated between writes, we
|
|
|
|
* precede the update with write to turn off the fence register,
|
|
|
|
* and only enable the fence as the last step.
|
|
|
|
*
|
|
|
|
* For extra levels of paranoia, we make sure each step lands
|
|
|
|
* before applying the next step.
|
|
|
|
*/
|
2019-06-04 20:00:21 +08:00
|
|
|
intel_uncore_write_fw(uncore, fence_reg_lo, 0);
|
|
|
|
intel_uncore_posting_read_fw(uncore, fence_reg_lo);
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
intel_uncore_write_fw(uncore, fence_reg_hi, upper_32_bits(val));
|
|
|
|
intel_uncore_write_fw(uncore, fence_reg_lo, lower_32_bits(val));
|
|
|
|
intel_uncore_posting_read_fw(uncore, fence_reg_lo);
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
static void i915_write_fence_reg(struct i915_fence_reg *fence,
|
2016-08-19 00:17:00 +08:00
|
|
|
struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
|
|
|
u32 val;
|
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
val = 0;
|
|
|
|
if (vma) {
|
|
|
|
unsigned int tiling = i915_gem_object_get_tiling(vma->obj);
|
|
|
|
bool is_y_tiled = tiling == I915_TILING_Y;
|
|
|
|
unsigned int stride = i915_gem_object_get_stride(vma->obj);
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2017-01-10 00:16:10 +08:00
|
|
|
GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
|
|
|
|
GEM_BUG_ON(vma->node.start & ~I915_FENCE_START_MASK);
|
2017-01-10 00:16:11 +08:00
|
|
|
GEM_BUG_ON(!is_power_of_2(vma->fence_size));
|
2017-01-10 22:47:34 +08:00
|
|
|
GEM_BUG_ON(!IS_ALIGNED(vma->node.start, vma->fence_size));
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
if (is_y_tiled && HAS_128_BYTE_Y_TILING(fence->i915))
|
2017-01-10 00:16:10 +08:00
|
|
|
stride /= 128;
|
2015-07-24 19:55:11 +08:00
|
|
|
else
|
2017-01-10 00:16:10 +08:00
|
|
|
stride /= 512;
|
|
|
|
GEM_BUG_ON(!is_power_of_2(stride));
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-15 17:48:52 +08:00
|
|
|
val = vma->node.start;
|
2016-08-19 00:17:00 +08:00
|
|
|
if (is_y_tiled)
|
|
|
|
val |= BIT(I830_FENCE_TILING_Y_SHIFT);
|
2017-01-10 00:16:11 +08:00
|
|
|
val |= I915_FENCE_SIZE_BITS(vma->fence_size);
|
2017-01-10 00:16:10 +08:00
|
|
|
val |= ilog2(stride) << I830_FENCE_PITCH_SHIFT;
|
|
|
|
|
2015-07-24 19:55:11 +08:00
|
|
|
val |= I830_FENCE_REG_VALID;
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
if (!pipelined) {
|
2019-06-04 20:00:21 +08:00
|
|
|
struct intel_uncore *uncore = &fence->i915->uncore;
|
2016-08-19 00:17:00 +08:00
|
|
|
i915_reg_t reg = FENCE_REG(fence->id);
|
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
intel_uncore_write_fw(uncore, reg, val);
|
|
|
|
intel_uncore_posting_read_fw(uncore, reg);
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
static void i830_write_fence_reg(struct i915_fence_reg *fence,
|
2016-08-19 00:17:00 +08:00
|
|
|
struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
2016-08-15 17:48:52 +08:00
|
|
|
u32 val;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
val = 0;
|
|
|
|
if (vma) {
|
|
|
|
unsigned int stride = i915_gem_object_get_stride(vma->obj);
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2017-01-10 00:16:10 +08:00
|
|
|
GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
|
|
|
|
GEM_BUG_ON(vma->node.start & ~I830_FENCE_START_MASK);
|
2017-01-10 00:16:11 +08:00
|
|
|
GEM_BUG_ON(!is_power_of_2(vma->fence_size));
|
2017-01-10 00:16:10 +08:00
|
|
|
GEM_BUG_ON(!is_power_of_2(stride / 128));
|
2017-01-10 22:47:34 +08:00
|
|
|
GEM_BUG_ON(!IS_ALIGNED(vma->node.start, vma->fence_size));
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-15 17:48:52 +08:00
|
|
|
val = vma->node.start;
|
2017-01-10 00:16:11 +08:00
|
|
|
if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y)
|
2016-08-19 00:17:00 +08:00
|
|
|
val |= BIT(I830_FENCE_TILING_Y_SHIFT);
|
2017-01-10 00:16:11 +08:00
|
|
|
val |= I830_FENCE_SIZE_BITS(vma->fence_size);
|
2017-01-10 00:16:10 +08:00
|
|
|
val |= ilog2(stride / 128) << I830_FENCE_PITCH_SHIFT;
|
2015-07-24 19:55:11 +08:00
|
|
|
val |= I830_FENCE_REG_VALID;
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
if (!pipelined) {
|
2019-06-04 20:00:21 +08:00
|
|
|
struct intel_uncore *uncore = &fence->i915->uncore;
|
2016-08-19 00:17:00 +08:00
|
|
|
i915_reg_t reg = FENCE_REG(fence->id);
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
intel_uncore_write_fw(uncore, reg, val);
|
|
|
|
intel_uncore_posting_read_fw(uncore, reg);
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
static void fence_write(struct i915_fence_reg *fence,
|
2016-08-19 00:17:00 +08:00
|
|
|
struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* Previous access through the fence register is marshalled by
|
2016-08-19 00:17:00 +08:00
|
|
|
* the mb() inside the fault handlers (i915_gem_release_mmaps)
|
|
|
|
* and explicitly managed for internal users.
|
2015-07-24 19:55:11 +08:00
|
|
|
*/
|
2016-08-19 00:17:00 +08:00
|
|
|
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 02:10:43 +08:00
|
|
|
if (IS_GEN(fence->i915, 2))
|
2016-08-19 00:17:00 +08:00
|
|
|
i830_write_fence_reg(fence, vma);
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 02:10:43 +08:00
|
|
|
else if (IS_GEN(fence->i915, 3))
|
2016-08-19 00:17:00 +08:00
|
|
|
i915_write_fence_reg(fence, vma);
|
|
|
|
else
|
|
|
|
i965_write_fence_reg(fence, vma);
|
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* Access through the fenced region afterwards is
|
2016-08-19 00:17:00 +08:00
|
|
|
* ordered by the posting reads whilst writing the registers.
|
2015-07-24 19:55:11 +08:00
|
|
|
*/
|
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
fence->dirty = false;
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
static int fence_update(struct i915_fence_reg *fence,
|
2016-08-19 00:17:00 +08:00
|
|
|
struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
2019-01-14 22:21:18 +08:00
|
|
|
intel_wakeref_t wakeref;
|
2019-02-08 23:37:02 +08:00
|
|
|
struct i915_vma *old;
|
2016-08-19 00:17:00 +08:00
|
|
|
int ret;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
if (vma) {
|
|
|
|
if (!i915_vma_is_map_and_fenceable(vma))
|
|
|
|
return -EINVAL;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
if (WARN(!i915_gem_object_get_stride(vma->obj) ||
|
|
|
|
!i915_gem_object_get_tiling(vma->obj),
|
|
|
|
"bogus fence setup with stride: 0x%x, tiling mode: %i\n",
|
|
|
|
i915_gem_object_get_stride(vma->obj),
|
|
|
|
i915_gem_object_get_tiling(vma->obj)))
|
|
|
|
return -EINVAL;
|
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
ret = i915_vma_sync(vma);
|
2016-08-19 00:17:00 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2019-02-08 23:37:02 +08:00
|
|
|
old = xchg(&fence->vma, NULL);
|
|
|
|
if (old) {
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
/* XXX Ideally we would move the waiting to outside the mutex */
|
|
|
|
ret = i915_vma_sync(old);
|
2019-02-08 23:37:02 +08:00
|
|
|
if (ret) {
|
|
|
|
fence->vma = old;
|
2016-08-19 00:17:00 +08:00
|
|
|
return ret;
|
2019-02-08 23:37:02 +08:00
|
|
|
}
|
2018-01-31 00:44:57 +08:00
|
|
|
|
|
|
|
i915_vma_flush_writes(old);
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2019-02-08 23:37:02 +08:00
|
|
|
/*
|
|
|
|
* Ensure that all userspace CPU access is completed before
|
2016-08-19 00:17:00 +08:00
|
|
|
* stealing the fence.
|
|
|
|
*/
|
2019-02-08 23:37:02 +08:00
|
|
|
if (old != vma) {
|
|
|
|
GEM_BUG_ON(old->fence != fence);
|
|
|
|
i915_vma_revoke_mmap(old);
|
|
|
|
old->fence = NULL;
|
|
|
|
}
|
2016-08-19 00:17:00 +08:00
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
list_move(&fence->link, &fence->i915->ggtt.fence_list);
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
|
|
|
|
2019-02-08 23:37:02 +08:00
|
|
|
/*
|
|
|
|
* We only need to update the register itself if the device is awake.
|
2017-03-06 17:29:16 +08:00
|
|
|
* If the device is currently powered down, we will defer the write
|
|
|
|
* to the runtime resume, see i915_gem_restore_fences().
|
2019-02-08 23:37:02 +08:00
|
|
|
*
|
|
|
|
* This only works for removing the fence register, on acquisition
|
|
|
|
* the caller must hold the rpm wakeref. The fence register must
|
|
|
|
* be cleared before we can use any other fences to ensure that
|
|
|
|
* the new fences do not overlap the elided clears, confusing HW.
|
2017-03-06 17:29:16 +08:00
|
|
|
*/
|
2019-06-14 07:21:54 +08:00
|
|
|
wakeref = intel_runtime_pm_get_if_in_use(&fence->i915->runtime_pm);
|
2019-02-08 23:37:02 +08:00
|
|
|
if (!wakeref) {
|
|
|
|
GEM_BUG_ON(vma);
|
|
|
|
return 0;
|
2017-03-06 17:29:16 +08:00
|
|
|
}
|
2016-08-19 00:17:00 +08:00
|
|
|
|
drm/i915: Avoid reset lock in writing fence registers
The idea of taking the reset lock around writing the fence register was
to serialise the mmio write we also perform during the reset where those
registers get clobbered. However, the lock is overkill as write tearing
between reset and fence_update() is harmless; the final value of the
fence register is the same. A race between revoke_fences() and
fence_update() is also harmless at this point as on the fault path where
this is necessary, we acquire the reset lock to coordinate ourselves in
the upper layer.
The danger of acquiring the reset lock again in fence_update() is that
we may recurse from the shrinker along the i915_gem_fault() path.
<4> [125.739646] ============================================
<4> [125.739652] WARNING: possible recursive locking detected
<4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U
<4> [125.739666] --------------------------------------------
<4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock:
<4> [125.739679] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x0/0x310 [i915]
<4> [125.739848]
but task is already holding lock:
<4> [125.739854] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915]
<4> [125.739918]
other info that might help us debug this:
<4> [125.739925] Possible unsafe locking scenario:
<4> [125.739930] CPU0
<4> [125.739934] ----
<4> [125.739937] lock(&dev_priv->gpu_error.reset_backoff_srcu);
<4> [125.739944] lock(&dev_priv->gpu_error.reset_backoff_srcu);
<4> [125.739950]
*** DEADLOCK ***
<4> [125.739958] May be due to missing lock nesting notation
<4> [125.739966] 5 locks held by gem_mmap_gtt/1017:
<4> [125.739972] #0: 00000000471f682c (&mm->mmap_sem){++++}, at: __do_page_fault+0x133/0x500
<4> [125.739987] #1: 0000000026542685 (&dev->struct_mutex){+.+.}, at: i915_gem_fault+0x1f6/0x860 [i915]
<4> [125.740061] #2: 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915]
<4> [125.740126] #3: 00000000c828eb4f (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.25+0x0/0x30
<4> [125.740140] #4: 000000002d360d65 (shrinker_rwsem){++++}, at: shrink_slab+0x1cb/0x2c0
<4> [125.740151]
stack backtrace:
<4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1
<4> [125.740170] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007
<4> [125.740180] Call Trace:
<4> [125.740189] dump_stack+0x67/0x9b
<4> [125.740199] __lock_acquire+0xc75/0x1b00
<4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0
<4> [125.740216] ? tlb_finish_mmu+0x1a/0x30
<4> [125.740222] ? zap_page_range_single+0xe2/0x130
<4> [125.740230] ? lock_acquire+0xa6/0x1c0
<4> [125.740237] lock_acquire+0xa6/0x1c0
<4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740357] i915_reset_trylock+0x44/0x310 [i915]
<4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0
<4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60
<4> [125.740499] fence_update+0x218/0x470 [i915]
<4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915]
<4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915]
<4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915]
<4> [125.740722] ? ___preempt_schedule+0x16/0x18
<4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740870] do_shrink_slab+0x143/0x3f0
<4> [125.740878] shrink_slab+0x228/0x2c0
<4> [125.740886] shrink_node+0x167/0x450
<4> [125.740894] do_try_to_free_pages+0xc4/0x340
<4> [125.740902] try_to_free_pages+0xdc/0x2e0
<4> [125.740911] __alloc_pages_nodemask+0x662/0x1110
<4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915]
<4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915]
<4> [125.741054] pte_alloc_one+0x12/0x70
<4> [125.741060] __pte_alloc+0x11/0xf0
<4> [125.741067] apply_to_page_range+0x37e/0x440
<4> [125.741127] remap_io_mapping+0x6c/0x100 [i915]
<4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915]
<4> [125.741204] ? ptlock_alloc+0x15/0x30
<4> [125.741212] __do_fault+0x2c/0xb0
<4> [125.741218] __handle_mm_fault+0x8ee/0xfa0
<4> [125.741227] handle_mm_fault+0x196/0x3a0
<4> [125.741235] __do_page_fault+0x246/0x500
<4> [125.741243] ? page_fault+0x8/0x30
<4> [125.741250] page_fault+0x1e/0x30
<4> [125.741256] RIP: 0033:0x55d0cc456e12
<4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83 85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48
<4> [125.741280] RSP: 002b:00007ffc1bab7ab0 EFLAGS: 00010206
<4> [125.741287] RAX: 00007fc787cb6000 RBX: 0000000000000000 RCX: 0000000000000000
<4> [125.741295] RDX: 00000000ffffffff RSI: 0000000000005401 RDI: 0000000000000002
<4> [125.741303] RBP: 00007ffc1bab9b70 R08: 00007ffc1bab7920 R09: 000000000000001b
<4> [125.741310] R10: 7165722074736554 R11: 0000000000000246 R12: 000055d0cc454a80
<4> [125.741318] R13: 00007ffc1bab9f60 R14: 0000000000000000 R15: 0000000000000000
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109665
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-4-chris@chris-wilson.co.uk
2019-02-19 20:21:54 +08:00
|
|
|
WRITE_ONCE(fence->vma, vma);
|
2019-02-08 23:37:02 +08:00
|
|
|
fence_write(fence, vma);
|
2016-08-19 00:17:00 +08:00
|
|
|
|
2019-02-08 23:37:02 +08:00
|
|
|
if (vma) {
|
|
|
|
vma->fence = fence;
|
2019-06-13 15:32:54 +08:00
|
|
|
list_move_tail(&fence->link, &fence->i915->ggtt.fence_list);
|
2016-08-19 00:17:00 +08:00
|
|
|
}
|
|
|
|
|
2019-06-14 07:21:54 +08:00
|
|
|
intel_runtime_pm_put(&fence->i915->runtime_pm, wakeref);
|
drm/i915: Avoid reset lock in writing fence registers
The idea of taking the reset lock around writing the fence register was
to serialise the mmio write we also perform during the reset where those
registers get clobbered. However, the lock is overkill as write tearing
between reset and fence_update() is harmless; the final value of the
fence register is the same. A race between revoke_fences() and
fence_update() is also harmless at this point as on the fault path where
this is necessary, we acquire the reset lock to coordinate ourselves in
the upper layer.
The danger of acquiring the reset lock again in fence_update() is that
we may recurse from the shrinker along the i915_gem_fault() path.
<4> [125.739646] ============================================
<4> [125.739652] WARNING: possible recursive locking detected
<4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U
<4> [125.739666] --------------------------------------------
<4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock:
<4> [125.739679] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x0/0x310 [i915]
<4> [125.739848]
but task is already holding lock:
<4> [125.739854] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915]
<4> [125.739918]
other info that might help us debug this:
<4> [125.739925] Possible unsafe locking scenario:
<4> [125.739930] CPU0
<4> [125.739934] ----
<4> [125.739937] lock(&dev_priv->gpu_error.reset_backoff_srcu);
<4> [125.739944] lock(&dev_priv->gpu_error.reset_backoff_srcu);
<4> [125.739950]
*** DEADLOCK ***
<4> [125.739958] May be due to missing lock nesting notation
<4> [125.739966] 5 locks held by gem_mmap_gtt/1017:
<4> [125.739972] #0: 00000000471f682c (&mm->mmap_sem){++++}, at: __do_page_fault+0x133/0x500
<4> [125.739987] #1: 0000000026542685 (&dev->struct_mutex){+.+.}, at: i915_gem_fault+0x1f6/0x860 [i915]
<4> [125.740061] #2: 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915]
<4> [125.740126] #3: 00000000c828eb4f (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.25+0x0/0x30
<4> [125.740140] #4: 000000002d360d65 (shrinker_rwsem){++++}, at: shrink_slab+0x1cb/0x2c0
<4> [125.740151]
stack backtrace:
<4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1
<4> [125.740170] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007
<4> [125.740180] Call Trace:
<4> [125.740189] dump_stack+0x67/0x9b
<4> [125.740199] __lock_acquire+0xc75/0x1b00
<4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0
<4> [125.740216] ? tlb_finish_mmu+0x1a/0x30
<4> [125.740222] ? zap_page_range_single+0xe2/0x130
<4> [125.740230] ? lock_acquire+0xa6/0x1c0
<4> [125.740237] lock_acquire+0xa6/0x1c0
<4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740357] i915_reset_trylock+0x44/0x310 [i915]
<4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0
<4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60
<4> [125.740499] fence_update+0x218/0x470 [i915]
<4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915]
<4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915]
<4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915]
<4> [125.740722] ? ___preempt_schedule+0x16/0x18
<4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740870] do_shrink_slab+0x143/0x3f0
<4> [125.740878] shrink_slab+0x228/0x2c0
<4> [125.740886] shrink_node+0x167/0x450
<4> [125.740894] do_try_to_free_pages+0xc4/0x340
<4> [125.740902] try_to_free_pages+0xdc/0x2e0
<4> [125.740911] __alloc_pages_nodemask+0x662/0x1110
<4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915]
<4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915]
<4> [125.741054] pte_alloc_one+0x12/0x70
<4> [125.741060] __pte_alloc+0x11/0xf0
<4> [125.741067] apply_to_page_range+0x37e/0x440
<4> [125.741127] remap_io_mapping+0x6c/0x100 [i915]
<4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915]
<4> [125.741204] ? ptlock_alloc+0x15/0x30
<4> [125.741212] __do_fault+0x2c/0xb0
<4> [125.741218] __handle_mm_fault+0x8ee/0xfa0
<4> [125.741227] handle_mm_fault+0x196/0x3a0
<4> [125.741235] __do_page_fault+0x246/0x500
<4> [125.741243] ? page_fault+0x8/0x30
<4> [125.741250] page_fault+0x1e/0x30
<4> [125.741256] RIP: 0033:0x55d0cc456e12
<4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83 85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48
<4> [125.741280] RSP: 002b:00007ffc1bab7ab0 EFLAGS: 00010206
<4> [125.741287] RAX: 00007fc787cb6000 RBX: 0000000000000000 RCX: 0000000000000000
<4> [125.741295] RDX: 00000000ffffffff RSI: 0000000000005401 RDI: 0000000000000002
<4> [125.741303] RBP: 00007ffc1bab9b70 R08: 00007ffc1bab7920 R09: 000000000000001b
<4> [125.741310] R10: 7165722074736554 R11: 0000000000000246 R12: 000055d0cc454a80
<4> [125.741318] R13: 00007ffc1bab9f60 R14: 0000000000000000 R15: 0000000000000000
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109665
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-4-chris@chris-wilson.co.uk
2019-02-19 20:21:54 +08:00
|
|
|
return 0;
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2015-07-24 23:40:12 +08:00
|
|
|
/**
|
2019-08-22 14:15:57 +08:00
|
|
|
* i915_vma_revoke_fence - force-remove fence for a VMA
|
2016-08-19 00:17:00 +08:00
|
|
|
* @vma: vma to map linearly (not through a fence reg)
|
2015-07-24 23:40:12 +08:00
|
|
|
*
|
|
|
|
* This function force-removes any fence from the given object, which is useful
|
|
|
|
* if the kernel wants to do untiled GTT access.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success, negative error code on failure.
|
|
|
|
*/
|
2019-08-22 14:15:57 +08:00
|
|
|
int i915_vma_revoke_fence(struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
2019-06-13 15:32:54 +08:00
|
|
|
struct i915_fence_reg *fence = vma->fence;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2019-08-22 14:15:57 +08:00
|
|
|
lockdep_assert_held(&vma->vm->mutex);
|
2016-08-19 00:17:00 +08:00
|
|
|
if (!fence)
|
2015-07-24 19:55:11 +08:00
|
|
|
return 0;
|
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
if (atomic_read(&fence->pin_count))
|
2015-07-24 19:55:11 +08:00
|
|
|
return -EBUSY;
|
|
|
|
|
2019-08-22 14:15:57 +08:00
|
|
|
return fence_update(fence, NULL);
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
static struct i915_fence_reg *fence_find(struct drm_i915_private *i915)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
2019-06-13 15:32:54 +08:00
|
|
|
struct i915_fence_reg *fence;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2019-06-13 15:32:54 +08:00
|
|
|
list_for_each_entry(fence, &i915->ggtt.fence_list, link) {
|
2017-10-09 16:43:56 +08:00
|
|
|
GEM_BUG_ON(fence->vma && fence->vma->fence != fence);
|
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
if (atomic_read(&fence->pin_count))
|
2015-07-24 19:55:11 +08:00
|
|
|
continue;
|
|
|
|
|
2016-08-19 00:17:00 +08:00
|
|
|
return fence;
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Wait for completion of pending flips which consume fences */
|
2019-06-04 20:00:21 +08:00
|
|
|
if (intel_has_pending_fb_unpin(i915))
|
2015-07-24 19:55:11 +08:00
|
|
|
return ERR_PTR(-EAGAIN);
|
|
|
|
|
|
|
|
return ERR_PTR(-EDEADLK);
|
|
|
|
}
|
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
int __i915_vma_pin_fence(struct i915_vma *vma)
|
2019-08-22 14:09:12 +08:00
|
|
|
{
|
|
|
|
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
|
|
|
|
struct i915_fence_reg *fence;
|
|
|
|
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
|
|
|
|
int err;
|
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
lockdep_assert_held(&vma->vm->mutex);
|
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
/* Just update our place in the LRU if our fence is getting reused. */
|
|
|
|
if (vma->fence) {
|
|
|
|
fence = vma->fence;
|
|
|
|
GEM_BUG_ON(fence->vma != vma);
|
|
|
|
atomic_inc(&fence->pin_count);
|
|
|
|
if (!fence->dirty) {
|
|
|
|
list_move_tail(&fence->link, &ggtt->fence_list);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
} else if (set) {
|
|
|
|
fence = fence_find(vma->vm->i915);
|
|
|
|
if (IS_ERR(fence))
|
|
|
|
return PTR_ERR(fence);
|
|
|
|
|
|
|
|
GEM_BUG_ON(atomic_read(&fence->pin_count));
|
|
|
|
atomic_inc(&fence->pin_count);
|
|
|
|
} else {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = fence_update(fence, set);
|
|
|
|
if (err)
|
|
|
|
goto out_unpin;
|
|
|
|
|
|
|
|
GEM_BUG_ON(fence->vma != set);
|
|
|
|
GEM_BUG_ON(vma->fence != (set ? fence : NULL));
|
|
|
|
|
|
|
|
if (set)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_unpin:
|
|
|
|
atomic_dec(&fence->pin_count);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2015-07-24 19:55:11 +08:00
|
|
|
/**
|
2017-10-09 16:43:56 +08:00
|
|
|
* i915_vma_pin_fence - set up fencing for a vma
|
2016-08-19 00:17:00 +08:00
|
|
|
* @vma: vma to map through a fence reg
|
2015-07-24 19:55:11 +08:00
|
|
|
*
|
|
|
|
* When mapping objects through the GTT, userspace wants to be able to write
|
|
|
|
* to them without having to worry about swizzling if the object is tiled.
|
|
|
|
* This function walks the fence regs looking for a free one for @obj,
|
|
|
|
* stealing one if it can't find any.
|
|
|
|
*
|
|
|
|
* It then sets up the reg based on the object's properties: address, pitch
|
|
|
|
* and tiling format.
|
|
|
|
*
|
|
|
|
* For an untiled surface, this removes any existing fence.
|
2015-07-24 23:40:12 +08:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success, negative error code on failure.
|
2015-07-24 19:55:11 +08:00
|
|
|
*/
|
2019-06-13 15:32:54 +08:00
|
|
|
int i915_vma_pin_fence(struct i915_vma *vma)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
2017-10-09 16:43:56 +08:00
|
|
|
int err;
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* Note that we revoke fences on runtime suspend. Therefore the user
|
2016-10-24 20:42:18 +08:00
|
|
|
* must keep the device awake whilst using the fence.
|
|
|
|
*/
|
2019-06-14 07:21:50 +08:00
|
|
|
assert_rpm_wakelock_held(&vma->vm->i915->runtime_pm);
|
2019-08-22 14:09:12 +08:00
|
|
|
GEM_BUG_ON(!i915_vma_is_pinned(vma));
|
|
|
|
GEM_BUG_ON(!i915_vma_is_ggtt(vma));
|
2016-10-12 19:48:26 +08:00
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
err = mutex_lock_interruptible(&vma->vm->mutex);
|
2017-10-09 16:43:56 +08:00
|
|
|
if (err)
|
2019-08-22 14:09:12 +08:00
|
|
|
return err;
|
2017-10-09 16:43:56 +08:00
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
err = __i915_vma_pin_fence(vma);
|
|
|
|
mutex_unlock(&vma->vm->mutex);
|
2017-10-09 16:43:56 +08:00
|
|
|
|
|
|
|
return err;
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
|
|
|
|
2017-09-04 16:01:01 +08:00
|
|
|
/**
|
|
|
|
* i915_reserve_fence - Reserve a fence for vGPU
|
2019-06-04 20:00:21 +08:00
|
|
|
* @i915: i915 device private
|
2017-09-04 16:01:01 +08:00
|
|
|
*
|
|
|
|
* This function walks the fence regs looking for a free one and remove
|
|
|
|
* it from the fence_list. It is used to reserve fence for vGPU to use.
|
|
|
|
*/
|
2019-06-13 15:32:54 +08:00
|
|
|
struct i915_fence_reg *i915_reserve_fence(struct drm_i915_private *i915)
|
2017-09-04 16:01:01 +08:00
|
|
|
{
|
2019-08-22 14:09:12 +08:00
|
|
|
struct i915_ggtt *ggtt = &i915->ggtt;
|
2019-06-13 15:32:54 +08:00
|
|
|
struct i915_fence_reg *fence;
|
2017-09-04 16:01:01 +08:00
|
|
|
int count;
|
|
|
|
int ret;
|
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
lockdep_assert_held(&ggtt->vm.mutex);
|
2017-09-04 16:01:01 +08:00
|
|
|
|
|
|
|
/* Keep at least one fence available for the display engine. */
|
|
|
|
count = 0;
|
2019-08-22 14:09:12 +08:00
|
|
|
list_for_each_entry(fence, &ggtt->fence_list, link)
|
|
|
|
count += !atomic_read(&fence->pin_count);
|
2017-09-04 16:01:01 +08:00
|
|
|
if (count <= 1)
|
|
|
|
return ERR_PTR(-ENOSPC);
|
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
fence = fence_find(i915);
|
2017-09-04 16:01:01 +08:00
|
|
|
if (IS_ERR(fence))
|
|
|
|
return fence;
|
|
|
|
|
|
|
|
if (fence->vma) {
|
|
|
|
/* Force-remove fence from VMA */
|
|
|
|
ret = fence_update(fence, NULL);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
list_del(&fence->link);
|
2019-08-22 14:09:12 +08:00
|
|
|
|
2017-09-04 16:01:01 +08:00
|
|
|
return fence;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* i915_unreserve_fence - Reclaim a reserved fence
|
|
|
|
* @fence: the fence reg
|
|
|
|
*
|
|
|
|
* This function add a reserved fence register from vGPU to the fence_list.
|
|
|
|
*/
|
2019-06-13 15:32:54 +08:00
|
|
|
void i915_unreserve_fence(struct i915_fence_reg *fence)
|
2017-09-04 16:01:01 +08:00
|
|
|
{
|
2019-08-22 14:09:12 +08:00
|
|
|
struct i915_ggtt *ggtt = &fence->i915->ggtt;
|
|
|
|
|
|
|
|
lockdep_assert_held(&ggtt->vm.mutex);
|
2017-09-04 16:01:01 +08:00
|
|
|
|
2019-08-22 14:09:12 +08:00
|
|
|
list_add(&fence->link, &ggtt->fence_list);
|
2017-09-04 16:01:01 +08:00
|
|
|
}
|
|
|
|
|
2015-07-24 23:40:12 +08:00
|
|
|
/**
|
|
|
|
* i915_gem_restore_fences - restore fence state
|
2019-06-04 20:00:21 +08:00
|
|
|
* @i915: i915 device private
|
2015-07-24 23:40:12 +08:00
|
|
|
*
|
|
|
|
* Restore the hw fence state to match the software tracking again, to be called
|
2016-10-24 20:42:18 +08:00
|
|
|
* after a gpu reset and on resume. Note that on runtime suspend we only cancel
|
|
|
|
* the fences, to be reacquired by the user later.
|
2015-07-24 23:40:12 +08:00
|
|
|
*/
|
2019-06-04 20:00:21 +08:00
|
|
|
void i915_gem_restore_fences(struct drm_i915_private *i915)
|
2015-07-24 19:55:11 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2019-02-08 23:37:02 +08:00
|
|
|
rcu_read_lock(); /* keep obj alive as we dereference */
|
2019-06-13 15:32:54 +08:00
|
|
|
for (i = 0; i < i915->ggtt.num_fences; i++) {
|
|
|
|
struct i915_fence_reg *reg = &i915->ggtt.fence_regs[i];
|
2019-02-08 23:37:02 +08:00
|
|
|
struct i915_vma *vma = READ_ONCE(reg->vma);
|
2015-07-24 19:55:11 +08:00
|
|
|
|
2017-10-09 16:43:56 +08:00
|
|
|
GEM_BUG_ON(vma && vma->fence != reg);
|
|
|
|
|
2015-07-24 19:55:11 +08:00
|
|
|
/*
|
|
|
|
* Commit delayed tiling changes if we have an object still
|
|
|
|
* attached to the fence, otherwise just clear the fence.
|
|
|
|
*/
|
2019-02-08 23:37:02 +08:00
|
|
|
if (vma && !i915_gem_object_is_tiled(vma->obj))
|
2016-08-19 23:54:23 +08:00
|
|
|
vma = NULL;
|
|
|
|
|
2016-10-12 19:48:26 +08:00
|
|
|
fence_write(reg, vma);
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
2019-02-08 23:37:02 +08:00
|
|
|
rcu_read_unlock();
|
2015-07-24 19:55:11 +08:00
|
|
|
}
|
2015-07-24 23:40:14 +08:00
|
|
|
|
|
|
|
/**
|
2015-07-24 23:40:15 +08:00
|
|
|
* DOC: tiling swizzling details
|
2015-07-24 23:40:14 +08:00
|
|
|
*
|
|
|
|
* The idea behind tiling is to increase cache hit rates by rearranging
|
|
|
|
* pixel data so that a group of pixel accesses are in the same cacheline.
|
|
|
|
* Performance improvement from doing this on the back/depth buffer are on
|
|
|
|
* the order of 30%.
|
|
|
|
*
|
|
|
|
* Intel architectures make this somewhat more complicated, though, by
|
|
|
|
* adjustments made to addressing of data when the memory is in interleaved
|
|
|
|
* mode (matched pairs of DIMMS) to improve memory bandwidth.
|
|
|
|
* For interleaved memory, the CPU sends every sequential 64 bytes
|
|
|
|
* to an alternate memory channel so it can get the bandwidth from both.
|
|
|
|
*
|
|
|
|
* The GPU also rearranges its accesses for increased bandwidth to interleaved
|
|
|
|
* memory, and it matches what the CPU does for non-tiled. However, when tiled
|
|
|
|
* it does it a little differently, since one walks addresses not just in the
|
|
|
|
* X direction but also Y. So, along with alternating channels when bit
|
|
|
|
* 6 of the address flips, it also alternates when other bits flip -- Bits 9
|
|
|
|
* (every 512 bytes, an X tile scanline) and 10 (every two X tile scanlines)
|
|
|
|
* are common to both the 915 and 965-class hardware.
|
|
|
|
*
|
|
|
|
* The CPU also sometimes XORs in higher bits as well, to improve
|
|
|
|
* bandwidth doing strided access like we do so frequently in graphics. This
|
|
|
|
* is called "Channel XOR Randomization" in the MCH documentation. The result
|
|
|
|
* is that the CPU is XORing in either bit 11 or bit 17 to bit 6 of its address
|
|
|
|
* decode.
|
|
|
|
*
|
|
|
|
* All of this bit 6 XORing has an effect on our memory management,
|
|
|
|
* as we need to make sure that the 3d driver can correctly address object
|
|
|
|
* contents.
|
|
|
|
*
|
|
|
|
* If we don't have interleaved memory, all tiling is safe and no swizzling is
|
|
|
|
* required.
|
|
|
|
*
|
|
|
|
* When bit 17 is XORed in, we simply refuse to tile at all. Bit
|
2016-01-05 11:29:17 +08:00
|
|
|
* 17 is not just a page offset, so as we page an object out and back in,
|
2015-07-24 23:40:14 +08:00
|
|
|
* individual pages in it will have different bit 17 addresses, resulting in
|
|
|
|
* each 64 bytes being swapped with its neighbor!
|
|
|
|
*
|
|
|
|
* Otherwise, if interleaved, we have to tell the 3d driver what the address
|
|
|
|
* swizzling it needs to do is, since it's writing with the CPU to the pages
|
|
|
|
* (bit 6 and potentially bit 11 XORed in), and the GPU is reading from the
|
|
|
|
* pages (bit 6, 9, and 10 XORed in), resulting in a cumulative bit swizzling
|
|
|
|
* required by the CPU of XORing in bit 6, 9, 10, and potentially 11, in order
|
|
|
|
* to match what the GPU expects.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2015-07-24 23:40:15 +08:00
|
|
|
* i915_gem_detect_bit_6_swizzle - detect bit 6 swizzling pattern
|
2019-06-04 20:00:21 +08:00
|
|
|
* @i915: i915 device private
|
2015-07-24 23:40:15 +08:00
|
|
|
*
|
2015-07-24 23:40:14 +08:00
|
|
|
* Detects bit 6 swizzling of address lookup between IGD access and CPU
|
|
|
|
* access through main memory.
|
|
|
|
*/
|
2019-06-13 15:32:54 +08:00
|
|
|
static void detect_bit_6_swizzle(struct drm_i915_private *i915)
|
2015-07-24 23:40:14 +08:00
|
|
|
{
|
2019-06-04 20:00:21 +08:00
|
|
|
struct intel_uncore *uncore = &i915->uncore;
|
2019-01-16 17:15:19 +08:00
|
|
|
u32 swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
|
|
|
|
u32 swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
|
2015-07-24 23:40:14 +08:00
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
if (INTEL_GEN(i915) >= 8 || IS_VALLEYVIEW(i915)) {
|
2015-07-24 23:40:14 +08:00
|
|
|
/*
|
|
|
|
* On BDW+, swizzling is not used. We leave the CPU memory
|
|
|
|
* controller in charge of optimizing memory accesses without
|
|
|
|
* the extra address manipulation GPU side.
|
|
|
|
*
|
|
|
|
* VLV and CHV don't have GPU swizzling.
|
|
|
|
*/
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
|
2019-06-04 20:00:21 +08:00
|
|
|
} else if (INTEL_GEN(i915) >= 6) {
|
|
|
|
if (i915->preserve_bios_swizzle) {
|
|
|
|
if (intel_uncore_read(uncore, DISP_ARB_CTL) &
|
2015-07-24 23:40:14 +08:00
|
|
|
DISP_TILE_SURFACE_SWIZZLING) {
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9;
|
|
|
|
} else {
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
}
|
|
|
|
} else {
|
2019-01-16 17:15:19 +08:00
|
|
|
u32 dimm_c0, dimm_c1;
|
2019-06-04 20:00:21 +08:00
|
|
|
dimm_c0 = intel_uncore_read(uncore, MAD_DIMM_C0);
|
|
|
|
dimm_c1 = intel_uncore_read(uncore, MAD_DIMM_C1);
|
2015-07-24 23:40:14 +08:00
|
|
|
dimm_c0 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
|
|
|
|
dimm_c1 &= MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* Enable swizzling when the channels are populated
|
2015-07-24 23:40:14 +08:00
|
|
|
* with identically sized dimms. We don't need to check
|
|
|
|
* the 3rd channel because no cpu with gpu attached
|
|
|
|
* ships in that configuration. Also, swizzling only
|
2019-06-04 20:00:21 +08:00
|
|
|
* makes sense for 2 channels anyway.
|
|
|
|
*/
|
2015-07-24 23:40:14 +08:00
|
|
|
if (dimm_c0 == dimm_c1) {
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9;
|
|
|
|
} else {
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
}
|
|
|
|
}
|
2019-06-04 20:00:21 +08:00
|
|
|
} else if (IS_GEN(i915, 5)) {
|
|
|
|
/*
|
|
|
|
* On Ironlake whatever DRAM config, GPU always do
|
2015-07-24 23:40:14 +08:00
|
|
|
* same swizzling setup.
|
|
|
|
*/
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9;
|
2019-06-04 20:00:21 +08:00
|
|
|
} else if (IS_GEN(i915, 2)) {
|
|
|
|
/*
|
|
|
|
* As far as we know, the 865 doesn't have these bit 6
|
2015-07-24 23:40:14 +08:00
|
|
|
* swizzling issues.
|
|
|
|
*/
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
|
2019-06-04 20:00:21 +08:00
|
|
|
} else if (IS_G45(i915) || IS_I965G(i915) || IS_G33(i915)) {
|
|
|
|
/*
|
|
|
|
* The 965, G33, and newer, have a very flexible memory
|
2019-03-19 00:56:28 +08:00
|
|
|
* configuration. It will enable dual-channel mode
|
|
|
|
* (interleaving) on as much memory as it can, and the GPU
|
|
|
|
* will additionally sometimes enable different bit 6
|
|
|
|
* swizzling for tiled objects from the CPU.
|
|
|
|
*
|
|
|
|
* Here's what I found on the G965:
|
|
|
|
* slot fill memory size swizzling
|
|
|
|
* 0A 0B 1A 1B 1-ch 2-ch
|
|
|
|
* 512 0 0 0 512 0 O
|
|
|
|
* 512 0 512 0 16 1008 X
|
|
|
|
* 512 0 0 512 16 1008 X
|
|
|
|
* 0 512 0 512 16 1008 X
|
|
|
|
* 1024 1024 1024 0 2048 1024 O
|
|
|
|
*
|
|
|
|
* We could probably detect this based on either the DRB
|
|
|
|
* matching, which was the case for the swizzling required in
|
|
|
|
* the table above, or from the 1-ch value being less than
|
|
|
|
* the minimum size of a rank.
|
|
|
|
*
|
|
|
|
* Reports indicate that the swizzling actually
|
|
|
|
* varies depending upon page placement inside the
|
|
|
|
* channels, i.e. we see swizzled pages where the
|
|
|
|
* banks of memory are paired and unswizzled on the
|
|
|
|
* uneven portion, so leave that as unknown.
|
|
|
|
*/
|
2019-06-04 20:00:21 +08:00
|
|
|
if (intel_uncore_read(uncore, C0DRB3) ==
|
|
|
|
intel_uncore_read(uncore, C1DRB3)) {
|
2019-03-19 00:56:28 +08:00
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9;
|
|
|
|
}
|
|
|
|
} else {
|
2019-06-04 20:00:21 +08:00
|
|
|
u32 dcc = intel_uncore_read(uncore, DCC);
|
2015-07-24 23:40:14 +08:00
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* On 9xx chipsets, channel interleave by the CPU is
|
2015-07-24 23:40:14 +08:00
|
|
|
* determined by DCC. For single-channel, neither the CPU
|
|
|
|
* nor the GPU do swizzling. For dual channel interleaved,
|
|
|
|
* the GPU's interleave is bit 9 and 10 for X tiled, and bit
|
|
|
|
* 9 for Y tiled. The CPU's interleave is independent, and
|
|
|
|
* can be based on either bit 11 (haven't seen this yet) or
|
|
|
|
* bit 17 (common).
|
|
|
|
*/
|
|
|
|
switch (dcc & DCC_ADDRESSING_MODE_MASK) {
|
|
|
|
case DCC_ADDRESSING_MODE_SINGLE_CHANNEL:
|
|
|
|
case DCC_ADDRESSING_MODE_DUAL_CHANNEL_ASYMMETRIC:
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
break;
|
|
|
|
case DCC_ADDRESSING_MODE_DUAL_CHANNEL_INTERLEAVED:
|
|
|
|
if (dcc & DCC_CHANNEL_XOR_DISABLE) {
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* This is the base swizzling by the GPU for
|
2015-07-24 23:40:14 +08:00
|
|
|
* tiled buffers.
|
|
|
|
*/
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9;
|
|
|
|
} else if ((dcc & DCC_CHANNEL_XOR_BIT_17) == 0) {
|
|
|
|
/* Bit 11 swizzling by the CPU in addition. */
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10_11;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9_11;
|
|
|
|
} else {
|
|
|
|
/* Bit 17 swizzling by the CPU in addition. */
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_9_10_17;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_9_17;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* check for L-shaped memory aka modified enhanced addressing */
|
2019-06-04 20:00:21 +08:00
|
|
|
if (IS_GEN(i915, 4) &&
|
|
|
|
!(intel_uncore_read(uncore, DCC2) & DCC2_MODIFIED_ENHANCED_DISABLE)) {
|
2015-11-19 17:58:05 +08:00
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
|
2015-07-24 23:40:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (dcc == 0xffffffff) {
|
|
|
|
DRM_ERROR("Couldn't read from MCHBAR. "
|
|
|
|
"Disabling tiling.\n");
|
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-11-19 17:58:05 +08:00
|
|
|
if (swizzle_x == I915_BIT_6_SWIZZLE_UNKNOWN ||
|
|
|
|
swizzle_y == I915_BIT_6_SWIZZLE_UNKNOWN) {
|
2019-06-04 20:00:21 +08:00
|
|
|
/*
|
|
|
|
* Userspace likes to explode if it sees unknown swizzling,
|
2015-11-19 17:58:05 +08:00
|
|
|
* so lie. We will finish the lie when reporting through
|
|
|
|
* the get-tiling-ioctl by reporting the physical swizzle
|
|
|
|
* mode as unknown instead.
|
|
|
|
*
|
|
|
|
* As we don't strictly know what the swizzling is, it may be
|
|
|
|
* bit17 dependent, and so we need to also prevent the pages
|
|
|
|
* from being moved.
|
|
|
|
*/
|
2019-06-04 20:00:21 +08:00
|
|
|
i915->quirks |= QUIRK_PIN_SWIZZLED_PAGES;
|
2015-11-19 17:58:05 +08:00
|
|
|
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
|
|
|
|
}
|
|
|
|
|
2019-06-04 20:00:21 +08:00
|
|
|
i915->mm.bit_6_swizzle_x = swizzle_x;
|
|
|
|
i915->mm.bit_6_swizzle_y = swizzle_y;
|
2015-07-24 23:40:14 +08:00
|
|
|
}
|
|
|
|
|
2015-07-24 23:40:15 +08:00
|
|
|
/*
|
2015-07-24 23:40:14 +08:00
|
|
|
* Swap every 64 bytes of this page around, to account for it having a new
|
|
|
|
* bit 17 of its physical address and therefore being interpreted differently
|
|
|
|
* by the GPU.
|
|
|
|
*/
|
2019-06-13 15:32:54 +08:00
|
|
|
static void i915_gem_swizzle_page(struct page *page)
|
2015-07-24 23:40:14 +08:00
|
|
|
{
|
|
|
|
char temp[64];
|
|
|
|
char *vaddr;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
vaddr = kmap(page);
|
|
|
|
|
|
|
|
for (i = 0; i < PAGE_SIZE; i += 128) {
|
|
|
|
memcpy(temp, &vaddr[i], 64);
|
|
|
|
memcpy(&vaddr[i], &vaddr[i + 64], 64);
|
|
|
|
memcpy(&vaddr[i + 64], temp, 64);
|
|
|
|
}
|
|
|
|
|
|
|
|
kunmap(page);
|
|
|
|
}
|
|
|
|
|
2015-07-24 23:40:15 +08:00
|
|
|
/**
|
|
|
|
* i915_gem_object_do_bit_17_swizzle - fixup bit 17 swizzling
|
|
|
|
* @obj: i915 GEM buffer object
|
2016-10-28 20:58:36 +08:00
|
|
|
* @pages: the scattergather list of physical pages
|
2015-07-24 23:40:15 +08:00
|
|
|
*
|
|
|
|
* This function fixes up the swizzling in case any page frame number for this
|
|
|
|
* object has changed in bit 17 since that state has been saved with
|
|
|
|
* i915_gem_object_save_bit_17_swizzle().
|
|
|
|
*
|
|
|
|
* This is called when pinning backing storage again, since the kernel is free
|
|
|
|
* to move unpinned backing storage around (either by directly moving pages or
|
|
|
|
* by swapping them out and back in again).
|
|
|
|
*/
|
2015-07-24 23:40:14 +08:00
|
|
|
void
|
2016-10-28 20:58:36 +08:00
|
|
|
i915_gem_object_do_bit_17_swizzle(struct drm_i915_gem_object *obj,
|
|
|
|
struct sg_table *pages)
|
2015-07-24 23:40:14 +08:00
|
|
|
{
|
2016-05-20 18:54:06 +08:00
|
|
|
struct sgt_iter sgt_iter;
|
|
|
|
struct page *page;
|
2015-07-24 23:40:14 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (obj->bit_17 == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
i = 0;
|
2016-10-28 20:58:36 +08:00
|
|
|
for_each_sgt_page(page, sgt_iter, pages) {
|
2015-07-24 23:40:14 +08:00
|
|
|
char new_bit_17 = page_to_phys(page) >> 17;
|
2016-10-28 20:58:36 +08:00
|
|
|
if ((new_bit_17 & 0x1) != (test_bit(i, obj->bit_17) != 0)) {
|
2015-07-24 23:40:14 +08:00
|
|
|
i915_gem_swizzle_page(page);
|
|
|
|
set_page_dirty(page);
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-24 23:40:15 +08:00
|
|
|
/**
|
|
|
|
* i915_gem_object_save_bit_17_swizzle - save bit 17 swizzling
|
|
|
|
* @obj: i915 GEM buffer object
|
2016-10-28 20:58:36 +08:00
|
|
|
* @pages: the scattergather list of physical pages
|
2015-07-24 23:40:15 +08:00
|
|
|
*
|
|
|
|
* This function saves the bit 17 of each page frame number so that swizzling
|
|
|
|
* can be fixed up later on with i915_gem_object_do_bit_17_swizzle(). This must
|
|
|
|
* be called before the backing storage can be unpinned.
|
|
|
|
*/
|
2015-07-24 23:40:14 +08:00
|
|
|
void
|
2016-10-28 20:58:36 +08:00
|
|
|
i915_gem_object_save_bit_17_swizzle(struct drm_i915_gem_object *obj,
|
|
|
|
struct sg_table *pages)
|
2015-07-24 23:40:14 +08:00
|
|
|
{
|
2016-10-28 20:58:36 +08:00
|
|
|
const unsigned int page_count = obj->base.size >> PAGE_SHIFT;
|
2016-05-20 18:54:06 +08:00
|
|
|
struct sgt_iter sgt_iter;
|
|
|
|
struct page *page;
|
2015-07-24 23:40:14 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (obj->bit_17 == NULL) {
|
2019-03-04 17:29:08 +08:00
|
|
|
obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);
|
2015-07-24 23:40:14 +08:00
|
|
|
if (obj->bit_17 == NULL) {
|
|
|
|
DRM_ERROR("Failed to allocate memory for bit 17 "
|
|
|
|
"record\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
i = 0;
|
2016-05-20 18:54:06 +08:00
|
|
|
|
2016-10-28 20:58:36 +08:00
|
|
|
for_each_sgt_page(page, sgt_iter, pages) {
|
2016-05-20 18:54:06 +08:00
|
|
|
if (page_to_phys(page) & (1 << 17))
|
2015-07-24 23:40:14 +08:00
|
|
|
__set_bit(i, obj->bit_17);
|
|
|
|
else
|
|
|
|
__clear_bit(i, obj->bit_17);
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
2019-06-13 15:32:54 +08:00
|
|
|
|
|
|
|
void i915_ggtt_init_fences(struct i915_ggtt *ggtt)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = ggtt->vm.i915;
|
|
|
|
int num_fences;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&ggtt->fence_list);
|
|
|
|
INIT_LIST_HEAD(&ggtt->userfault_list);
|
2019-06-14 07:21:56 +08:00
|
|
|
intel_wakeref_auto_init(&ggtt->userfault_wakeref, &i915->runtime_pm);
|
2019-06-13 15:32:54 +08:00
|
|
|
|
|
|
|
detect_bit_6_swizzle(i915);
|
|
|
|
|
|
|
|
if (INTEL_GEN(i915) >= 7 &&
|
|
|
|
!(IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)))
|
|
|
|
num_fences = 32;
|
|
|
|
else if (INTEL_GEN(i915) >= 4 ||
|
|
|
|
IS_I945G(i915) || IS_I945GM(i915) ||
|
|
|
|
IS_G33(i915) || IS_PINEVIEW(i915))
|
|
|
|
num_fences = 16;
|
|
|
|
else
|
|
|
|
num_fences = 8;
|
|
|
|
|
|
|
|
if (intel_vgpu_active(i915))
|
|
|
|
num_fences = intel_uncore_read(&i915->uncore,
|
|
|
|
vgtif_reg(avail_rs.fence_num));
|
|
|
|
|
|
|
|
/* Initialize fence registers to zero */
|
|
|
|
for (i = 0; i < num_fences; i++) {
|
|
|
|
struct i915_fence_reg *fence = &ggtt->fence_regs[i];
|
|
|
|
|
|
|
|
fence->i915 = i915;
|
|
|
|
fence->id = i;
|
|
|
|
list_add_tail(&fence->link, &ggtt->fence_list);
|
|
|
|
}
|
|
|
|
ggtt->num_fences = num_fences;
|
|
|
|
|
|
|
|
i915_gem_restore_fences(i915);
|
|
|
|
}
|
2019-06-21 15:07:45 +08:00
|
|
|
|
|
|
|
void intel_gt_init_swizzling(struct intel_gt *gt)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = gt->i915;
|
|
|
|
struct intel_uncore *uncore = gt->uncore;
|
|
|
|
|
|
|
|
if (INTEL_GEN(i915) < 5 ||
|
|
|
|
i915->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
|
|
|
|
return;
|
|
|
|
|
2019-06-21 15:07:46 +08:00
|
|
|
intel_uncore_rmw(uncore, DISP_ARB_CTL, 0, DISP_TILE_SURFACE_SWIZZLING);
|
2019-06-21 15:07:45 +08:00
|
|
|
|
|
|
|
if (IS_GEN(i915, 5))
|
|
|
|
return;
|
|
|
|
|
2019-06-21 15:07:46 +08:00
|
|
|
intel_uncore_rmw(uncore, TILECTL, 0, TILECTL_SWZCTL);
|
2019-06-21 15:07:45 +08:00
|
|
|
|
|
|
|
if (IS_GEN(i915, 6))
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
ARB_MODE,
|
|
|
|
_MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_SNB));
|
|
|
|
else if (IS_GEN(i915, 7))
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
ARB_MODE,
|
|
|
|
_MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_IVB));
|
|
|
|
else if (IS_GEN(i915, 8))
|
|
|
|
intel_uncore_write(uncore,
|
|
|
|
GAMTARBMODE,
|
|
|
|
_MASKED_BIT_ENABLE(ARB_MODE_SWIZZLE_BDW));
|
|
|
|
else
|
|
|
|
MISSING_CASE(INTEL_GEN(i915));
|
|
|
|
}
|