All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2)
@ 2013-12-03 15:49 ville.syrjala
  2013-12-03 15:49   ` ville.syrjala
                   ` (5 more replies)
  0 siblings, 6 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx

Another attempt at figuring out stolen memory for gen2. This time instead
of trusting the GTT base address, I used the same method the BIOS uses.
(TOM-TSEG_SIZE-stolen_size). Except on 865G where things are more complicated.
Fortunately it seems to have a simlple answer for us in the for om the TOUD
register.

So far this has only been tested on my 855 laptop with 512MB memory.

Ville Syrjälä (6):
      x86: Add vfunc for Intel graphics stolen memory base address
      x86: Add Intel graphics stolen memory quirk for gen2 platforms
      x86: Print the Intel graphcis stolen memory range
      intel-gtt: Report stolen_size as 0 when local memory is present
      drm/i915: Don't clobber the GTT when it's within stolen memory
      drm/i915: Determine the stolen memory base address on gen2

 arch/x86/kernel/early-quirks.c         | 218 ++++++++++++++++++++++++++++-----
 drivers/char/agp/intel-gtt.c           |   7 ++
 drivers/gpu/drm/i915/i915_gem_stolen.c | 108 ++++++++++++++--
 drivers/gpu/drm/i915/i915_reg.h        |   2 +
 include/drm/i915_drm.h                 |  18 +++
 5 files changed, 313 insertions(+), 40 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH 1/6] x86: Add vfunc for Intel graphics stolen memory base address
  2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
@ 2013-12-03 15:49   ` ville.syrjala
  2013-12-03 15:49   ` ville.syrjala
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel

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

For gen2 devices we're going to need another way to determine the
stolen memory base address. Make that into a vfunc as well.

Also drop the bogus inline keyword from gen8_stolen_size().

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 77 ++++++++++++++++++++++++++----------------
 1 file changed, 48 insertions(+), 29 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bc4a088..fddd4d0 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -228,7 +228,7 @@ static void __init intel_remapping_check(int num, int slot, int func)
  *
  * And yes, so far on current devices the base addr is always under 4G.
  */
-static u32 __init intel_stolen_base(int num, int slot, int func)
+static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_size)
 {
 	u32 base;
 
@@ -313,7 +313,7 @@ static size_t __init gen6_stolen_size(int num, int slot, int func)
 	return gmch_ctrl << 25; /* 32 MB units */
 }
 
-static inline size_t gen8_stolen_size(int num, int slot, int func)
+static size_t gen8_stolen_size(int num, int slot, int func)
 {
 	u16 gmch_ctrl;
 
@@ -323,31 +323,50 @@ static inline size_t gen8_stolen_size(int num, int slot, int func)
 	return gmch_ctrl << 25; /* 32 MB units */
 }
 
-typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+struct intel_stolen_funcs {
+	size_t (*size)(int num, int slot, int func);
+	u32 (*base)(int num, int slot, int func, size_t size);
+};
+
+static const struct intel_stolen_funcs gen3_stolen_funcs = {
+	.base = intel_stolen_base,
+	.size = gen3_stolen_size,
+};
+
+static const struct intel_stolen_funcs gen6_stolen_funcs = {
+	.base = intel_stolen_base,
+	.size = gen6_stolen_size,
+};
+
+static const struct intel_stolen_funcs gen8_stolen_funcs = {
+	.base = intel_stolen_base,
+	.size = gen8_stolen_size,
+};
 
 static struct pci_device_id intel_stolen_ids[] __initdata = {
-	INTEL_I915G_IDS(gen3_stolen_size),
-	INTEL_I915GM_IDS(gen3_stolen_size),
-	INTEL_I945G_IDS(gen3_stolen_size),
-	INTEL_I945GM_IDS(gen3_stolen_size),
-	INTEL_VLV_M_IDS(gen6_stolen_size),
-	INTEL_VLV_D_IDS(gen6_stolen_size),
-	INTEL_PINEVIEW_IDS(gen3_stolen_size),
-	INTEL_I965G_IDS(gen3_stolen_size),
-	INTEL_G33_IDS(gen3_stolen_size),
-	INTEL_I965GM_IDS(gen3_stolen_size),
-	INTEL_GM45_IDS(gen3_stolen_size),
-	INTEL_G45_IDS(gen3_stolen_size),
-	INTEL_IRONLAKE_D_IDS(gen3_stolen_size),
-	INTEL_IRONLAKE_M_IDS(gen3_stolen_size),
-	INTEL_SNB_D_IDS(gen6_stolen_size),
-	INTEL_SNB_M_IDS(gen6_stolen_size),
-	INTEL_IVB_M_IDS(gen6_stolen_size),
-	INTEL_IVB_D_IDS(gen6_stolen_size),
-	INTEL_HSW_D_IDS(gen6_stolen_size),
-	INTEL_HSW_M_IDS(gen6_stolen_size),
-	INTEL_BDW_M_IDS(gen8_stolen_size),
-	INTEL_BDW_D_IDS(gen8_stolen_size)
+	INTEL_I915G_IDS(&gen3_stolen_funcs),
+	INTEL_I915GM_IDS(&gen3_stolen_funcs),
+	INTEL_I945G_IDS(&gen3_stolen_funcs),
+	INTEL_I945GM_IDS(&gen3_stolen_funcs),
+	INTEL_VLV_M_IDS(&gen6_stolen_funcs),
+	INTEL_VLV_D_IDS(&gen6_stolen_funcs),
+	INTEL_PINEVIEW_IDS(&gen3_stolen_funcs),
+	INTEL_I965G_IDS(&gen3_stolen_funcs),
+	INTEL_G33_IDS(&gen3_stolen_funcs),
+	INTEL_I965GM_IDS(&gen3_stolen_funcs),
+	INTEL_GM45_IDS(&gen3_stolen_funcs),
+	INTEL_G45_IDS(&gen3_stolen_funcs),
+	INTEL_IRONLAKE_D_IDS(&gen3_stolen_funcs),
+	INTEL_IRONLAKE_M_IDS(&gen3_stolen_funcs),
+	INTEL_SNB_D_IDS(&gen6_stolen_funcs),
+	INTEL_SNB_M_IDS(&gen6_stolen_funcs),
+	INTEL_IVB_M_IDS(&gen6_stolen_funcs),
+	INTEL_IVB_D_IDS(&gen6_stolen_funcs),
+	INTEL_HSW_D_IDS(&gen6_stolen_funcs),
+	INTEL_HSW_M_IDS(&gen6_stolen_funcs),
+	INTEL_BDW_M_IDS(&gen8_stolen_funcs),
+	INTEL_BDW_D_IDS(&gen8_stolen_funcs)
 };
 
 static void __init intel_graphics_stolen(int num, int slot, int func)
