public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: ville.syrjala@linux.intel.com
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 8/8] drm/i915: Determine the stolen memory base address on gen2
Date: Thu, 28 Nov 2013 17:15:10 +0200	[thread overview]
Message-ID: <1385651710-7768-9-git-send-email-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <1385651710-7768-1-git-send-email-ville.syrjala@linux.intel.com>

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

There doesn't seem to an explicit stolen memory base register on gen2.
Some old comment in the code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.

The e820 map in said machine looks like this:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
[    0.000000] BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen memory
would start there would place it on top of some ACPI memory regions.
So not a good idea as already stated.

The 9MB region after the ACPI regions at 0x1f700000 however looks
promising given that the macine reports the stolen memory size to be
8MB. Looking at the PGTBL_CTL register, the GTT entries are at offset
0x1fee00000, and given that the GTT entries occupy 128KB, it looks like
the stolen memory could start at 0x1f700000 and the GTT entries would
occupy the last 128KB of the stolen memory. I have no idea about the
extra 1MB after the GTT entries.

I tested this on the machine in question, and so far I've not seen any
issues. Hopefully the same rules hold for all gen2 machines...

On i830 w/ local memory, stolen memory is replaced by the local memory.
In this case the page table is stored in local memory. Since the local
memory starts at offset 0, we can add an extra sanity check to make sure
the page table is really stored at the end of local memory.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 36 ++++++++++++++++++++++++----------
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 39e6404..407a9fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -51,13 +51,10 @@ static unsigned long i915_stolen_to_physical(struct drm_device *dev)
 	/* Almost universally we can find the Graphics Base of Stolen Memory
 	 * at offset 0x5c in the igfx configuration space. On a few (desktop)
 	 * machines this is also mirrored in the bridge device at different
-	 * locations, or in the MCHBAR. On gen2, the layout is again slightly
-	 * different with the Graphics Segment immediately following Top of
-	 * Memory (or Top of Usable DRAM). Note it appears that TOUD is only
-	 * reported by 865g, so we just use the top of memory as determined
-	 * by the e820 probe.
+	 * locations, or in the MCHBAR.
 	 *
-	 * XXX However gen2 requires an unavailable symbol.
+	 * Gen2 stolen base is tricky. Try to deduce it from the
+	 * page table base address.
 	 */
 	base = 0;
 	if (INTEL_INFO(dev)->gen >= 3) {
@@ -65,10 +62,29 @@ static unsigned long i915_stolen_to_physical(struct drm_device *dev)
 		pci_read_config_dword(dev->pdev, 0x5c, &base);
 		base &= ~((1<<20) - 1);
 	} else { /* GEN2 */
-#if 0
-		/* Stolen is immediately above Top of Memory */
-		base = max_low_pfn_mapped << PAGE_SHIFT;
-#endif
+		u32 pgtbl_ctl = I915_READ(I810_PGTBL_CTL);
+
+		/* GTT disabled? */
+		if (!(pgtbl_ctl & I810_PGTBL_ENABLED)) {
+			dev_priv->gtt.has_local_memory = false;
+			return 0;
+		}
+
+		pgtbl_ctl &= I810_PGTBL_ADDRESS_MASK;
+
+		/*
+		 * Assume GTT entries occupy the last 128KB of stolen/local memory.
+		 * The 128KB should already be deducted from stolen_size by this
+		 * time.
+		 */
+		base = pgtbl_ctl - dev_priv->gtt.stolen_size;
+
+		if (WARN(dev_priv->gtt.has_local_memory && base != 0,
+			 "IGD page table address (0x%x) vs. local memory size (%zu) mismatch\n",
+			 pgtbl_ctl, dev_priv->gtt.stolen_size)) {
+			dev_priv->gtt.has_local_memory = false;
+			return 0;
+		}
 	}
 
 	if (base == 0)
-- 
1.8.3.2

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

  parent reply	other threads:[~2013-11-28 15:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 15:15 [PATCH 0/8] Gen2 stolen/local memory support ville.syrjala
2013-11-28 15:15 ` [PATCH 1/8] x86: Add vfunc for Intel graphics stolen memory base address ville.syrjala
2013-11-28 15:15 ` [PATCH 2/8] x86: Add Intel graphics stolen memory quirk for gen2 platforms ville.syrjala
2013-11-30 12:58   ` Ingo Molnar
2013-11-28 15:15 ` [PATCH 3/8] intel-gtt: Return whether we have local memory or not ville.syrjala
2013-11-28 15:15 ` [PATCH 4/8] intel-gtt: Assume last 128KB of stolen contains the GTT entries on gen2 ville.syrjala
2013-11-28 15:15 ` [PATCH 5/8] intel-gtt: Use i810_write_entry() on gen2 platforms ville.syrjala
2013-11-28 15:15 ` [PATCH 6/8] drm/i915: Add I915_CACHE_LOCAL to indicate local memory ville.syrjala
2013-11-28 15:15 ` [PATCH 7/8] drm/i915: Keep track if we have " ville.syrjala
2013-11-28 15:15 ` ville.syrjala [this message]
2013-11-28 16:32   ` [PATCH 8/8] drm/i915: Determine the stolen memory base address on gen2 Chris Wilson
2013-11-28 18:01     ` Ville Syrjälä

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=1385651710-7768-9-git-send-email-ville.syrjala@linux.intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.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