[Intel-gfx] [PATCH 2/2] drm/i915/stolen: Intepret reserved_base=0 as deduce from top
Chris Wilson
chris at chris-wilson.co.uk
Mon Mar 12 12:55:42 UTC 2018
On my j1900 Valleyview, and on both of CI's, if I allocate above the power
context (as allotted by PCBR) then the objects are not accessed. For
example, if it is a ringbuffer, then the commands are not executed,
causing a GPU hang with no breadcrumb advancement. On inspection,
GEN6_STOLEN_RESERVED is enabled, but has base==0 which we interpret a
being invalid. However, it fits neatly in after the powercontext if we
interpret base==0 as meaning allocate from top instead, the GPU doesn't
hang on boot!
Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala at linux.intel.com>
Cc: Imre Deak <imre.deak at intel.com>
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index b04e2551bae6..1bd542977e4c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -386,12 +386,13 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
break;
}
- /* It is possible for the reserved base to be zero, but the register
- * field for size doesn't have a zero option. */
- if (reserved_base == 0) {
- reserved_size = 0;
- reserved_base = stolen_top;
- }
+ /*
+ * It is possible for the reserved base to be zero, but the register
+ * field for size doesn't have a zero option. Experience says they
+ * mean allocate from top.
+ */
+ if (reserved_base == 0)
+ reserved_base = stolen_top - reserved_size;
dev_priv->dsm_reserved =
(struct resource) DEFINE_RES_MEM(reserved_base, reserved_size);
--
2.16.2
More information about the Intel-gfx
mailing list