@@ -364,10 +383,10 @@ static void __init intel_graphics_stolen(int num, int slot, int func)
 
 	for (i = 0; i < ARRAY_SIZE(intel_stolen_ids); i++) {
 		if (intel_stolen_ids[i].device == device) {
-			stolen_size_fn stolen_size =
-				(stolen_size_fn)intel_stolen_ids[i].driver_data;
-			size = stolen_size(num, slot, func);
-			start = intel_stolen_base(num, slot, func);
+			const struct intel_stolen_funcs *stolen_funcs =
+				(const struct intel_stolen_funcs *)intel_stolen_ids[i].driver_data;
+			size = stolen_funcs->size(num, slot, func);
+			start = stolen_funcs->base(num, slot, func, size);
 			if (size && start) {
 				/* Mark this space as reserved */
 				e820_add_region(start, size, E820_RESERVED);
-- 
1.8.3.2


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 1/6] x86: Add vfunc for Intel graphics stolen memory base address
@ 2013-12-03 15:49   ` ville.syrjala
  0 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, x86, H. Peter Anvin

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

For gen2 devices we're going to need another way to determine the
stolen memory base address. Make that into a vfunc as well.

Also drop the bogus inline keyword from gen8_stolen_size().

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 77 ++++++++++++++++++++++++++----------------
 1 file changed, 48 insertions(+), 29 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bc4a088..fddd4d0 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -228,7 +228,7 @@ static void __init intel_remapping_check(int num, int slot, int func)
  *
  * And yes, so far on current devices the base addr is always under 4G.
  */
-static u32 __init intel_stolen_base(int num, int slot, int func)
+static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_size)
 {
 	u32 base;
 
@@ -313,7 +313,7 @@ static size_t __init gen6_stolen_size(int num, int slot, int func)
 	return gmch_ctrl << 25; /* 32 MB units */
 }
 
-static inline size_t gen8_stolen_size(int num, int slot, int func)
+static size_t gen8_stolen_size(int num, int slot, int func)
 {
 	u16 gmch_ctrl;
 
@@ -323,31 +323,50 @@ static inline size_t gen8_stolen_size(int num, int slot, int func)
 	return gmch_ctrl << 25; /* 32 MB units */
 }
 
-typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+struct intel_stolen_funcs {
+	size_t (*size)(int num, int slot, int func);
+	u32 (*base)(int num, int slot, int func, size_t size);
+};
+
+static const struct intel_stolen_funcs gen3_stolen_funcs = {
+	.base = intel_stolen_base,
+	.size = gen3_stolen_size,
+};
+
+static const struct intel_stolen_funcs gen6_stolen_funcs = {
+	.base = intel_stolen_base,
+	.size = gen6_stolen_size,
+};
+
+static const struct intel_stolen_funcs gen8_stolen_funcs = {
+	.base = intel_stolen_base,
+	.size = gen8_stolen_size,
+};
 
 static struct pci_device_id intel_stolen_ids[] __initdata = {
-	INTEL_I915G_IDS(gen3_stolen_size),
-	INTEL_I915GM_IDS(gen3_stolen_size),
-	INTEL_I945G_IDS(gen3_stolen_size),
-	INTEL_I945GM_IDS(gen3_stolen_size),
-	INTEL_VLV_M_IDS(gen6_stolen_size),
-	INTEL_VLV_D_IDS(gen6_stolen_size),
-	INTEL_PINEVIEW_IDS(gen3_stolen_size),
-	INTEL_I965G_IDS(gen3_stolen_size),
-	INTEL_G33_IDS(gen3_stolen_size),
-	INTEL_I965GM_IDS(gen3_stolen_size),
-	INTEL_GM45_IDS(gen3_stolen_size),
-	INTEL_G45_IDS(gen3_stolen_size),
-	INTEL_IRONLAKE_D_IDS(gen3_stolen_size),
-	INTEL_IRONLAKE_M_IDS(gen3_stolen_size),
-	INTEL_SNB_D_IDS(gen6_stolen_size),
-	INTEL_SNB_M_IDS(gen6_stolen_size),
-	INTEL_IVB_M_IDS(gen6_stolen_size),
-	INTEL_IVB_D_IDS(gen6_stolen_size),
-	INTEL_HSW_D_IDS(gen6_stolen_size),
-	INTEL_HSW_M_IDS(gen6_stolen_size),
-	INTEL_BDW_M_IDS(gen8_stolen_size),
-	INTEL_BDW_D_IDS(gen8_stolen_size)
+	INTEL_I915G_IDS(&gen3_stolen_funcs),
+	INTEL_I915GM_IDS(&gen3_stolen_funcs),
+	INTEL_I945G_IDS(&gen3_stolen_funcs),
+	INTEL_I945GM_IDS(&gen3_stolen_funcs),
+	INTEL_VLV_M_IDS(&gen6_stolen_funcs),
+	INTEL_VLV_D_IDS(&gen6_stolen_funcs),
+	INTEL_PINEVIEW_IDS(&gen3_stolen_funcs),
+	INTEL_I965G_IDS(&gen3_stolen_funcs),
+	INTEL_G33_IDS(&gen3_stolen_funcs),
+	INTEL_I965GM_IDS(&gen3_stolen_funcs),
+	INTEL_GM45_IDS(&gen3_stolen_funcs),
+	INTEL_G45_IDS(&gen3_stolen_funcs),
+	INTEL_IRONLAKE_D_IDS(&gen3_stolen_funcs),
+	INTEL_IRONLAKE_M_IDS(&gen3_stolen_funcs),
+	INTEL_SNB_D_IDS(&gen6_stolen_funcs),
+	INTEL_SNB_M_IDS(&gen6_stolen_funcs),
+	INTEL_IVB_M_IDS(&gen6_stolen_funcs),
+	INTEL_IVB_D_IDS(&gen6_stolen_funcs),
+	INTEL_HSW_D_IDS(&gen6_stolen_funcs),
+	INTEL_HSW_M_IDS(&gen6_stolen_funcs),
+	INTEL_BDW_M_IDS(&gen8_stolen_funcs),
+	INTEL_BDW_D_IDS(&gen8_stolen_funcs)
 };
 
 static void __init intel_graphics_stolen(int num, int slot, int func)
@@ -364,10 +383,10 @@ static void __init intel_graphics_stolen(int num, int slot, int func)
 
 	for (i = 0; i < ARRAY_SIZE(intel_stolen_ids); i++) {
 		if (intel_stolen_ids[i].device == device) {
-			stolen_size_fn stolen_size =
-				(stolen_size_fn)intel_stolen_ids[i].driver_data;
-			size = stolen_size(num, slot, func);
-			start = intel_stolen_base(num, slot, func);
+			const struct intel_stolen_funcs *stolen_funcs =
+				(const struct intel_stolen_funcs *)intel_stolen_ids[i].driver_data;
+			size = stolen_funcs->size(num, slot, func);
+			start = stolen_funcs->base(num, slot, func, size);
 			if (size && start) {
 				/* Mark this space as reserved */
 				e820_add_region(start, size, E820_RESERVED);
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
@ 2013-12-03 15:49   ` ville.syrjala
  2013-12-03 15:49   ` ville.syrjala
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 855 machine, and so far everything looks
peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 139 +++++++++++++++++++++++++++++++++++++++++
 include/drm/i915_drm.h         |  18 ++++++
 2 files changed, 157 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fddd4d0..66357bf 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -247,6 +247,121 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
 #define MB(x)	(KB (KB (x)))
 #define GB(x)	(MB (KB (x)))
 
+/* FIXME is this actually correct for 830? */
+static size_t __init i830_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	switch (tmp & TSEG_SIZE_MASK) {
+	case TSEG_SIZE_512K:
+		return KB(512);
+	case TSEG_SIZE_1M:
+		return MB(1);
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+}
+
+static size_t __init i845_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	switch (tmp & TSEG_SIZE_MASK) {
+	case TSEG_SIZE_512K:
+		return KB(512);
+	case TSEG_SIZE_1M:
+		return MB(1);
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+}
+
+static size_t __init i85x_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	return MB(1);
+}
+
+/* FIXME is this actually correct for 830? */
+static size_t __init i830_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
+}
+
+static size_t __init i85x_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
+}
+
+/*
+ * On 830/845/85x the stolen memory base isn't available in any
+ * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
+ */
+static u32 __init i830_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i830_tseg_size() - stolen_size;
+}
+
+static u32 __init i845_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i845_tseg_size() - stolen_size;
+}
+
+static u32 __init i85x_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i85x_mem_size() - i85x_tseg_size() - stolen_size;
+}
+
+static u32 __init i865_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	/*
+	 * FIXME is the graphics stolen memory region
+	 * always at TOUD? Ie. is it always the last
+	 * one to be allocated by the BIOS?
+	 */
+	return read_pci_config_16(0, 0, 0, I865_TOUD) << 16;
+}
+
+static size_t __init i830_stolen_size(int num, int slot, int func)
+{
+	size_t stolen_size;
+	u16 gmch_ctrl;
+
+	gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
+
+	switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
+	case I830_GMCH_GMS_STOLEN_512:
+		stolen_size = KB(512);
+		break;
+	case I830_GMCH_GMS_STOLEN_1024:
+		stolen_size = MB(1);
+		break;
+	case I830_GMCH_GMS_STOLEN_8192:
+		stolen_size = MB(8);
+		break;
+	case I830_GMCH_GMS_LOCAL:
+		/* local memory isn't part of the normal address space */
+		stolen_size = 0;
+		break;
+	default:
+		return 0;
+	}
+
+	return stolen_size;
+}
+
 static size_t __init gen3_stolen_size(int num, int slot, int func)
 {
 	size_t stolen_size;
@@ -329,6 +444,26 @@ struct intel_stolen_funcs {
 	u32 (*base)(int num, int slot, int func, size_t size);
 };
 
+static const struct intel_stolen_funcs i830_stolen_funcs = {
+	.base = i830_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i845_stolen_funcs = {
+	.base = i845_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i85x_stolen_funcs = {
+	.base = i85x_stolen_base,
+	.size = gen3_stolen_size,
+};
+
+static const struct intel_stolen_funcs i865_stolen_funcs = {
+	.base = i865_stolen_base,
+	.size = gen3_stolen_size,
+};
+
 static const struct intel_stolen_funcs gen3_stolen_funcs = {
 	.base = intel_stolen_base,
 	.size = gen3_stolen_size,
@@ -345,6 +480,10 @@ static const struct intel_stolen_funcs gen8_stolen_funcs = {
 };
 
 static struct pci_device_id intel_stolen_ids[] __initdata = {
+	INTEL_I830_IDS(&i830_stolen_funcs),
+	INTEL_I845G_IDS(&i845_stolen_funcs),
+	INTEL_I85X_IDS(&i85x_stolen_funcs),
+	INTEL_I865G_IDS(&i865_stolen_funcs),
 	INTEL_I915G_IDS(&gen3_stolen_funcs),
 	INTEL_I915GM_IDS(&gen3_stolen_funcs),
 	INTEL_I945G_IDS(&gen3_stolen_funcs),
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 97d5497..ebfa5168 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -56,6 +56,12 @@ extern bool i915_gpu_turbo_disable(void);
 
 #define I830_GMCH_CTRL			0x52
 
+#define I830_GMCH_GMS_MASK		0x70
+#define I830_GMCH_GMS_LOCAL		0x10
+#define I830_GMCH_GMS_STOLEN_512	0x20
+#define I830_GMCH_GMS_STOLEN_1024	0x30
+#define I830_GMCH_GMS_STOLEN_8192	0x40
+
 #define I855_GMCH_GMS_MASK		0xF0
 #define I855_GMCH_GMS_STOLEN_0M		0x0
 #define I855_GMCH_GMS_STOLEN_1M		(0x1 << 4)
@@ -72,4 +78,16 @@ extern bool i915_gpu_turbo_disable(void);
 #define INTEL_GMCH_GMS_STOLEN_224M	(0xc << 4)
 #define INTEL_GMCH_GMS_STOLEN_352M	(0xd << 4)
 
+#define I830_DRB3		0x63
+#define I85X_DRB3		0x43
+#define I865_TOUD		0xc4
+
+#define I830_ESMRAMC		0x91
+#define I845_ESMRAMC		0x9e
+#define I85X_ESMRAMC		0x61
+#define    TSEG_ENABLE		(1 << 0)
+#define    TSEG_SIZE_MASK	(3 << 1)
+#define    TSEG_SIZE_512K	(2 << 1)
+#define    TSEG_SIZE_1M		(3 << 1)
+
 #endif				/* _I915_DRM_H_ */
-- 
1.8.3.2


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
@ 2013-12-03 15:49   ` ville.syrjala
  0 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, x86, H. Peter Anvin

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 855 machine, and so far everything looks
peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 139 +++++++++++++++++++++++++++++++++++++++++
 include/drm/i915_drm.h         |  18 ++++++
 2 files changed, 157 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fddd4d0..66357bf 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -247,6 +247,121 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
 #define MB(x)	(KB (KB (x)))
 #define GB(x)	(MB (KB (x)))
 
+/* FIXME is this actually correct for 830? */
+static size_t __init i830_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	switch (tmp & TSEG_SIZE_MASK) {
+	case TSEG_SIZE_512K:
+		return KB(512);
+	case TSEG_SIZE_1M:
+		return MB(1);
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+}
+
+static size_t __init i845_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	switch (tmp & TSEG_SIZE_MASK) {
+	case TSEG_SIZE_512K:
+		return KB(512);
+	case TSEG_SIZE_1M:
+		return MB(1);
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+}
+
+static size_t __init i85x_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	return MB(1);
+}
+
+/* FIXME is this actually correct for 830? */
+static size_t __init i830_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
+}
+
+static size_t __init i85x_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
+}
+
+/*
+ * On 830/845/85x the stolen memory base isn't available in any
+ * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
+ */
+static u32 __init i830_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i830_tseg_size() - stolen_size;
+}
+
+static u32 __init i845_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i845_tseg_size() - stolen_size;
+}
+
+static u32 __init i85x_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i85x_mem_size() - i85x_tseg_size() - stolen_size;
+}
+
+static u32 __init i865_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	/*
+	 * FIXME is the graphics stolen memory region
+	 * always at TOUD? Ie. is it always the last
+	 * one to be allocated by the BIOS?
+	 */
+	return read_pci_config_16(0, 0, 0, I865_TOUD) << 16;
+}
+
+static size_t __init i830_stolen_size(int num, int slot, int func)
+{
+	size_t stolen_size;
+	u16 gmch_ctrl;
+
+	gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
+
+	switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
+	case I830_GMCH_GMS_STOLEN_512:
+		stolen_size = KB(512);
+		break;
+	case I830_GMCH_GMS_STOLEN_1024:
+		stolen_size = MB(1);
+		break;
+	case I830_GMCH_GMS_STOLEN_8192:
+		stolen_size = MB(8);
+		break;
+	case I830_GMCH_GMS_LOCAL:
+		/* local memory isn't part of the normal address space */
+		stolen_size = 0;
+		break;
+	default:
+		return 0;
+	}
+
+	return stolen_size;
+}
+
 static size_t __init gen3_stolen_size(int num, int slot, int func)
 {
 	size_t stolen_size;
@@ -329,6 +444,26 @@ struct intel_stolen_funcs {
 	u32 (*base)(int num, int slot, int func, size_t size);
 };
 
+static const struct intel_stolen_funcs i830_stolen_funcs = {
+	.base = i830_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i845_stolen_funcs = {
+	.base = i845_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i85x_stolen_funcs = {
+	.base = i85x_stolen_base,
+	.size = gen3_stolen_size,
+};
+
+static const struct intel_stolen_funcs i865_stolen_funcs = {
+	.base = i865_stolen_base,
+	.size = gen3_stolen_size,
+};
+
 static const struct intel_stolen_funcs gen3_stolen_funcs = {
 	.base = intel_stolen_base,
 	.size = gen3_stolen_size,
@@ -345,6 +480,10 @@ static const struct intel_stolen_funcs gen8_stolen_funcs = {
 };
 
 static struct pci_device_id intel_stolen_ids[] __initdata = {
+	INTEL_I830_IDS(&i830_stolen_funcs),
+	INTEL_I845G_IDS(&i845_stolen_funcs),
+	INTEL_I85X_IDS(&i85x_stolen_funcs),
+	INTEL_I865G_IDS(&i865_stolen_funcs),
 	INTEL_I915G_IDS(&gen3_stolen_funcs),
 	INTEL_I915GM_IDS(&gen3_stolen_funcs),
 	INTEL_I945G_IDS(&gen3_stolen_funcs),
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 97d5497..ebfa5168 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -56,6 +56,12 @@ extern bool i915_gpu_turbo_disable(void);
 
 #define I830_GMCH_CTRL			0x52
 
+#define I830_GMCH_GMS_MASK		0x70
+#define I830_GMCH_GMS_LOCAL		0x10
+#define I830_GMCH_GMS_STOLEN_512	0x20
+#define I830_GMCH_GMS_STOLEN_1024	0x30
+#define I830_GMCH_GMS_STOLEN_8192	0x40
+
 #define I855_GMCH_GMS_MASK		0xF0
 #define I855_GMCH_GMS_STOLEN_0M		0x0
 #define I855_GMCH_GMS_STOLEN_1M		(0x1 << 4)
@@ -72,4 +78,16 @@ extern bool i915_gpu_turbo_disable(void);
 #define INTEL_GMCH_GMS_STOLEN_224M	(0xc << 4)
 #define INTEL_GMCH_GMS_STOLEN_352M	(0xd << 4)
 
+#define I830_DRB3		0x63
+#define I85X_DRB3		0x43
+#define I865_TOUD		0xc4
+
+#define I830_ESMRAMC		0x91
+#define I845_ESMRAMC		0x9e
+#define I85X_ESMRAMC		0x61
+#define    TSEG_ENABLE		(1 << 0)
+#define    TSEG_SIZE_MASK	(3 << 1)
+#define    TSEG_SIZE_512K	(2 << 1)
+#define    TSEG_SIZE_1M		(3 << 1)
+
 #endif				/* _I915_DRM_H_ */
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 3/6] x86: Print the Intel graphcis stolen memory range
  2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
@ 2013-12-03 15:49   ` ville.syrjala
  2013-12-03 15:49   ` ville.syrjala
                     ` (4 subsequent siblings)
  5 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel

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

Print an informative message when reserving the graphics stolen
memory region in the early quirk.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 66357bf..d15e087 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -527,6 +527,8 @@ static void __init intel_graphics_stolen(int num, int slot, int func)
 			size = stolen_funcs->size(num, slot, func);
 			start = stolen_funcs->base(num, slot, func, size);
 			if (size && start) {
+				printk(KERN_INFO "Reserving Intel graphics stolen memory at 0x%x-0x%x\n",
+				       start, start + (u32)size - 1);
 				/* Mark this space as reserved */
 				e820_add_region(start, size, E820_RESERVED);
 				sanitize_e820_map(e820.map,
-- 
1.8.3.2


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 3/6] x86: Print the Intel graphcis stolen memory range
@ 2013-12-03 15:49   ` ville.syrjala
  0 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, x86, H. Peter Anvin

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

Print an informative message when reserving the graphics stolen
memory region in the early quirk.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 66357bf..d15e087 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -527,6 +527,8 @@ static void __init intel_graphics_stolen(int num, int slot, int func)
 			size = stolen_funcs->size(num, slot, func);
 			start = stolen_funcs->base(num, slot, func, size);
 			if (size && start) {
+				printk(KERN_INFO "Reserving Intel graphics stolen memory at 0x%x-0x%x\n",
+				       start, start + (u32)size - 1);
 				/* Mark this space as reserved */
 				e820_add_region(start, size, E820_RESERVED);
 				sanitize_e820_map(e820.map,
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 4/6] intel-gtt: Report stolen_size as 0 when local memory is present
  2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
                   ` (2 preceding siblings ...)
  2013-12-03 15:49   ` ville.syrjala
@ 2013-12-03 15:49 ` ville.syrjala
  2013-12-03 15:49 ` [PATCH 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory ville.syrjala
  2013-12-03 15:49 ` [PATCH v2 6/6] drm/i915: Determine the stolen memory base address on gen2 ville.syrjala
  5 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx

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

We don't have proper support for local memory elsewhere in the code,
and seeing as no-one seems to have ever seen a system which has local
memory, just report stolen_size as 0 when local memory is detected.

Add a big WARN to alert us if someone were to stumble on one of these
imaginary beasts.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/char/agp/intel-gtt.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 078968d..d7a1ed3 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -437,6 +437,13 @@ static unsigned int intel_gtt_stolen_size(void)
 		stolen_size = 0;
 	}
 
+	/*
+	 * Assumption is that systems with local
+	 * memory don't actually exist in the wild.
+	 */
+	if (WARN(local, "Unicorn sighted! Stop the presses!\n"))
+		stolen_size = 0;
+
 	return stolen_size;
 }
 
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory
  2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
                   ` (3 preceding siblings ...)
  2013-12-03 15:49 ` [PATCH 4/6] intel-gtt: Report stolen_size as 0 when local memory is present ville.syrjala
@ 2013-12-03 15:49 ` ville.syrjala
  2014-06-05 17:02   ` [PATCH v2 " ville.syrjala
  2013-12-03 15:49 ` [PATCH v2 6/6] drm/i915: Determine the stolen memory base address on gen2 ville.syrjala
  5 siblings, 1 reply; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx

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

On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 36 ++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/i915_reg.h        |  2 ++
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index d284d89..deb349a 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -74,6 +74,42 @@ static unsigned long i915_stolen_to_physical(struct drm_device *dev)
 	if (base == 0)
 		return 0;
 
+	/* make sure we don't clobber the GTT if it's within stolen memory */
+	if (INTEL_INFO(dev)->gen <= 4 && !IS_G33(dev) && !IS_G4X(dev)) {
+		struct {
+			u32 start, end;
+		} stolen[2] = {
+			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
+			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
+		};
+		u32 gtt_start = I915_READ(PGTBL_CTL) & PGTBL_ADDRESS_MASK;
+		u32 gtt_end = gtt_start + gtt_total_entries(dev_priv->gtt) * 4;
+
+		if (gtt_start >= stolen[0].start && gtt_start < stolen[0].end)
+			stolen[0].end = gtt_start;
+		if (gtt_end > stolen[1].start && gtt_end <= stolen[1].end)
+			stolen[1].start = gtt_end;
+
+		/* pick the larger of the two chunks */
+		if (stolen[0].end - stolen[0].start >
+		    stolen[1].end - stolen[1].start) {
+			base = stolen[0].start;
+			dev_priv->gtt.stolen_size = stolen[0].end - stolen[0].start;
+		} else {
+			base = stolen[1].start;
+			dev_priv->gtt.stolen_size = stolen[1].end - stolen[1].start;
+		}
+
+		if (stolen[0].start != stolen[1].start ||
+		    stolen[0].end != stolen[1].end) {
+			DRM_DEBUG_KMS("GTT within stolen memory at 0x%x-0x%x\n",
+				      gtt_start, gtt_end - 1);
+			DRM_DEBUG_KMS("Stolen memory adjusted to 0x%x-0x%x\n",
+				      base, base + (u32) dev_priv->gtt.stolen_size - 1);
+		}
+	}
+
+
 	/* Verify that nothing else uses this physical address. Stolen
 	 * memory should be reserved by the BIOS and hidden from the
 	 * kernel. So if the region is already marked as busy, something
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3be449d..e7dde2c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -630,6 +630,8 @@
 /*
  * Instruction and interrupt control regs
  */
+#define PGTBL_CTL	0x02020
+#define   PGTBL_ADDRESS_MASK	0xfffff000
 #define PGTBL_ER	0x02024
 #define RENDER_RING_BASE	0x02000
 #define BSD_RING_BASE		0x04000
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 6/6] drm/i915: Determine the stolen memory base address on gen2
  2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
                   ` (4 preceding siblings ...)
  2013-12-03 15:49 ` [PATCH 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory ville.syrjala
@ 2013-12-03 15:49 ` ville.syrjala
  2014-01-07 15:28   ` [PATCH v3 " ville.syrjala
  5 siblings, 1 reply; 28+ messages in thread
From: ville.syrjala @ 2013-12-03 15:49 UTC (permalink / raw)
  To: intel-gfx

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 855 machine, and so far everything looks
peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods

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

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index deb349a..38421f1 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -30,6 +30,9 @@
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
 
+#define KB(x) ((x) * 1024)
+#define MB(x) (KB(x) * 1024)
+
 /*
  * The BIOS typically reserves some of the system's memory for the exclusive
  * use of the integrated graphics. This memory is no longer available for
@@ -51,24 +54,71 @@ 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.
+	 *
+	 * On 865 we just check the TOUD register.
+	 *
+	 * On 830/845/85x the stolen memory base isn't available in any
+	 * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
 	 *
-	 * XXX However gen2 requires an unavailable symbol.
 	 */
 	base = 0;
 	if (INTEL_INFO(dev)->gen >= 3) {
 		/* Read Graphics Base of Stolen Memory directly */
 		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
+	} else if (IS_I865G(dev)) {
+		u16 toud = 0;
+
+		/*
+		 * FIXME is the graphics stolen memory region
+		 * always at TOUD? Ie. is it always the last
+		 * one to be allocated by the BIOS?
+		 */
+		pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I865_TOUD, &toud);
+
+		base = toud << 16;
+	} else if (IS_I85X(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0), I85X_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE)
+			tseg_size = MB(1);
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 1),
+					 I85X_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
+	} else if (IS_I830(dev) || IS_845G(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 IS_I830(dev) ? I830_ESMRAMC :
+					 I845_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE) {
+			switch (tmp & TSEG_SIZE_MASK) {
+			case TSEG_SIZE_512K:
+				tseg_size = KB(512);
+				break;
+			case TSEG_SIZE_1M:
+				tseg_size = MB(1);
+				break;
+			}
+		}
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
 	}
 
 	if (base == 0)
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2013-12-03 15:49   ` ville.syrjala
@ 2013-12-04  9:08     ` Ingo Molnar
  -1 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2013-12-04  9:08 UTC (permalink / raw)
  To: ville.syrjala
  Cc: intel-gfx, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
	linux-kernel


* ville.syrjala@linux.intel.com <ville.syrjala@linux.intel.com> wrote:

> v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods

I guess v2 is a reaction to my review feedback? I got no reply to my 
mail from you so I'm not sure and I'd like to know whether all 
feedback was addressed.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
@ 2013-12-04  9:08     ` Ingo Molnar
  0 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2013-12-04  9:08 UTC (permalink / raw)
  To: ville.syrjala
  Cc: intel-gfx, x86, linux-kernel, Ingo Molnar, H. Peter Anvin,
	Thomas Gleixner


* ville.syrjala@linux.intel.com <ville.syrjala@linux.intel.com> wrote:

> v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods

I guess v2 is a reaction to my review feedback? I got no reply to my 
mail from you so I'm not sure and I'd like to know whether all 
feedback was addressed.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2013-12-04  9:08     ` Ingo Molnar
@ 2013-12-04 15:12       ` Ville Syrjälä
  -1 siblings, 0 replies; 28+ messages in thread
From: Ville Syrjälä @ 2013-12-04 15:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: intel-gfx, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
	linux-kernel

On Wed, Dec 04, 2013 at 10:08:14AM +0100, Ingo Molnar wrote:
> 
> * ville.syrjala@linux.intel.com <ville.syrjala@linux.intel.com> wrote:
> 
> > v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
> 
> I guess v2 is a reaction to my review feedback? I got no reply to my 
> mail from you so I'm not sure and I'd like to know whether all 
> feedback was addressed.

Actually this was mostly insipired by a private mail from hpa. I forgot
to reply to your mail, sorry about that.

But anyways, I think apart from your comment about the KB/MB macros,
the rest of the comments no longer apply. And as far as those macros
go, there seem to be similar macros already sprinkled around in various
places, so I'm not sure how big of a fallout we'd have if I just stick
them into kernel.h.

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
@ 2013-12-04 15:12       ` Ville Syrjälä
  0 siblings, 0 replies; 28+ messages in thread
From: Ville Syrjälä @ 2013-12-04 15:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: intel-gfx, x86, linux-kernel, Ingo Molnar, H. Peter Anvin,
	Thomas Gleixner

On Wed, Dec 04, 2013 at 10:08:14AM +0100, Ingo Molnar wrote:
> 
> * ville.syrjala@linux.intel.com <ville.syrjala@linux.intel.com> wrote:
> 
> > v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
> 
> I guess v2 is a reaction to my review feedback? I got no reply to my 
> mail from you so I'm not sure and I'd like to know whether all 
> feedback was addressed.

Actually this was mostly insipired by a private mail from hpa. I forgot
to reply to your mail, sorry about that.

But anyways, I think apart from your comment about the KB/MB macros,
the rest of the comments no longer apply. And as far as those macros
go, there seem to be similar macros already sprinkled around in various
places, so I'm not sure how big of a fallout we'd have if I just stick
them into kernel.h.

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2013-12-04 15:12       ` Ville Syrjälä
  (?)
@ 2013-12-04 15:15       ` Ingo Molnar
  -1 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2013-12-04 15:15 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: intel-gfx, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
	linux-kernel


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

> On Wed, Dec 04, 2013 at 10:08:14AM +0100, Ingo Molnar wrote:
> > 
> > * ville.syrjala@linux.intel.com <ville.syrjala@linux.intel.com> wrote:
> > 
> > > v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
> > 
> > I guess v2 is a reaction to my review feedback? I got no reply to my 
> > mail from you so I'm not sure and I'd like to know whether all 
> > feedback was addressed.
> 
> Actually this was mostly insipired by a private mail from hpa. I forgot
> to reply to your mail, sorry about that.
> 
> But anyways, I think apart from your comment about the KB/MB macros,
> the rest of the comments no longer apply. [...]

Ok.

> [...] And as far as those macros go, there seem to be similar macros 
> already sprinkled around in various places, so I'm not sure how big 
> of a fallout we'd have if I just stick them into kernel.h.

That was a separate suggestion, outside the scope of this series.

Anyway, this v2 series looks good.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2013-12-03 15:49   ` ville.syrjala
@ 2014-01-07 15:28     ` ville.syrjala
  -1 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2014-01-07 15:28 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 830 and 855 machines, and so far everything
looks peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 132 +++++++++++++++++++++++++++++++++++++++++
 include/drm/i915_drm.h         |  20 +++++++
 2 files changed, 152 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fddd4d0..5218dd2 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -247,6 +247,114 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
 #define MB(x)	(KB (KB (x)))
 #define GB(x)	(MB (KB (x)))
 
+static size_t __init i830_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	if (tmp & I830_TSEG_SIZE_1M)
+		return MB(1);
+	else
+		return KB(512);
+}
+
+static size_t __init i845_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	switch (tmp & I845_TSEG_SIZE_MASK) {
+	case I845_TSEG_SIZE_512K:
+		return KB(512);
+	case I845_TSEG_SIZE_1M:
+		return MB(1);
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+}
+
+static size_t __init i85x_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	return MB(1);
+}
+
+static size_t __init i830_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
+}
+
+static size_t __init i85x_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
+}
+
+/*
+ * On 830/845/85x the stolen memory base isn't available in any
+ * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
+ */
+static u32 __init i830_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i830_tseg_size() - stolen_size;
+}
+
+static u32 __init i845_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i845_tseg_size() - stolen_size;
+}
+
+static u32 __init i85x_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i85x_mem_size() - i85x_tseg_size() - stolen_size;
+}
+
+static u32 __init i865_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	/*
+	 * FIXME is the graphics stolen memory region
+	 * always at TOUD? Ie. is it always the last
+	 * one to be allocated by the BIOS?
+	 */
+	return read_pci_config_16(0, 0, 0, I865_TOUD) << 16;
+}
+
+static size_t __init i830_stolen_size(int num, int slot, int func)
+{
+	size_t stolen_size;
+	u16 gmch_ctrl;
+
+	gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
+
+	switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
+	case I830_GMCH_GMS_STOLEN_512:
+		stolen_size = KB(512);
+		break;
+	case I830_GMCH_GMS_STOLEN_1024:
+		stolen_size = MB(1);
+		break;
+	case I830_GMCH_GMS_STOLEN_8192:
+		stolen_size = MB(8);
+		break;
+	case I830_GMCH_GMS_LOCAL:
+		/* local memory isn't part of the normal address space */
+		stolen_size = 0;
+		break;
+	default:
+		return 0;
+	}
+
+	return stolen_size;
+}
+
 static size_t __init gen3_stolen_size(int num, int slot, int func)
 {
 	size_t stolen_size;
@@ -329,6 +437,26 @@ struct intel_stolen_funcs {
 	u32 (*base)(int num, int slot, int func, size_t size);
 };
 
+static const struct intel_stolen_funcs i830_stolen_funcs = {
+	.base = i830_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i845_stolen_funcs = {
+	.base = i845_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i85x_stolen_funcs = {
+	.base = i85x_stolen_base,
+	.size = gen3_stolen_size,
+};
+
+static const struct intel_stolen_funcs i865_stolen_funcs = {
+	.base = i865_stolen_base,
+	.size = gen3_stolen_size,
+};
+
 static const struct intel_stolen_funcs gen3_stolen_funcs = {
 	.base = intel_stolen_base,
 	.size = gen3_stolen_size,
@@ -345,6 +473,10 @@ static const struct intel_stolen_funcs gen8_stolen_funcs = {
 };
 
 static struct pci_device_id intel_stolen_ids[] __initdata = {
+	INTEL_I830_IDS(&i830_stolen_funcs),
+	INTEL_I845G_IDS(&i845_stolen_funcs),
+	INTEL_I85X_IDS(&i85x_stolen_funcs),
+	INTEL_I865G_IDS(&i865_stolen_funcs),
 	INTEL_I915G_IDS(&gen3_stolen_funcs),
 	INTEL_I915GM_IDS(&gen3_stolen_funcs),
 	INTEL_I945G_IDS(&gen3_stolen_funcs),
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 97d5497..595f85c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -56,6 +56,12 @@ extern bool i915_gpu_turbo_disable(void);
 
 #define I830_GMCH_CTRL			0x52
 
+#define I830_GMCH_GMS_MASK		0x70
+#define I830_GMCH_GMS_LOCAL		0x10
+#define I830_GMCH_GMS_STOLEN_512	0x20
+#define I830_GMCH_GMS_STOLEN_1024	0x30
+#define I830_GMCH_GMS_STOLEN_8192	0x40
+
 #define I855_GMCH_GMS_MASK		0xF0
 #define I855_GMCH_GMS_STOLEN_0M		0x0
 #define I855_GMCH_GMS_STOLEN_1M		(0x1 << 4)
@@ -72,4 +78,18 @@ extern bool i915_gpu_turbo_disable(void);
 #define INTEL_GMCH_GMS_STOLEN_224M	(0xc << 4)
 #define INTEL_GMCH_GMS_STOLEN_352M	(0xd << 4)
 
+#define I830_DRB3		0x63
+#define I85X_DRB3		0x43
+#define I865_TOUD		0xc4
+
+#define I830_ESMRAMC		0x91
+#define I845_ESMRAMC		0x9e
+#define I85X_ESMRAMC		0x61
+#define    TSEG_ENABLE		(1 << 0)
+#define    I830_TSEG_SIZE_512K	(0 << 1)
+#define    I830_TSEG_SIZE_1M	(1 << 1)
+#define    I845_TSEG_SIZE_MASK	(3 << 1)
+#define    I845_TSEG_SIZE_512K	(2 << 1)
+#define    I845_TSEG_SIZE_1M	(3 << 1)
+
 #endif				/* _I915_DRM_H_ */
-- 
1.8.3.2


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
@ 2014-01-07 15:28     ` ville.syrjala
  0 siblings, 0 replies; 28+ messages in thread
From: ville.syrjala @ 2014-01-07 15:28 UTC (permalink / raw)
  To: intel-gfx; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar, x86, H. Peter Anvin

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 830 and 855 machines, and so far everything
looks peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 arch/x86/kernel/early-quirks.c | 132 +++++++++++++++++++++++++++++++++++++++++
 include/drm/i915_drm.h         |  20 +++++++
 2 files changed, 152 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fddd4d0..5218dd2 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -247,6 +247,114 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
 #define MB(x)	(KB (KB (x)))
 #define GB(x)	(MB (KB (x)))
 
+static size_t __init i830_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	if (tmp & I830_TSEG_SIZE_1M)
+		return MB(1);
+	else
+		return KB(512);
+}
+
+static size_t __init i845_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	switch (tmp & I845_TSEG_SIZE_MASK) {
+	case I845_TSEG_SIZE_512K:
+		return KB(512);
+	case I845_TSEG_SIZE_1M:
+		return MB(1);
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+}
+
+static size_t __init i85x_tseg_size(void)
+{
+	u8 tmp = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
+
+	if (!(tmp & TSEG_ENABLE))
+		return 0;
+
+	return MB(1);
+}
+
+static size_t __init i830_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
+}
+
+static size_t __init i85x_mem_size(void)
+{
+	return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
+}
+
+/*
+ * On 830/845/85x the stolen memory base isn't available in any
+ * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
+ */
+static u32 __init i830_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i830_tseg_size() - stolen_size;
+}
+
+static u32 __init i845_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i830_mem_size() - i845_tseg_size() - stolen_size;
+}
+
+static u32 __init i85x_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	return i85x_mem_size() - i85x_tseg_size() - stolen_size;
+}
+
+static u32 __init i865_stolen_base(int num, int slot, int func, size_t stolen_size)
+{
+	/*
+	 * FIXME is the graphics stolen memory region
+	 * always at TOUD? Ie. is it always the last
+	 * one to be allocated by the BIOS?
+	 */
+	return read_pci_config_16(0, 0, 0, I865_TOUD) << 16;
+}
+
+static size_t __init i830_stolen_size(int num, int slot, int func)
+{
+	size_t stolen_size;
+	u16 gmch_ctrl;
+
+	gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
+
+	switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
+	case I830_GMCH_GMS_STOLEN_512:
+		stolen_size = KB(512);
+		break;
+	case I830_GMCH_GMS_STOLEN_1024:
+		stolen_size = MB(1);
+		break;
+	case I830_GMCH_GMS_STOLEN_8192:
+		stolen_size = MB(8);
+		break;
+	case I830_GMCH_GMS_LOCAL:
+		/* local memory isn't part of the normal address space */
+		stolen_size = 0;
+		break;
+	default:
+		return 0;
+	}
+
+	return stolen_size;
+}
+
 static size_t __init gen3_stolen_size(int num, int slot, int func)
 {
 	size_t stolen_size;
@@ -329,6 +437,26 @@ struct intel_stolen_funcs {
 	u32 (*base)(int num, int slot, int func, size_t size);
 };
 
+static const struct intel_stolen_funcs i830_stolen_funcs = {
+	.base = i830_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i845_stolen_funcs = {
+	.base = i845_stolen_base,
+	.size = i830_stolen_size,
+};
+
+static const struct intel_stolen_funcs i85x_stolen_funcs = {
+	.base = i85x_stolen_base,
+	.size = gen3_stolen_size,
+};
+
+static const struct intel_stolen_funcs i865_stolen_funcs = {
+	.base = i865_stolen_base,
+	.size = gen3_stolen_size,
+};
+
 static const struct intel_stolen_funcs gen3_stolen_funcs = {
 	.base = intel_stolen_base,
 	.size = gen3_stolen_size,
@@ -345,6 +473,10 @@ static const struct intel_stolen_funcs gen8_stolen_funcs = {
 };
 
 static struct pci_device_id intel_stolen_ids[] __initdata = {
+	INTEL_I830_IDS(&i830_stolen_funcs),
+	INTEL_I845G_IDS(&i845_stolen_funcs),
+	INTEL_I85X_IDS(&i85x_stolen_funcs),
+	INTEL_I865G_IDS(&i865_stolen_funcs),
 	INTEL_I915G_IDS(&gen3_stolen_funcs),
 	INTEL_I915GM_IDS(&gen3_stolen_funcs),
 	INTEL_I945G_IDS(&gen3_stolen_funcs),
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 97d5497..595f85c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -56,6 +56,12 @@ extern bool i915_gpu_turbo_disable(void);
 
 #define I830_GMCH_CTRL			0x52
 
+#define I830_GMCH_GMS_MASK		0x70
+#define I830_GMCH_GMS_LOCAL		0x10
+#define I830_GMCH_GMS_STOLEN_512	0x20
+#define I830_GMCH_GMS_STOLEN_1024	0x30
+#define I830_GMCH_GMS_STOLEN_8192	0x40
+
 #define I855_GMCH_GMS_MASK		0xF0
 #define I855_GMCH_GMS_STOLEN_0M		0x0
 #define I855_GMCH_GMS_STOLEN_1M		(0x1 << 4)
@@ -72,4 +78,18 @@ extern bool i915_gpu_turbo_disable(void);
 #define INTEL_GMCH_GMS_STOLEN_224M	(0xc << 4)
 #define INTEL_GMCH_GMS_STOLEN_352M	(0xd << 4)
 
+#define I830_DRB3		0x63
+#define I85X_DRB3		0x43
+#define I865_TOUD		0xc4
+
+#define I830_ESMRAMC		0x91
+#define I845_ESMRAMC		0x9e
+#define I85X_ESMRAMC		0x61
+#define    TSEG_ENABLE		(1 << 0)
+#define    I830_TSEG_SIZE_512K	(0 << 1)
+#define    I830_TSEG_SIZE_1M	(1 << 1)
+#define    I845_TSEG_SIZE_MASK	(3 << 1)
+#define    I845_TSEG_SIZE_512K	(2 << 1)
+#define    I845_TSEG_SIZE_1M	(3 << 1)
+
 #endif				/* _I915_DRM_H_ */
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v3 6/6] drm/i915: Determine the stolen memory base address on gen2
  2013-12-03 15:49 ` [PATCH v2 6/6] drm/i915: Determine the stolen memory base address on gen2 ville.syrjala
@ 2014-01-07 15:28   ` ville.syrjala
  2014-01-10 13:31     ` [PATCH v4 " ville.syrjala
  0 siblings, 1 reply; 28+ messages in thread
From: ville.syrjala @ 2014-01-07 15:28 UTC (permalink / raw)
  To: intel-gfx

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 830 and 855 machines, and so far everything
looks peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830

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

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 7b2fe3e..3850228 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -30,6 +30,9 @@
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
 
+#define KB(x) ((x) * 1024)
+#define MB(x) (KB(x) * 1024)
+
 /*
  * The BIOS typically reserves some of the system's memory for the exclusive
  * use of the integrated graphics. This memory is no longer available for
@@ -51,24 +54,90 @@ 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.
+	 *
+	 * On 865 we just check the TOUD register.
+	 *
+	 * On 830/845/85x the stolen memory base isn't available in any
+	 * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
 	 *
-	 * XXX However gen2 requires an unavailable symbol.
 	 */
 	base = 0;
 	if (INTEL_INFO(dev)->gen >= 3) {
 		/* Read Graphics Base of Stolen Memory directly */
 		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
+	} else if (IS_I865G(dev)) {
+		u16 toud = 0;
+
+		/*
+		 * FIXME is the graphics stolen memory region
+		 * always at TOUD? Ie. is it always the last
+		 * one to be allocated by the BIOS?
+		 */
+		pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I865_TOUD, &toud);
+
+		base = toud << 16;
+	} else if (IS_I85X(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0), I85X_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE)
+			tseg_size = MB(1);
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 1),
+					 I85X_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
+	} if (IS_845G(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I845_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE) {
+			switch (tmp & I845_TSEG_SIZE_MASK) {
+			case I845_TSEG_SIZE_512K:
+				tseg_size = KB(512);
+				break;
+			case I845_TSEG_SIZE_1M:
+				tseg_size = MB(1);
+				break;
+			}
+		}
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
+	} else if (IS_I830(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE) {
+			if (tmp & I830_TSEG_SIZE_1M)
+				tseg_size = MB(1);
+			else
+				tseg_size = KB(512);
+		}
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
 	}
 
 	if (base == 0)
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 6/6] drm/i915: Determine the stolen memory base address on gen2
  2014-01-07 15:28   ` [PATCH v3 " ville.syrjala
@ 2014-01-10 13:31     ` ville.syrjala
  2014-01-10 15:11       ` Jani Nikula
  0 siblings, 1 reply; 28+ messages in thread
From: ville.syrjala @ 2014-01-10 13:31 UTC (permalink / raw)
  To: intel-gfx

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

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 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.

After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.

Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.

865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.

I tested this on the my 830 and 855 machines, and so far everything
looks peachy.

v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830
v4: Add missing 'else' (Chris)

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

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 7b2fe3e..169a55d 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -30,6 +30,9 @@
 #include <drm/i915_drm.h>
 #include "i915_drv.h"
 
+#define KB(x) ((x) * 1024)
+#define MB(x) (KB(x) * 1024)
+
 /*
  * The BIOS typically reserves some of the system's memory for the exclusive
  * use of the integrated graphics. This memory is no longer available for
@@ -51,24 +54,91 @@ 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.
+	 *
+	 * On 865 we just check the TOUD register.
+	 *
+	 * On 830/845/85x the stolen memory base isn't available in any
+	 * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
 	 *
-	 * XXX However gen2 requires an unavailable symbol.
 	 */
 	base = 0;
 	if (INTEL_INFO(dev)->gen >= 3) {
 		/* Read Graphics Base of Stolen Memory directly */
 		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
+	} else if (IS_I865G(dev)) {
+		u16 toud = 0;
+
+		/*
+		 * FIXME is the graphics stolen memory region
+		 * always at TOUD? Ie. is it always the last
+		 * one to be allocated by the BIOS?
+		 */
+		pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I865_TOUD, &toud);
+
+		base = toud << 16;
+	} else if (IS_I85X(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I85X_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE)
+			tseg_size = MB(1);
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 1),
+					 I85X_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
+	} else if (IS_845G(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I845_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE) {
+			switch (tmp & I845_TSEG_SIZE_MASK) {
+			case I845_TSEG_SIZE_512K:
+				tseg_size = KB(512);
+				break;
+			case I845_TSEG_SIZE_1M:
+				tseg_size = MB(1);
+				break;
+			}
+		}
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
+	} else if (IS_I830(dev)) {
+		u32 tseg_size = 0;
+		u32 tom;
+		u8 tmp;
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_ESMRAMC, &tmp);
+
+		if (tmp & TSEG_ENABLE) {
+			if (tmp & I830_TSEG_SIZE_1M)
+				tseg_size = MB(1);
+			else
+				tseg_size = KB(512);
+		}
+
+		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+					 I830_DRB3, &tmp);
+		tom = tmp * MB(32);
+
+		base = tom - tseg_size - dev_priv->gtt.stolen_size;
 	}
 
 	if (base == 0)
-- 
1.8.3.2

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 6/6] drm/i915: Determine the stolen memory base address on gen2
  2014-01-10 13:31     ` [PATCH v4 " ville.syrjala
@ 2014-01-10 15:11       ` Jani Nikula
  0 siblings, 0 replies; 28+ messages in thread
From: Jani Nikula @ 2014-01-10 15:11 UTC (permalink / raw)
  To: ville.syrjala, intel-gfx

On Fri, 10 Jan 2014, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> There isn't an explicit stolen memory base register on gen2.
> Some old comment in the i915 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.
>
> After some more digging through chipset documentation, I've determined
> the BIOS first allocates space for something called TSEG (something to
> do with SMM) from the top of memory, and then it allocates the graphics
> stolen memory below that. Accordind to the chipset documentation TSEG
> has a fixed size of 1MB on 855. So that explains the top 1MB in the
> e820 region. And it also confirms that the GTT entries are in fact at
> the end of the the stolen memory region.
>
> Derive the stolen memory base address on gen2 the same as the BIOS does
> (TOM-TSEG_SIZE-stolen_size). There are a few differences between the
> registers on various gen2 chipsets, so a few different codepaths are
> required.
>
> 865G is again bit more special since it seems to support enough memory
> to hit 4GB address space issues. This means the PCI allocations will
> also affect the location of the stolen memory. Fortunately there
> appears to be the TOUD register which may give us the correct answer
> directly. But the chipset docs are a bit unclear, so I'm not 100%
> sure that the graphics stolen memory is always the last thing the
> BIOS steals. Someone would need to verify it on a real system.
>
> I tested this on the my 830 and 855 machines, and so far everything
> looks peachy.
>
> v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
> v3: Fix TSEG size for 830
> v4: Add missing 'else' (Chris)
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 92 ++++++++++++++++++++++++++++++----
>  1 file changed, 81 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 7b2fe3e..169a55d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -30,6 +30,9 @@
>  #include <drm/i915_drm.h>
>  #include "i915_drv.h"
>  
> +#define KB(x) ((x) * 1024)
> +#define MB(x) (KB(x) * 1024)

Bikeshed, how about making those KiB and MiB and moving to intel_drv.h
next to KHz and MHz?

BR,
Jani.


> +
>  /*
>   * The BIOS typically reserves some of the system's memory for the exclusive
>   * use of the integrated graphics. This memory is no longer available for
> @@ -51,24 +54,91 @@ 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.
> +	 *
> +	 * On 865 we just check the TOUD register.
> +	 *
> +	 * On 830/845/85x the stolen memory base isn't available in any
> +	 * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
>  	 *
> -	 * XXX However gen2 requires an unavailable symbol.
>  	 */
>  	base = 0;
>  	if (INTEL_INFO(dev)->gen >= 3) {
>  		/* Read Graphics Base of Stolen Memory directly */
>  		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
> +	} else if (IS_I865G(dev)) {
> +		u16 toud = 0;
> +
> +		/*
> +		 * FIXME is the graphics stolen memory region
> +		 * always at TOUD? Ie. is it always the last
> +		 * one to be allocated by the BIOS?
> +		 */
> +		pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
> +					 I865_TOUD, &toud);
> +
> +		base = toud << 16;
> +	} else if (IS_I85X(dev)) {
> +		u32 tseg_size = 0;
> +		u32 tom;
> +		u8 tmp;
> +
> +		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
> +					 I85X_ESMRAMC, &tmp);
> +
> +		if (tmp & TSEG_ENABLE)
> +			tseg_size = MB(1);
> +
> +		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 1),
> +					 I85X_DRB3, &tmp);
> +		tom = tmp * MB(32);
> +
> +		base = tom - tseg_size - dev_priv->gtt.stolen_size;
> +	} else if (IS_845G(dev)) {
> +		u32 tseg_size = 0;
> +		u32 tom;
> +		u8 tmp;
> +
> +		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
> +					 I845_ESMRAMC, &tmp);
> +
> +		if (tmp & TSEG_ENABLE) {
> +			switch (tmp & I845_TSEG_SIZE_MASK) {
> +			case I845_TSEG_SIZE_512K:
> +				tseg_size = KB(512);
> +				break;
> +			case I845_TSEG_SIZE_1M:
> +				tseg_size = MB(1);
> +				break;
> +			}
> +		}
> +
> +		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
> +					 I830_DRB3, &tmp);
> +		tom = tmp * MB(32);
> +
> +		base = tom - tseg_size - dev_priv->gtt.stolen_size;
> +	} else if (IS_I830(dev)) {
> +		u32 tseg_size = 0;
> +		u32 tom;
> +		u8 tmp;
> +
> +		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
> +					 I830_ESMRAMC, &tmp);
> +
> +		if (tmp & TSEG_ENABLE) {
> +			if (tmp & I830_TSEG_SIZE_1M)
> +				tseg_size = MB(1);
> +			else
> +				tseg_size = KB(512);
> +		}
> +
> +		pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
> +					 I830_DRB3, &tmp);
> +		tom = tmp * MB(32);
> +
> +		base = tom - tseg_size - dev_priv->gtt.stolen_size;
>  	}
>  
>  	if (base == 0)
> -- 
> 1.8.3.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2014-01-07 15:28     ` ville.syrjala
@ 2014-02-04 12:47       ` Ville Syrjälä
  -1 siblings, 0 replies; 28+ messages in thread
From: Ville Syrjälä @ 2014-02-04 12:47 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel

Hi x86 folks,

Ping on getting the gen2 stolen memory early quirk patches into the x86
tree.

>From our side Daniel and Chris both seemed happy with them, so I'd like
to get them in at some point.

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
@ 2014-02-04 12:47       ` Ville Syrjälä
  0 siblings, 0 replies; 28+ messages in thread
From: Ville Syrjälä @ 2014-02-04 12:47 UTC (permalink / raw)
  To: intel-gfx; +Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel

Hi x86 folks,

Ping on getting the gen2 stolen memory early quirk patches into the x86
tree.

From our side Daniel and Chris both seemed happy with them, so I'd like
to get them in at some point.

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2014-02-04 12:47       ` Ville Syrjälä
  (?)
@ 2014-02-04 13:02       ` Daniel Vetter
  2014-02-05  5:41           ` Ingo Molnar
  -1 siblings, 1 reply; 28+ messages in thread
From: Daniel Vetter @ 2014-02-04 13:02 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: intel-gfx, linux-kernel, Thomas Gleixner, Ingo Molnar, x86,
	H. Peter Anvin

On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote:
> Hi x86 folks,
> 
> Ping on getting the gen2 stolen memory early quirk patches into the x86
> tree.
> 
> From our side Daniel and Chris both seemed happy with them, so I'd like
> to get them in at some point.

Yup, I think this is ready for 3.15. And since there's no direct depency
really between the i915 parts and the x86 early reserve stuff they can go
both in through relevant trees - i915 will simply fail the stolen setup if
the range isn't properly reserved.

A stable branch somewhere would be good though so that I can pull it into
our integration tree for testing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
  2014-02-04 13:02       ` [Intel-gfx] " Daniel Vetter
@ 2014-02-05  5:41           ` Ingo Molnar
  0 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2014-02-05  5:41 UTC (permalink / raw)
  To: Ville Syrjälä,
	intel-gfx, linux-kernel, Thomas Gleixner, Ingo Molnar, x86,
	H. Peter Anvin


* Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote:
> > Hi x86 folks,
> > 
> > Ping on getting the gen2 stolen memory early quirk patches into 
> > the x86 tree.
> > 
> > From our side Daniel and Chris both seemed happy with them, so I'd 
> > like to get them in at some point.
> 
> Yup, I think this is ready for 3.15. And since there's no direct 
> depency really between the i915 parts and the x86 early reserve 
> stuff they can go both in through relevant trees - i915 will simply 
> fail the stolen setup if the range isn't properly reserved.
> 
> A stable branch somewhere would be good though so that I can pull it 
> into our integration tree for testing.

Please post the x86 bits separately in a standalone series, if they 
can and should be applied standalone.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
@ 2014-02-05  5:41           ` Ingo Molnar
  0 siblings, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2014-02-05  5:41 UTC (permalink / raw)
  To: Ville Syrjälä,
	intel-gfx, linux-kernel, Thomas Gleixner, Ingo Molnar, x86,
	H. Peter Anvin


* Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote:
> > Hi x86 folks,
> > 
> > Ping on getting the gen2 stolen memory early quirk patches into 
> > the x86 tree.
> > 
> > From our side Daniel and Chris both seemed happy with them, so I'd 
> > like to get them in at some point.
> 
> Yup, I think this is ready for 3.15. And since there's no direct 
> depency really between the i915 parts and the x86 early reserve 
> stuff they can go both in through relevant trees - i915 will simply 
> fail the stolen setup if the range isn't properly reserved.
> 
> A stable branch somewhere would be good though so that I can pull it 
> into our integration tree for testing.

Please post the x86 bits separately in a standalone series, if they 
can and should be applied standalone.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v2 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory
  2013-12-03 15:49 ` [PATCH 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory ville.syrjala
@ 2014-06-05 17:02   ` ville.syrjala
  2014-06-30 10:25     ` Jani Nikula
  0 siblings, 1 reply; 28+ messages in thread
From: ville.syrjala @ 2014-06-05 17:02 UTC (permalink / raw)
  To: intel-gfx

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

On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.

v2: Deal with gen4 36 bit physical address

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 44 ++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/i915_reg.h        |  3 +++
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 62ef55b..7465ab0 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -74,6 +74,50 @@ static unsigned long i915_stolen_to_physical(struct drm_device *dev)
 	if (base == 0)
 		return 0;
 
+	/* make sure we don't clobber the GTT if it's within stolen memory */
+	if (INTEL_INFO(dev)->gen <= 4 && !IS_G33(dev) && !IS_G4X(dev)) {
+		struct {
+			u32 start, end;
+		} stolen[2] = {
+			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
+			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
+		};
+		u64 gtt_start, gtt_end;
+
+		gtt_start = I915_READ(PGTBL_CTL);
+		if (IS_GEN4(dev))
+			gtt_start = (gtt_start & PGTBL_ADDRESS_LO_MASK) |
+				(gtt_start & PGTBL_ADDRESS_HI_MASK) << 28;
+		else
+			gtt_start &= PGTBL_ADDRESS_LO_MASK;
+		gtt_end = gtt_start + gtt_total_entries(dev_priv->gtt) * 4;
+
+		if (gtt_start >= stolen[0].start && gtt_start < stolen[0].end)
+			stolen[0].end = gtt_start;
+		if (gtt_end > stolen[1].start && gtt_end <= stolen[1].end)
+			stolen[1].start = gtt_end;
+
+		/* pick the larger of the two chunks */
+		if (stolen[0].end - stolen[0].start >
+		    stolen[1].end - stolen[1].start) {
+			base = stolen[0].start;
+			dev_priv->gtt.stolen_size = stolen[0].end - stolen[0].start;
+		} else {
+			base = stolen[1].start;
+			dev_priv->gtt.stolen_size = stolen[1].end - stolen[1].start;
+		}
+
+		if (stolen[0].start != stolen[1].start ||
+		    stolen[0].end != stolen[1].end) {
+			DRM_DEBUG_KMS("GTT within stolen memory at 0x%llx-0x%llx\n",
+				      (unsigned long long) gtt_start,
+				      (unsigned long long) gtt_end - 1);
+			DRM_DEBUG_KMS("Stolen memory adjusted to 0x%x-0x%x\n",
+				      base, base + (u32) dev_priv->gtt.stolen_size - 1);
+		}
+	}
+
+
 	/* Verify that nothing else uses this physical address. Stolen
 	 * memory should be reserved by the BIOS and hidden from the
 	 * kernel. So if the region is already marked as busy, something
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 247be2a..619924b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -978,6 +978,9 @@ enum punit_power_well {
 /*
  * Instruction and interrupt control regs
  */
+#define PGTBL_CTL	0x02020
+#define   PGTBL_ADDRESS_LO_MASK	0xfffff000 /* bits [31:12] */
+#define   PGTBL_ADDRESS_HI_MASK	0x000000f0 /* bits [35:32] (gen4) */
 #define PGTBL_ER	0x02024
 #define RENDER_RING_BASE	0x02000
 #define BSD_RING_BASE		0x04000
-- 
1.8.5.5

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

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory
  2014-06-05 17:02   ` [PATCH v2 " ville.syrjala
@ 2014-06-30 10:25     ` Jani Nikula
  2014-07-07  9:02       ` Daniel Vetter
  0 siblings, 1 reply; 28+ messages in thread
From: Jani Nikula @ 2014-06-30 10:25 UTC (permalink / raw)
  To: ville.syrjala, intel-gfx

On Thu, 05 Jun 2014, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> On most gen2-4 platforms the GTT can be (or maybe always is?)
> inside the stolen memory region. If that's the case, reduce the
> size of the stolen memory appropriately to make make sure we
> don't clobber the GTT.
>
> v2: Deal with gen4 36 bit physical address

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151

> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 44 ++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/i915_reg.h        |  3 +++
>  2 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 62ef55b..7465ab0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -74,6 +74,50 @@ static unsigned long i915_stolen_to_physical(struct drm_device *dev)
>  	if (base == 0)
>  		return 0;
>  
> +	/* make sure we don't clobber the GTT if it's within stolen memory */
> +	if (INTEL_INFO(dev)->gen <= 4 && !IS_G33(dev) && !IS_G4X(dev)) {
> +		struct {
> +			u32 start, end;
> +		} stolen[2] = {
> +			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
> +			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
> +		};
> +		u64 gtt_start, gtt_end;
> +
> +		gtt_start = I915_READ(PGTBL_CTL);
> +		if (IS_GEN4(dev))
> +			gtt_start = (gtt_start & PGTBL_ADDRESS_LO_MASK) |
> +				(gtt_start & PGTBL_ADDRESS_HI_MASK) << 28;
> +		else
> +			gtt_start &= PGTBL_ADDRESS_LO_MASK;
> +		gtt_end = gtt_start + gtt_total_entries(dev_priv->gtt) * 4;
> +
> +		if (gtt_start >= stolen[0].start && gtt_start < stolen[0].end)
> +			stolen[0].end = gtt_start;
> +		if (gtt_end > stolen[1].start && gtt_end <= stolen[1].end)
> +			stolen[1].start = gtt_end;
> +
> +		/* pick the larger of the two chunks */
> +		if (stolen[0].end - stolen[0].start >
> +		    stolen[1].end - stolen[1].start) {
> +			base = stolen[0].start;
> +			dev_priv->gtt.stolen_size = stolen[0].end - stolen[0].start;
> +		} else {
> +			base = stolen[1].start;
> +			dev_priv->gtt.stolen_size = stolen[1].end - stolen[1].start;
> +		}
> +
> +		if (stolen[0].start != stolen[1].start ||
> +		    stolen[0].end != stolen[1].end) {
> +			DRM_DEBUG_KMS("GTT within stolen memory at 0x%llx-0x%llx\n",
> +				      (unsigned long long) gtt_start,
> +				      (unsigned long long) gtt_end - 1);
> +			DRM_DEBUG_KMS("Stolen memory adjusted to 0x%x-0x%x\n",
> +				      base, base + (u32) dev_priv->gtt.stolen_size - 1);
> +		}
> +	}
> +
> +
>  	/* Verify that nothing else uses this physical address. Stolen
>  	 * memory should be reserved by the BIOS and hidden from the
>  	 * kernel. So if the region is already marked as busy, something
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 247be2a..619924b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -978,6 +978,9 @@ enum punit_power_well {
>  /*
>   * Instruction and interrupt control regs
>   */
> +#define PGTBL_CTL	0x02020
> +#define   PGTBL_ADDRESS_LO_MASK	0xfffff000 /* bits [31:12] */
> +#define   PGTBL_ADDRESS_HI_MASK	0x000000f0 /* bits [35:32] (gen4) */
>  #define PGTBL_ER	0x02024
>  #define RENDER_RING_BASE	0x02000
>  #define BSD_RING_BASE		0x04000
> -- 
> 1.8.5.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory
  2014-06-30 10:25     ` Jani Nikula
@ 2014-07-07  9:02       ` Daniel Vetter
  0 siblings, 0 replies; 28+ messages in thread
From: Daniel Vetter @ 2014-07-07  9:02 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

On Mon, Jun 30, 2014 at 01:25:29PM +0300, Jani Nikula wrote:
> On Thu, 05 Jun 2014, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > On most gen2-4 platforms the GTT can be (or maybe always is?)
> > inside the stolen memory region. If that's the case, reduce the
> > size of the stolen memory appropriately to make make sure we
> > don't clobber the GTT.
> >
> > v2: Deal with gen4 36 bit physical address
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151

Picked up for -fixes (with Chris' irc-ack and cc: stable), thanks for the
patch.
-Daniel

> 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 44 ++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/i915_reg.h        |  3 +++
> >  2 files changed, 47 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 62ef55b..7465ab0 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -74,6 +74,50 @@ static unsigned long i915_stolen_to_physical(struct drm_device *dev)
> >  	if (base == 0)
> >  		return 0;
> >  
> > +	/* make sure we don't clobber the GTT if it's within stolen memory */
> > +	if (INTEL_INFO(dev)->gen <= 4 && !IS_G33(dev) && !IS_G4X(dev)) {
> > +		struct {
> > +			u32 start, end;
> > +		} stolen[2] = {
> > +			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
> > +			{ .start = base, .end = base + dev_priv->gtt.stolen_size, },
> > +		};
> > +		u64 gtt_start, gtt_end;
> > +
> > +		gtt_start = I915_READ(PGTBL_CTL);
> > +		if (IS_GEN4(dev))
> > +			gtt_start = (gtt_start & PGTBL_ADDRESS_LO_MASK) |
> > +				(gtt_start & PGTBL_ADDRESS_HI_MASK) << 28;
> > +		else
> > +			gtt_start &= PGTBL_ADDRESS_LO_MASK;
> > +		gtt_end = gtt_start + gtt_total_entries(dev_priv->gtt) * 4;
> > +
> > +		if (gtt_start >= stolen[0].start && gtt_start < stolen[0].end)
> > +			stolen[0].end = gtt_start;
> > +		if (gtt_end > stolen[1].start && gtt_end <= stolen[1].end)
> > +			stolen[1].start = gtt_end;
> > +
> > +		/* pick the larger of the two chunks */
> > +		if (stolen[0].end - stolen[0].start >
> > +		    stolen[1].end - stolen[1].start) {
> > +			base = stolen[0].start;
> > +			dev_priv->gtt.stolen_size = stolen[0].end - stolen[0].start;
> > +		} else {
> > +			base = stolen[1].start;
> > +			dev_priv->gtt.stolen_size = stolen[1].end - stolen[1].start;
> > +		}
> > +
> > +		if (stolen[0].start != stolen[1].start ||
> > +		    stolen[0].end != stolen[1].end) {
> > +			DRM_DEBUG_KMS("GTT within stolen memory at 0x%llx-0x%llx\n",
> > +				      (unsigned long long) gtt_start,
> > +				      (unsigned long long) gtt_end - 1);
> > +			DRM_DEBUG_KMS("Stolen memory adjusted to 0x%x-0x%x\n",
> > +				      base, base + (u32) dev_priv->gtt.stolen_size - 1);
> > +		}
> > +	}
> > +
> > +
> >  	/* Verify that nothing else uses this physical address. Stolen
> >  	 * memory should be reserved by the BIOS and hidden from the
> >  	 * kernel. So if the region is already marked as busy, something
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index 247be2a..619924b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -978,6 +978,9 @@ enum punit_power_well {
> >  /*
> >   * Instruction and interrupt control regs
> >   */
> > +#define PGTBL_CTL	0x02020
> > +#define   PGTBL_ADDRESS_LO_MASK	0xfffff000 /* bits [31:12] */
> > +#define   PGTBL_ADDRESS_HI_MASK	0x000000f0 /* bits [35:32] (gen4) */
> >  #define PGTBL_ER	0x02024
> >  #define RENDER_RING_BASE	0x02000
> >  #define BSD_RING_BASE		0x04000
> > -- 
> > 1.8.5.5
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2014-07-07  9:02 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-03 15:49 [PATCH 0/6] drm/i915: Gen2 stolen/local memory support (v2) ville.syrjala
2013-12-03 15:49 ` [PATCH 1/6] x86: Add vfunc for Intel graphics stolen memory base address ville.syrjala
2013-12-03 15:49   ` ville.syrjala
2013-12-03 15:49 ` [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms ville.syrjala
2013-12-03 15:49   ` ville.syrjala
2013-12-04  9:08   ` Ingo Molnar
2013-12-04  9:08     ` Ingo Molnar
2013-12-04 15:12     ` Ville Syrjälä
2013-12-04 15:12       ` Ville Syrjälä
2013-12-04 15:15       ` Ingo Molnar
2014-01-07 15:28   ` [PATCH v3 " ville.syrjala
2014-01-07 15:28     ` ville.syrjala
2014-02-04 12:47     ` Ville Syrjälä
2014-02-04 12:47       ` Ville Syrjälä
2014-02-04 13:02       ` [Intel-gfx] " Daniel Vetter
2014-02-05  5:41         ` Ingo Molnar
2014-02-05  5:41           ` Ingo Molnar
2013-12-03 15:49 ` [PATCH 3/6] x86: Print the Intel graphcis stolen memory range ville.syrjala
2013-12-03 15:49   ` ville.syrjala
2013-12-03 15:49 ` [PATCH 4/6] intel-gtt: Report stolen_size as 0 when local memory is present ville.syrjala
2013-12-03 15:49 ` [PATCH 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory ville.syrjala
2014-06-05 17:02   ` [PATCH v2 " ville.syrjala
2014-06-30 10:25     ` Jani Nikula
2014-07-07  9:02       ` Daniel Vetter
2013-12-03 15:49 ` [PATCH v2 6/6] drm/i915: Determine the stolen memory base address on gen2 ville.syrjala
2014-01-07 15:28   ` [PATCH v3 " ville.syrjala
2014-01-10 13:31     ` [PATCH v4 " ville.syrjala
2014-01-10 15:11       ` Jani Nikula

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.