Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On Thu, Jul 25, 2013 at 09:37:49AM -0700, Jesse Barnes wrote:
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process. On some systems, MMIO space is allocated on top, despite
the efforts of the RAM buffer approach, which simply rounds memory
boundaries up to 64M to try to catch space that may decode as RAM and so
is not suitable for MMIO.
v2: use read_pci_config for 32 bit reads instead of adding a new one
(Chris)
add gen6 stolen size function (Chris)
use a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Our QA seems to be happy with this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66844
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66726
Tested-by: lu hua huax...@intel.com
Cheers, Daniel
---
arch/x86/kernel/early-quirks.c | 158
+++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..bff8a6f 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -12,6 +12,7 @@
#include linux/pci.h
#include linux/acpi.h
#include linux/pci_ids.h
+#include drm/i915_drm.h
#include asm/pci-direct.h
#include asm/dma.h
#include asm/io_apic.h
@@ -208,6 +209,161 @@ static void __init intel_remapping_check(int num, int
slot, int func)
}
+/*
+ * Systems with Intel graphics controllers set aside memory exclusively
+ * for gfx driver use. This memory is not marked in the E820 as reserved
+ * or as RAM, and so is subject to overlap from E820 manipulation later
+ * in the boot process. On some systems, MMIO space is allocated on top,
+ * despite the efforts of the RAM buffer approach, which simply rounds
+ * memory boundaries up to 64M to try to catch space that may decode
+ * as RAM and so is not suitable for MMIO.
+ *
+ * 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)
+{
+ u32 base;
+
+ /*
+ * 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.
+ */
+ base = read_pci_config(num, slot, func, 0x5c);
+ base = ~((120) - 1);
+
+ return base;
+}
+
+#define KB(x)((x) * 1024)
+#define MB(x)(KB (KB (x)))
+#define GB(x)(MB (KB (x)))
+
+static size_t __init gen3_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 I855_GMCH_GMS_MASK) {
+ case I855_GMCH_GMS_STOLEN_1M:
+ stolen_size = MB(1);
+ break;
+ case I855_GMCH_GMS_STOLEN_4M:
+ stolen_size = MB(4);
+ break;
+ case I855_GMCH_GMS_STOLEN_8M:
+ stolen_size = MB(8);
+ break;
+ case I855_GMCH_GMS_STOLEN_16M:
+ stolen_size = MB(16);
+ break;
+ case I855_GMCH_GMS_STOLEN_32M:
+ stolen_size = MB(32);
+ break;
+ case I915_GMCH_GMS_STOLEN_48M:
+ stolen_size = MB(48);
+ break;
+ case I915_GMCH_GMS_STOLEN_64M:
+ stolen_size = MB(64);
+ break;
+ case G33_GMCH_GMS_STOLEN_128M:
+ stolen_size = MB(128);
+ break;
+ case G33_GMCH_GMS_STOLEN_256M:
+ stolen_size = MB(256);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_96M:
+ stolen_size = MB(96);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_160M:
+ stolen_size = MB(160);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_224M:
+ stolen_size = MB(224);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_352M:
+ stolen_size = MB(352);
+ break;
+ default:
+ stolen_size = 0;
+ break;
+ }
+
+ return stolen_size;
+}
+
+static size_t __init gen6_stolen_size(int num, int slot, int func)
+{
+ u16 gmch_ctrl;
+
+ gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
+ gmch_ctrl = SNB_GMCH_GMS_SHIFT;
+ gmch_ctrl = SNB_GMCH_GMS_MASK;
+
+ return gmch_ctrl 25; /* 32 MB units */
+}
+
+typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+static struct pci_device_id intel_stolen_ids[] __initdata = {
+ INTEL_I915G_IDS(gen3_stolen_size),
+
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On Fri, 26 Jul 2013 09:58:45 -0700 H. Peter Anvin h...@zytor.com wrote: On 07/25/2013 09:37 AM, Jesse Barnes wrote: Systems with Intel graphics controllers set aside memory exclusively for + /* +* 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. +*/ This comment makes me nervous. It isn't clear to me if it is saying: - All igfx devices has the graphics base at 0x5c, a few have it in other places, too (which doesn't matter, we can use 0x5c anyway), or - Most igfx devices have the graphics base at 0x5c, some don't, and we hope and pray we're not on one of those systems because we're not checking. I assume it is the former, but it really needs to be phrased better. I mostly copied it from the driver where we had some other ways of finding it too. For the PCI IDs listed, we can always use 0x5c. I'll fix the comment. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On 07/25/2013 09:37 AM, Jesse Barnes wrote: Systems with Intel graphics controllers set aside memory exclusively for + /* + * 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. + */ This comment makes me nervous. It isn't clear to me if it is saying: - All igfx devices has the graphics base at 0x5c, a few have it in other places, too (which doesn't matter, we can use 0x5c anyway), or - Most igfx devices have the graphics base at 0x5c, some don't, and we hope and pray we're not on one of those systems because we're not checking. I assume it is the former, but it really needs to be phrased better. -hpa ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process. On some systems, MMIO space is allocated on top, despite
the efforts of the RAM buffer approach, which simply rounds memory
boundaries up to 64M to try to catch space that may decode as RAM and so
is not suitable for MMIO.
v2: use read_pci_config for 32 bit reads instead of adding a new one
(Chris)
add gen6 stolen size function (Chris)
use a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 158
+++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..bff8a6f 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -12,6 +12,7 @@
#include linux/pci.h
#include linux/acpi.h
#include linux/pci_ids.h
+#include drm/i915_drm.h
#include asm/pci-direct.h
#include asm/dma.h
#include asm/io_apic.h
@@ -208,6 +209,161 @@ static void __init intel_remapping_check(int num, int
slot, int func)
}
+/*
+ * Systems with Intel graphics controllers set aside memory exclusively
+ * for gfx driver use. This memory is not marked in the E820 as reserved
+ * or as RAM, and so is subject to overlap from E820 manipulation later
+ * in the boot process. On some systems, MMIO space is allocated on top,
+ * despite the efforts of the RAM buffer approach, which simply rounds
+ * memory boundaries up to 64M to try to catch space that may decode
+ * as RAM and so is not suitable for MMIO.
+ *
+ * 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)
+{
+ u32 base;
+
+ /*
+ * 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.
+ */
+ base = read_pci_config(num, slot, func, 0x5c);
+ base = ~((120) - 1);
+
+ return base;
+}
+
+#define KB(x)((x) * 1024)
+#define MB(x)(KB (KB (x)))
+#define GB(x)(MB (KB (x)))
+
+static size_t __init gen3_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 I855_GMCH_GMS_MASK) {
+ case I855_GMCH_GMS_STOLEN_1M:
+ stolen_size = MB(1);
+ break;
+ case I855_GMCH_GMS_STOLEN_4M:
+ stolen_size = MB(4);
+ break;
+ case I855_GMCH_GMS_STOLEN_8M:
+ stolen_size = MB(8);
+ break;
+ case I855_GMCH_GMS_STOLEN_16M:
+ stolen_size = MB(16);
+ break;
+ case I855_GMCH_GMS_STOLEN_32M:
+ stolen_size = MB(32);
+ break;
+ case I915_GMCH_GMS_STOLEN_48M:
+ stolen_size = MB(48);
+ break;
+ case I915_GMCH_GMS_STOLEN_64M:
+ stolen_size = MB(64);
+ break;
+ case G33_GMCH_GMS_STOLEN_128M:
+ stolen_size = MB(128);
+ break;
+ case G33_GMCH_GMS_STOLEN_256M:
+ stolen_size = MB(256);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_96M:
+ stolen_size = MB(96);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_160M:
+ stolen_size = MB(160);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_224M:
+ stolen_size = MB(224);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_352M:
+ stolen_size = MB(352);
+ break;
+ default:
+ stolen_size = 0;
+ break;
+ }
+
+ return stolen_size;
+}
+
+static size_t __init gen6_stolen_size(int num, int slot, int func)
+{
+ u16 gmch_ctrl;
+
+ gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
+ gmch_ctrl = SNB_GMCH_GMS_SHIFT;
+ gmch_ctrl = SNB_GMCH_GMS_MASK;
+
+ return gmch_ctrl 25; /* 32 MB units */
+}
+
+typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+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(gen3_stolen_size),
+ INTEL_VLV_D_IDS(gen3_stolen_size),
+
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote: On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote: Two bikesheds: - Can't we give the thing a better name like Intel Graphics Stolen? Using a custom type and name seems simple enough and naturally leads it to ending up in iomem_resource. - Can't we store the iomem region somewhere so that intel-gtt.ko and i915.ko can get at it and we could drop the duplicated stolen detection code? The choice is then walking the resource list looking for our named region or reading a couple of registers. Certainly walking the iomem makes everything much clearer. -Chris diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h index bbae024..5e12db4 100644 --- a/arch/x86/include/uapi/asm/e820.h +++ b/arch/x86/include/uapi/asm/e820.h @@ -38,6 +38,7 @@ #define E820_NVS 4 #define E820_UNUSABLE 5 +#define E820_STOLEN_IGFX 6 /* * reserved RAM used by kernel itself diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index d32abea..d8f0e4f 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -149,6 +149,10 @@ static void __init e820_print_type(u32 type) case E820_UNUSABLE: printk(KERN_CONT unusable); break; + + case E820_STOLEN_IGFX: + printk(KERN_CONT Intel Graphics Stolen); + break; default: printk(KERN_CONT type %u, type); break; diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c index bff8a6f..27b6d17 100644 --- a/arch/x86/kernel/early-quirks.c +++ b/arch/x86/kernel/early-quirks.c @@ -350,18 +350,10 @@ static void __init intel_graphics_stolen(int num, int slot, int func) size = stolen_size(num, slot, func); start = intel_stolen_base(num, slot, func); if (size start) - goto found; - else - break; + e820_add_region(start, size, E820_STOLEN_IGFX); + return; } } - - /* No match or invalid data, don't bother reserving */ - return; -found: - /* Mark this space as reserved */ - e820_add_region(start, size, E820_RESERVED); - return; } #define QFLAG_APPLY_ONCE 0x1 -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On Thu, Jul 25, 2013 at 09:34:05AM +0100, Chris Wilson wrote: On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote: On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote: Two bikesheds: - Can't we give the thing a better name like Intel Graphics Stolen? Using a custom type and name seems simple enough and naturally leads it to ending up in iomem_resource. - Can't we store the iomem region somewhere so that intel-gtt.ko and i915.ko can get at it and we could drop the duplicated stolen detection code? The choice is then walking the resource list looking for our named region or reading a couple of registers. Certainly walking the iomem makes everything much clearer. Oh, I like this ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process. On some systems, MMIO space is allocated on top, despite
the efforts of the RAM buffer approach, which simply rounds memory
boundaries up to 64M to try to catch space that may decode as RAM and so
is not suitable for MMIO.
v2: use read_pci_config for 32 bit reads instead of adding a new one
(Chris)
add gen6 stolen size function (Chris)
use a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 158 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..bff8a6f 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -12,6 +12,7 @@
#include linux/pci.h
#include linux/acpi.h
#include linux/pci_ids.h
+#include drm/i915_drm.h
#include asm/pci-direct.h
#include asm/dma.h
#include asm/io_apic.h
@@ -208,6 +209,161 @@ static void __init intel_remapping_check(int num, int
slot, int func)
}
+/*
+ * Systems with Intel graphics controllers set aside memory exclusively
+ * for gfx driver use. This memory is not marked in the E820 as reserved
+ * or as RAM, and so is subject to overlap from E820 manipulation later
+ * in the boot process. On some systems, MMIO space is allocated on top,
+ * despite the efforts of the RAM buffer approach, which simply rounds
+ * memory boundaries up to 64M to try to catch space that may decode
+ * as RAM and so is not suitable for MMIO.
+ *
+ * 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)
+{
+ u32 base;
+
+ /*
+* 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.
+*/
+ base = read_pci_config(num, slot, func, 0x5c);
+ base = ~((120) - 1);
+
+ return base;
+}
+
+#define KB(x) ((x) * 1024)
+#define MB(x) (KB (KB (x)))
+#define GB(x) (MB (KB (x)))
+
+static size_t __init gen3_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 I855_GMCH_GMS_MASK) {
+ case I855_GMCH_GMS_STOLEN_1M:
+ stolen_size = MB(1);
+ break;
+ case I855_GMCH_GMS_STOLEN_4M:
+ stolen_size = MB(4);
+ break;
+ case I855_GMCH_GMS_STOLEN_8M:
+ stolen_size = MB(8);
+ break;
+ case I855_GMCH_GMS_STOLEN_16M:
+ stolen_size = MB(16);
+ break;
+ case I855_GMCH_GMS_STOLEN_32M:
+ stolen_size = MB(32);
+ break;
+ case I915_GMCH_GMS_STOLEN_48M:
+ stolen_size = MB(48);
+ break;
+ case I915_GMCH_GMS_STOLEN_64M:
+ stolen_size = MB(64);
+ break;
+ case G33_GMCH_GMS_STOLEN_128M:
+ stolen_size = MB(128);
+ break;
+ case G33_GMCH_GMS_STOLEN_256M:
+ stolen_size = MB(256);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_96M:
+ stolen_size = MB(96);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_160M:
+ stolen_size = MB(160);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_224M:
+ stolen_size = MB(224);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_352M:
+ stolen_size = MB(352);
+ break;
+ default:
+ stolen_size = 0;
+ break;
+ }
+
+ return stolen_size;
+}
+
+static size_t __init gen6_stolen_size(int num, int slot, int func)
+{
+ u16 gmch_ctrl;
+
+ gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
+ gmch_ctrl = SNB_GMCH_GMS_SHIFT;
+ gmch_ctrl = SNB_GMCH_GMS_MASK;
+
+ return gmch_ctrl 25; /* 32 MB units */
+}
+
+typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+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(gen3_stolen_size),
+ INTEL_VLV_D_IDS(gen3_stolen_size),
+ INTEL_PINEVIEW_IDS(gen3_stolen_size),
+ INTEL_I965G_IDS(gen3_stolen_size),
+
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
Hmm, interesting licence block in i915_pciids.h - our claim to grant licence but TG disclaims liability. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
On Thu, 25 Jul 2013 23:59:25 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: Hmm, interesting licence block in i915_pciids.h - our claim to grant licence but TG disclaims liability. Oops my manual search replace obviously failed. Will fix up. -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] x86: add early quirk for reserving Intel graphics stolen memory v3
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process. On some systems, MMIO space is allocated on top, despite
the efforts of the RAM buffer approach, which simply rounds memory
boundaries up to 64M to try to catch space that may decode as RAM and so
is not suitable for MMIO.
v2: use read_pci_config for 32 bit reads instead of adding a new one
(Chris)
add gen6 stolen size function (Chris)
use a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 158 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..bff8a6f 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -12,6 +12,7 @@
#include linux/pci.h
#include linux/acpi.h
#include linux/pci_ids.h
+#include drm/i915_drm.h
#include asm/pci-direct.h
#include asm/dma.h
#include asm/io_apic.h
@@ -208,6 +209,161 @@ static void __init intel_remapping_check(int num, int
slot, int func)
}
+/*
+ * Systems with Intel graphics controllers set aside memory exclusively
+ * for gfx driver use. This memory is not marked in the E820 as reserved
+ * or as RAM, and so is subject to overlap from E820 manipulation later
+ * in the boot process. On some systems, MMIO space is allocated on top,
+ * despite the efforts of the RAM buffer approach, which simply rounds
+ * memory boundaries up to 64M to try to catch space that may decode
+ * as RAM and so is not suitable for MMIO.
+ *
+ * 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)
+{
+ u32 base;
+
+ /*
+* 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.
+*/
+ base = read_pci_config(num, slot, func, 0x5c);
+ base = ~((120) - 1);
+
+ return base;
+}
+
+#define KB(x) ((x) * 1024)
+#define MB(x) (KB (KB (x)))
+#define GB(x) (MB (KB (x)))
+
+static size_t __init gen3_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 I855_GMCH_GMS_MASK) {
+ case I855_GMCH_GMS_STOLEN_1M:
+ stolen_size = MB(1);
+ break;
+ case I855_GMCH_GMS_STOLEN_4M:
+ stolen_size = MB(4);
+ break;
+ case I855_GMCH_GMS_STOLEN_8M:
+ stolen_size = MB(8);
+ break;
+ case I855_GMCH_GMS_STOLEN_16M:
+ stolen_size = MB(16);
+ break;
+ case I855_GMCH_GMS_STOLEN_32M:
+ stolen_size = MB(32);
+ break;
+ case I915_GMCH_GMS_STOLEN_48M:
+ stolen_size = MB(48);
+ break;
+ case I915_GMCH_GMS_STOLEN_64M:
+ stolen_size = MB(64);
+ break;
+ case G33_GMCH_GMS_STOLEN_128M:
+ stolen_size = MB(128);
+ break;
+ case G33_GMCH_GMS_STOLEN_256M:
+ stolen_size = MB(256);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_96M:
+ stolen_size = MB(96);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_160M:
+ stolen_size = MB(160);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_224M:
+ stolen_size = MB(224);
+ break;
+ case INTEL_GMCH_GMS_STOLEN_352M:
+ stolen_size = MB(352);
+ break;
+ default:
+ stolen_size = 0;
+ break;
+ }
+
+ return stolen_size;
+}
+
+static size_t __init gen6_stolen_size(int num, int slot, int func)
+{
+ u16 gmch_ctrl;
+
+ gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
+ gmch_ctrl = SNB_GMCH_GMS_SHIFT;
+ gmch_ctrl = SNB_GMCH_GMS_MASK;
+
+ return gmch_ctrl 25; /* 32 MB units */
+}
+
+typedef size_t (*stolen_size_fn)(int num, int slot, int func);
+
+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(gen3_stolen_size),
+ INTEL_VLV_D_IDS(gen3_stolen_size),
+ INTEL_PINEVIEW_IDS(gen3_stolen_size),
+ INTEL_I965G_IDS(gen3_stolen_size),
+
