Re: [PATCH] drm/i915: Skip Stolen Memory first page.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/08/2014 17:34, Jesse Barnes wrote:
On Thu, 31 Jul 2014 12:08:20 -0700
Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote:

WA to skip the first page of stolen memory due to sporadic HW write on *CS Idle

v2: Improve variable names and fix allocated size.

Reviewed-by: Ben Widawsky <ben@xxxxxxxxxxxx>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
---
  drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++++++++++-----
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 21c025a..82035b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -289,7 +289,8 @@ void i915_gem_cleanup_stolen(struct drm_device *dev)
  int i915_gem_init_stolen(struct drm_device *dev)
  {
  	struct drm_i915_private *dev_priv = dev->dev_private;
-	int bios_reserved = 0;
+	int start_rsvd = 0;
+	int end_rsvd = 0;

  #ifdef CONFIG_INTEL_IOMMU
  	if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
@@ -308,15 +309,19 @@ int i915_gem_init_stolen(struct drm_device *dev)
  	DRM_DEBUG_KMS("found %zd bytes of stolen memory at %08lx\n",
  		      dev_priv->gtt.stolen_size, dev_priv->mm.stolen_base);

+	/* WaSkipStolenMemoryFirstPage */
+	if (INTEL_INFO(dev)->gen >= 8)
+		start_rsvd = 4096;
+
  	if (IS_VALLEYVIEW(dev))
-		bios_reserved = 1024*1024; /* top 1M on VLV/BYT */
+		end_rsvd = 1024*1024; /* top 1M on VLV/BYT */

-	if (WARN_ON(bios_reserved > dev_priv->gtt.stolen_size))
+	if (WARN_ON((start_rsvd + end_rsvd) > dev_priv->gtt.stolen_size))
  		return 0;

  	/* Basic memrange allocator for stolen space */
-	drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_size -
-		    bios_reserved);
+	drm_mm_init(&dev_priv->mm.stolen, start_rsvd,
+		    dev_priv->gtt.stolen_size - start_rsvd - end_rsvd);

  	return 0;
  }

Beyond the fastboot stuff Ville has already mentioned, the early
allocation of the existing fb from stolen will prevent us from
clobbering the currently displayed buffer with the contents of the
ringbuffers and whatever else we allocate out of stolen at early boot.

We might be able to avoid that by doing stolen allocations top down, or
by reserving the displayed fb even if we can't allocate an obj for it,
only freeing it after our first mode set.

Can you file a bug or JIRA for that to make sure we don't lose track of
the fastboot & boot corruption issues after this fix lands?

Reviving an old thread,
Any particular reason why this patch is not merged to nightly?
Is it known to cause any other regressions?

regards
Arun



Thanks,


_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux