2006-09-26 16:52:30 +08:00
|
|
|
/* Various workarounds for chipset bugs.
|
|
|
|
This code runs very early and can't use the regular PCI subsystem
|
|
|
|
The entries are keyed to PCI bridges which usually identify chipsets
|
|
|
|
uniquely.
|
|
|
|
This is only for whole classes of chipsets with specific problems which
|
|
|
|
need early invasive action (e.g. before the timers are initialized).
|
|
|
|
Most PCI device specific workarounds can be done later and should be
|
|
|
|
in standard PCI quirks
|
|
|
|
Mainboard specific bugs should be handled by DMI entries.
|
|
|
|
CPU specific bugs in setup.c */
|
|
|
|
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/pci_ids.h>
|
2013-07-27 04:32:52 +08:00
|
|
|
#include <drm/i915_drm.h>
|
2006-09-26 16:52:30 +08:00
|
|
|
#include <asm/pci-direct.h>
|
|
|
|
#include <asm/dma.h>
|
2007-10-20 02:35:03 +08:00
|
|
|
#include <asm/io_apic.h>
|
|
|
|
#include <asm/apic.h>
|
2014-04-24 16:18:18 +08:00
|
|
|
#include <asm/hpet.h>
|
2008-07-11 09:23:42 +08:00
|
|
|
#include <asm/iommu.h>
|
2008-11-28 01:39:15 +08:00
|
|
|
#include <asm/gart.h>
|
2013-04-17 04:38:32 +08:00
|
|
|
#include <asm/irq_remapping.h>
|
2006-09-26 16:52:30 +08:00
|
|
|
|
2008-01-30 20:31:25 +08:00
|
|
|
static void __init fix_hypertransport_config(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u32 htcfg;
|
|
|
|
/*
|
|
|
|
* we found a hypertransport bus
|
|
|
|
* make sure that we are broadcasting
|
|
|
|
* interrupts to all cpus on the ht bus
|
|
|
|
* if we're using extended apic ids
|
|
|
|
*/
|
|
|
|
htcfg = read_pci_config(num, slot, func, 0x68);
|
|
|
|
if (htcfg & (1 << 18)) {
|
2008-01-30 20:31:26 +08:00
|
|
|
printk(KERN_INFO "Detected use of extended apic ids "
|
|
|
|
"on hypertransport bus\n");
|
2008-01-30 20:31:25 +08:00
|
|
|
if ((htcfg & (1 << 17)) == 0) {
|
2008-01-30 20:31:26 +08:00
|
|
|
printk(KERN_INFO "Enabling hypertransport extended "
|
|
|
|
"apic interrupt broadcast\n");
|
|
|
|
printk(KERN_INFO "Note this is a bios bug, "
|
|
|
|
"please contact your hw vendor\n");
|
2008-01-30 20:31:25 +08:00
|
|
|
htcfg |= (1 << 17);
|
|
|
|
write_pci_config(num, slot, func, 0x68, htcfg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init via_bugs(int num, int slot, int func)
|
2006-09-26 16:52:30 +08:00
|
|
|
{
|
2007-10-24 18:49:48 +08:00
|
|
|
#ifdef CONFIG_GART_IOMMU
|
2008-06-25 13:14:09 +08:00
|
|
|
if ((max_pfn > MAX_DMA32_PFN || force_iommu) &&
|
2007-10-24 18:49:50 +08:00
|
|
|
!gart_iommu_aperture_allowed) {
|
2006-09-26 16:52:30 +08:00
|
|
|
printk(KERN_INFO
|
2007-10-20 02:35:03 +08:00
|
|
|
"Looks like a VIA chipset. Disabling IOMMU."
|
|
|
|
" Override with iommu=allowed\n");
|
2007-10-24 18:49:50 +08:00
|
|
|
gart_iommu_aperture_disabled = 1;
|
2006-09-26 16:52:30 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI
|
2007-10-28 02:57:43 +08:00
|
|
|
#ifdef CONFIG_X86_IO_APIC
|
2006-09-26 16:52:30 +08:00
|
|
|
|
2007-02-03 00:48:22 +08:00
|
|
|
static int __init nvidia_hpet_check(struct acpi_table_header *header)
|
2006-09-26 16:52:30 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2007-10-28 02:57:43 +08:00
|
|
|
#endif /* CONFIG_X86_IO_APIC */
|
|
|
|
#endif /* CONFIG_ACPI */
|
2006-09-26 16:52:30 +08:00
|
|
|
|
2008-01-30 20:31:25 +08:00
|
|
|
static void __init nvidia_bugs(int num, int slot, int func)
|
2006-09-26 16:52:30 +08:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_ACPI
|
2007-10-20 02:35:03 +08:00
|
|
|
#ifdef CONFIG_X86_IO_APIC
|
2006-09-26 16:52:30 +08:00
|
|
|
/*
|
|
|
|
* All timer overrides on Nvidia are
|
|
|
|
* wrong unless HPET is enabled.
|
2006-11-14 23:57:46 +08:00
|
|
|
* Unfortunately that's not true on many Asus boards.
|
|
|
|
* We don't know yet how to detect this automatically, but
|
|
|
|
* at least allow a command line override.
|
2006-09-26 16:52:30 +08:00
|
|
|
*/
|
2006-11-14 23:57:46 +08:00
|
|
|
if (acpi_use_timer_override)
|
|
|
|
return;
|
|
|
|
|
2007-03-09 07:28:32 +08:00
|
|
|
if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) {
|
2006-09-26 16:52:30 +08:00
|
|
|
acpi_skip_timer_override = 1;
|
|
|
|
printk(KERN_INFO "Nvidia board "
|
|
|
|
"detected. Ignoring ACPI "
|
|
|
|
"timer override.\n");
|
2006-11-14 23:57:46 +08:00
|
|
|
printk(KERN_INFO "If you got timer trouble "
|
|
|
|
"try acpi_use_timer_override\n");
|
2006-09-26 16:52:30 +08:00
|
|
|
}
|
2007-10-20 02:35:03 +08:00
|
|
|
#endif
|
2006-09-26 16:52:30 +08:00
|
|
|
#endif
|
|
|
|
/* RED-PEN skip them on mptables too? */
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2008-10-15 03:01:15 +08:00
|
|
|
#if defined(CONFIG_ACPI) && defined(CONFIG_X86_IO_APIC)
|
|
|
|
static u32 __init ati_ixp4x0_rev(int num, int slot, int func)
|
2008-10-07 06:11:22 +08:00
|
|
|
{
|
|
|
|
u32 d;
|
|
|
|
u8 b;
|
|
|
|
|
|
|
|
b = read_pci_config_byte(num, slot, func, 0xac);
|
|
|
|
b &= ~(1<<5);
|
|
|
|
write_pci_config_byte(num, slot, func, 0xac, b);
|
|
|
|
|
|
|
|
d = read_pci_config(num, slot, func, 0x70);
|
|
|
|
d |= 1<<8;
|
|
|
|
write_pci_config(num, slot, func, 0x70, d);
|
|
|
|
|
|
|
|
d = read_pci_config(num, slot, func, 0x8);
|
|
|
|
d &= 0xff;
|
|
|
|
return d;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init ati_bugs(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u32 d;
|
|
|
|
u8 b;
|
|
|
|
|
|
|
|
if (acpi_use_timer_override)
|
|
|
|
return;
|
|
|
|
|
|
|
|
d = ati_ixp4x0_rev(num, slot, func);
|
|
|
|
if (d < 0x82)
|
|
|
|
acpi_skip_timer_override = 1;
|
|
|
|
else {
|
|
|
|
/* check for IRQ0 interrupt swap */
|
|
|
|
outb(0x72, 0xcd6); b = inb(0xcd7);
|
|
|
|
if (!(b & 0x2))
|
|
|
|
acpi_skip_timer_override = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (acpi_skip_timer_override) {
|
|
|
|
printk(KERN_INFO "SB4X0 revision 0x%x\n", d);
|
|
|
|
printk(KERN_INFO "Ignoring ACPI timer override.\n");
|
|
|
|
printk(KERN_INFO "If you got timer trouble "
|
|
|
|
"try acpi_use_timer_override\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-10-15 03:01:15 +08:00
|
|
|
static u32 __init ati_sbx00_rev(int num, int slot, int func)
|
|
|
|
{
|
2011-02-24 22:53:46 +08:00
|
|
|
u32 d;
|
2008-10-15 03:01:15 +08:00
|
|
|
|
|
|
|
d = read_pci_config(num, slot, func, 0x8);
|
|
|
|
d &= 0xff;
|
|
|
|
|
|
|
|
return d;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init ati_bugs_contd(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u32 d, rev;
|
|
|
|
|
|
|
|
rev = ati_sbx00_rev(num, slot, func);
|
2011-02-24 22:53:46 +08:00
|
|
|
if (rev >= 0x40)
|
|
|
|
acpi_fix_pin2_polarity = 1;
|
|
|
|
|
2011-03-15 22:31:37 +08:00
|
|
|
/*
|
|
|
|
* SB600: revisions 0x11, 0x12, 0x13, 0x14, ...
|
|
|
|
* SB700: revisions 0x39, 0x3a, ...
|
|
|
|
* SB800: revisions 0x40, 0x41, ...
|
|
|
|
*/
|
|
|
|
if (rev >= 0x39)
|
2008-10-15 03:01:15 +08:00
|
|
|
return;
|
|
|
|
|
2011-02-24 22:53:46 +08:00
|
|
|
if (acpi_use_timer_override)
|
|
|
|
return;
|
|
|
|
|
2008-10-15 03:01:15 +08:00
|
|
|
/* check for IRQ0 interrupt swap */
|
|
|
|
d = read_pci_config(num, slot, func, 0x64);
|
|
|
|
if (!(d & (1<<14)))
|
|
|
|
acpi_skip_timer_override = 1;
|
|
|
|
|
|
|
|
if (acpi_skip_timer_override) {
|
|
|
|
printk(KERN_INFO "SB600 revision 0x%x\n", rev);
|
|
|
|
printk(KERN_INFO "Ignoring ACPI timer override.\n");
|
|
|
|
printk(KERN_INFO "If you got timer trouble "
|
|
|
|
"try acpi_use_timer_override\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static void __init ati_bugs(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init ati_bugs_contd(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-04-17 04:38:32 +08:00
|
|
|
static void __init intel_remapping_check(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u8 revision;
|
2013-07-17 19:13:59 +08:00
|
|
|
u16 device;
|
2013-04-17 04:38:32 +08:00
|
|
|
|
2013-07-17 19:13:59 +08:00
|
|
|
device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
|
2013-04-17 04:38:32 +08:00
|
|
|
revision = read_pci_config_byte(num, slot, func, PCI_REVISION_ID);
|
|
|
|
|
|
|
|
/*
|
2014-03-13 02:44:33 +08:00
|
|
|
* Revision <= 13 of all triggering devices id in this quirk
|
|
|
|
* have a problem draining interrupts when irq remapping is
|
|
|
|
* enabled, and should be flagged as broken. Additionally
|
|
|
|
* revision 0x22 of device id 0x3405 has this problem.
|
2013-04-17 04:38:32 +08:00
|
|
|
*/
|
2014-03-13 02:44:33 +08:00
|
|
|
if (revision <= 0x13)
|
2013-04-17 04:38:32 +08:00
|
|
|
set_irq_remapping_broken();
|
2014-03-13 02:44:33 +08:00
|
|
|
else if (device == 0x3405 && revision == 0x22)
|
2013-07-17 19:13:59 +08:00
|
|
|
set_irq_remapping_broken();
|
2013-04-17 04:38:32 +08:00
|
|
|
}
|
|
|
|
|
2013-07-27 04:32:52 +08:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2014-04-13 17:45:03 +08:00
|
|
|
#define KB(x) ((x) * 1024UL)
|
2013-07-27 04:32:52 +08:00
|
|
|
#define MB(x) (KB (KB (x)))
|
|
|
|
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
static size_t __init i830_tseg_size(void)
|
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
u8 esmramc = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
if (!(esmramc & TSEG_ENABLE))
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
return 0;
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
if (esmramc & I830_TSEG_SIZE_1M)
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
return MB(1);
|
|
|
|
else
|
|
|
|
return KB(512);
|
|
|
|
}
|
|
|
|
|
|
|
|
static size_t __init i845_tseg_size(void)
|
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
u8 esmramc = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
|
|
|
|
u8 tseg_size = esmramc & I845_TSEG_SIZE_MASK;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
if (!(esmramc & TSEG_ENABLE))
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
return 0;
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
switch (tseg_size) {
|
|
|
|
case I845_TSEG_SIZE_512K: return KB(512);
|
|
|
|
case I845_TSEG_SIZE_1M: return MB(1);
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
default:
|
2016-04-22 18:29:26 +08:00
|
|
|
WARN(1, "Unknown ESMRAMC value: %x!\n", esmramc);
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
2016-04-22 18:29:26 +08:00
|
|
|
return 0;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static size_t __init i85x_tseg_size(void)
|
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
u8 esmramc = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
if (!(esmramc & TSEG_ENABLE))
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
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.
|
|
|
|
*/
|
2016-04-22 18:29:26 +08:00
|
|
|
static phys_addr_t __init i830_stolen_base(int num, int slot, int func,
|
|
|
|
size_t stolen_size)
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
return (phys_addr_t)i830_mem_size() - i830_tseg_size() - stolen_size;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
static phys_addr_t __init i845_stolen_base(int num, int slot, int func,
|
|
|
|
size_t stolen_size)
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
return (phys_addr_t)i830_mem_size() - i845_tseg_size() - stolen_size;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
static phys_addr_t __init i85x_stolen_base(int num, int slot, int func,
|
|
|
|
size_t stolen_size)
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
return (phys_addr_t)i85x_mem_size() - i85x_tseg_size() - stolen_size;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
static phys_addr_t __init i865_stolen_base(int num, int slot, int func,
|
|
|
|
size_t stolen_size)
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
{
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 toud;
|
|
|
|
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
/*
|
|
|
|
* FIXME is the graphics stolen memory region
|
|
|
|
* always at TOUD? Ie. is it always the last
|
|
|
|
* one to be allocated by the BIOS?
|
|
|
|
*/
|
2016-04-22 18:29:26 +08:00
|
|
|
toud = read_pci_config_16(0, 0, 0, I865_TOUD);
|
|
|
|
|
|
|
|
return (phys_addr_t)toud << 16;
|
|
|
|
}
|
|
|
|
|
|
|
|
static phys_addr_t __init gen3_stolen_base(int num, int slot, int func,
|
|
|
|
size_t stolen_size)
|
|
|
|
{
|
|
|
|
u32 bsm;
|
|
|
|
|
|
|
|
/* Almost universally we can find the Graphics Base of Stolen Memory
|
|
|
|
* at register BSM (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.
|
|
|
|
*/
|
|
|
|
bsm = read_pci_config(num, slot, func, INTEL_BSM);
|
|
|
|
|
|
|
|
return (phys_addr_t)bsm & INTEL_BSM_MASK;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static size_t __init i830_stolen_size(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u16 gmch_ctrl;
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 gms;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
|
|
|
|
gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
|
2016-04-22 18:29:26 +08:00
|
|
|
gms = gmch_ctrl & I830_GMCH_GMS_MASK;
|
|
|
|
|
|
|
|
switch (gms) {
|
|
|
|
case I830_GMCH_GMS_STOLEN_512: return KB(512);
|
|
|
|
case I830_GMCH_GMS_STOLEN_1024: return MB(1);
|
|
|
|
case I830_GMCH_GMS_STOLEN_8192: return MB(8);
|
|
|
|
/* local memory isn't part of the normal address space */
|
|
|
|
case I830_GMCH_GMS_LOCAL: return 0;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
default:
|
2016-04-22 18:29:26 +08:00
|
|
|
WARN(1, "Unknown GMCH_CTRL value: %x!\n", gmch_ctrl);
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
return 0;
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
}
|
|
|
|
|
2013-07-27 04:32:52 +08:00
|
|
|
static size_t __init gen3_stolen_size(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u16 gmch_ctrl;
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 gms;
|
2013-07-27 04:32:52 +08:00
|
|
|
|
|
|
|
gmch_ctrl = read_pci_config_16(0, 0, 0, I830_GMCH_CTRL);
|
2016-04-22 18:29:26 +08:00
|
|
|
gms = gmch_ctrl & I855_GMCH_GMS_MASK;
|
|
|
|
|
|
|
|
switch (gms) {
|
|
|
|
case I855_GMCH_GMS_STOLEN_1M: return MB(1);
|
|
|
|
case I855_GMCH_GMS_STOLEN_4M: return MB(4);
|
|
|
|
case I855_GMCH_GMS_STOLEN_8M: return MB(8);
|
|
|
|
case I855_GMCH_GMS_STOLEN_16M: return MB(16);
|
|
|
|
case I855_GMCH_GMS_STOLEN_32M: return MB(32);
|
|
|
|
case I915_GMCH_GMS_STOLEN_48M: return MB(48);
|
|
|
|
case I915_GMCH_GMS_STOLEN_64M: return MB(64);
|
|
|
|
case G33_GMCH_GMS_STOLEN_128M: return MB(128);
|
|
|
|
case G33_GMCH_GMS_STOLEN_256M: return MB(256);
|
|
|
|
case INTEL_GMCH_GMS_STOLEN_96M: return MB(96);
|
|
|
|
case INTEL_GMCH_GMS_STOLEN_160M:return MB(160);
|
|
|
|
case INTEL_GMCH_GMS_STOLEN_224M:return MB(224);
|
|
|
|
case INTEL_GMCH_GMS_STOLEN_352M:return MB(352);
|
2013-07-27 04:32:52 +08:00
|
|
|
default:
|
2016-04-22 18:29:26 +08:00
|
|
|
WARN(1, "Unknown GMCH_CTRL value: %x!\n", gmch_ctrl);
|
2013-07-27 04:32:52 +08:00
|
|
|
}
|
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
return 0;
|
2013-07-27 04:32:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static size_t __init gen6_stolen_size(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u16 gmch_ctrl;
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 gms;
|
2013-07-27 04:32:52 +08:00
|
|
|
|
|
|
|
gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
|
2016-04-22 18:29:26 +08:00
|
|
|
gms = (gmch_ctrl >> SNB_GMCH_GMS_SHIFT) & SNB_GMCH_GMS_MASK;
|
2013-07-27 04:32:52 +08:00
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
return (size_t)gms * MB(32);
|
2013-07-27 04:32:52 +08:00
|
|
|
}
|
|
|
|
|
2014-05-09 03:19:42 +08:00
|
|
|
static size_t __init gen8_stolen_size(int num, int slot, int func)
|
2013-11-04 08:53:55 +08:00
|
|
|
{
|
|
|
|
u16 gmch_ctrl;
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 gms;
|
2013-11-04 08:53:55 +08:00
|
|
|
|
|
|
|
gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
|
2016-04-22 18:29:26 +08:00
|
|
|
gms = (gmch_ctrl >> BDW_GMCH_GMS_SHIFT) & BDW_GMCH_GMS_MASK;
|
|
|
|
|
|
|
|
return (size_t)gms * MB(32);
|
2013-11-04 08:53:55 +08:00
|
|
|
}
|
|
|
|
|
2014-05-09 03:19:41 +08:00
|
|
|
static size_t __init chv_stolen_size(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u16 gmch_ctrl;
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 gms;
|
2014-05-09 03:19:41 +08:00
|
|
|
|
|
|
|
gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
|
2016-04-22 18:29:26 +08:00
|
|
|
gms = (gmch_ctrl >> SNB_GMCH_GMS_SHIFT) & SNB_GMCH_GMS_MASK;
|
2014-05-09 03:19:41 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 0x0 to 0x10: 32MB increments starting at 0MB
|
|
|
|
* 0x11 to 0x16: 4MB increments starting at 8MB
|
|
|
|
* 0x17 to 0x1d: 4MB increments start at 36MB
|
|
|
|
*/
|
2016-04-22 18:29:26 +08:00
|
|
|
if (gms < 0x11)
|
|
|
|
return (size_t)gms * MB(32);
|
|
|
|
else if (gms < 0x17)
|
|
|
|
return (size_t)(gms - 0x11 + 2) * MB(4);
|
2014-05-09 03:19:41 +08:00
|
|
|
else
|
2016-04-22 18:29:26 +08:00
|
|
|
return (size_t)(gms - 0x17 + 9) * MB(4);
|
2014-05-09 03:19:41 +08:00
|
|
|
}
|
2014-02-06 03:28:58 +08:00
|
|
|
|
2014-01-10 02:02:46 +08:00
|
|
|
static size_t __init gen9_stolen_size(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
u16 gmch_ctrl;
|
2016-04-22 18:29:26 +08:00
|
|
|
u16 gms;
|
2014-01-10 02:02:46 +08:00
|
|
|
|
|
|
|
gmch_ctrl = read_pci_config_16(num, slot, func, SNB_GMCH_CTRL);
|
2016-04-22 18:29:26 +08:00
|
|
|
gms = (gmch_ctrl >> BDW_GMCH_GMS_SHIFT) & BDW_GMCH_GMS_MASK;
|
2014-01-10 02:02:46 +08:00
|
|
|
|
2016-04-22 18:29:26 +08:00
|
|
|
/* 0x0 to 0xef: 32MB increments starting at 0MB */
|
|
|
|
/* 0xf0 to 0xfe: 4MB increments starting at 4MB */
|
|
|
|
if (gms < 0xf0)
|
|
|
|
return (size_t)gms * MB(32);
|
2014-01-10 02:02:46 +08:00
|
|
|
else
|
2016-04-22 18:29:26 +08:00
|
|
|
return (size_t)(gms - 0xf0 + 1) * MB(4);
|
2014-01-10 02:02:46 +08:00
|
|
|
}
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
struct intel_early_ops {
|
|
|
|
size_t (*stolen_size)(int num, int slot, int func);
|
|
|
|
phys_addr_t (*stolen_base)(int num, int slot, int func, size_t size);
|
|
|
|
};
|
2014-01-10 02:02:46 +08:00
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops i830_early_ops __initconst = {
|
|
|
|
.stolen_base = i830_stolen_base,
|
|
|
|
.stolen_size = i830_stolen_size,
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops i845_early_ops __initconst = {
|
|
|
|
.stolen_base = i845_stolen_base,
|
|
|
|
.stolen_size = i830_stolen_size,
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops i85x_early_ops __initconst = {
|
|
|
|
.stolen_base = i85x_stolen_base,
|
|
|
|
.stolen_size = gen3_stolen_size,
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops i865_early_ops __initconst = {
|
|
|
|
.stolen_base = i865_stolen_base,
|
|
|
|
.stolen_size = gen3_stolen_size,
|
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms
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:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-02-06 03:28:59 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops gen3_early_ops __initconst = {
|
|
|
|
.stolen_base = gen3_stolen_base,
|
|
|
|
.stolen_size = gen3_stolen_size,
|
2014-02-06 03:28:58 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops gen6_early_ops __initconst = {
|
|
|
|
.stolen_base = gen3_stolen_base,
|
|
|
|
.stolen_size = gen6_stolen_size,
|
2014-02-06 03:28:58 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops gen8_early_ops __initconst = {
|
|
|
|
.stolen_base = gen3_stolen_base,
|
|
|
|
.stolen_size = gen8_stolen_size,
|
2014-02-06 03:28:58 +08:00
|
|
|
};
|
2013-07-27 04:32:52 +08:00
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops gen9_early_ops __initconst = {
|
|
|
|
.stolen_base = gen3_stolen_base,
|
|
|
|
.stolen_size = gen9_stolen_size,
|
2014-01-10 02:02:46 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct intel_early_ops chv_early_ops __initconst = {
|
|
|
|
.stolen_base = gen3_stolen_base,
|
|
|
|
.stolen_size = chv_stolen_size,
|
2014-05-09 03:19:41 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static const struct pci_device_id intel_early_ids[] __initconst = {
|
|
|
|
INTEL_I830_IDS(&i830_early_ops),
|
|
|
|
INTEL_I845G_IDS(&i845_early_ops),
|
|
|
|
INTEL_I85X_IDS(&i85x_early_ops),
|
|
|
|
INTEL_I865G_IDS(&i865_early_ops),
|
|
|
|
INTEL_I915G_IDS(&gen3_early_ops),
|
|
|
|
INTEL_I915GM_IDS(&gen3_early_ops),
|
|
|
|
INTEL_I945G_IDS(&gen3_early_ops),
|
|
|
|
INTEL_I945GM_IDS(&gen3_early_ops),
|
|
|
|
INTEL_VLV_M_IDS(&gen6_early_ops),
|
|
|
|
INTEL_VLV_D_IDS(&gen6_early_ops),
|
|
|
|
INTEL_PINEVIEW_IDS(&gen3_early_ops),
|
|
|
|
INTEL_I965G_IDS(&gen3_early_ops),
|
|
|
|
INTEL_G33_IDS(&gen3_early_ops),
|
|
|
|
INTEL_I965GM_IDS(&gen3_early_ops),
|
|
|
|
INTEL_GM45_IDS(&gen3_early_ops),
|
|
|
|
INTEL_G45_IDS(&gen3_early_ops),
|
|
|
|
INTEL_IRONLAKE_D_IDS(&gen3_early_ops),
|
|
|
|
INTEL_IRONLAKE_M_IDS(&gen3_early_ops),
|
|
|
|
INTEL_SNB_D_IDS(&gen6_early_ops),
|
|
|
|
INTEL_SNB_M_IDS(&gen6_early_ops),
|
|
|
|
INTEL_IVB_M_IDS(&gen6_early_ops),
|
|
|
|
INTEL_IVB_D_IDS(&gen6_early_ops),
|
|
|
|
INTEL_HSW_D_IDS(&gen6_early_ops),
|
|
|
|
INTEL_HSW_M_IDS(&gen6_early_ops),
|
|
|
|
INTEL_BDW_M_IDS(&gen8_early_ops),
|
|
|
|
INTEL_BDW_D_IDS(&gen8_early_ops),
|
|
|
|
INTEL_CHV_IDS(&chv_early_ops),
|
|
|
|
INTEL_SKL_IDS(&gen9_early_ops),
|
|
|
|
INTEL_BXT_IDS(&gen9_early_ops),
|
|
|
|
INTEL_KBL_IDS(&gen9_early_ops),
|
2013-07-27 04:32:52 +08:00
|
|
|
};
|
|
|
|
|
2016-04-22 18:45:49 +08:00
|
|
|
static void __init
|
|
|
|
intel_graphics_stolen(int num, int slot, int func,
|
|
|
|
const struct intel_early_ops *early_ops)
|
2013-07-27 04:32:52 +08:00
|
|
|
{
|
2016-04-22 18:45:49 +08:00
|
|
|
phys_addr_t base;
|
2013-07-27 04:32:52 +08:00
|
|
|
size_t size;
|
2016-04-22 18:45:49 +08:00
|
|
|
|
|
|
|
size = early_ops->stolen_size(num, slot, func);
|
|
|
|
base = early_ops->stolen_base(num, slot, func, size);
|
|
|
|
|
|
|
|
if (!size || !base)
|
|
|
|
return;
|
|
|
|
|
|
|
|
printk(KERN_INFO "Reserving Intel graphics stolen memory at "
|
|
|
|
"0x%llx-0x%llx\n", base, base + size - 1);
|
|
|
|
|
|
|
|
/* Mark this space as reserved */
|
|
|
|
e820_add_region(base, size, E820_RESERVED);
|
|
|
|
sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init intel_graphics_quirks(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
const struct intel_early_ops *early_ops;
|
|
|
|
u16 device;
|
2013-07-27 04:32:52 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
|
2016-04-22 18:45:49 +08:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(intel_early_ids); i++) {
|
|
|
|
kernel_ulong_t driver_data = intel_early_ids[i].driver_data;
|
|
|
|
|
|
|
|
if (intel_early_ids[i].device != device)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
early_ops = (typeof(early_ops))driver_data;
|
|
|
|
|
|
|
|
intel_graphics_stolen(num, slot, func, early_ops);
|
|
|
|
|
|
|
|
return;
|
2013-07-27 04:32:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-24 16:18:18 +08:00
|
|
|
static void __init force_disable_hpet(int num, int slot, int func)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_HPET_TIMER
|
2015-10-19 18:35:44 +08:00
|
|
|
boot_hpet_disable = true;
|
2014-04-24 16:18:18 +08:00
|
|
|
pr_info("x86/hpet: Will disable the HPET for this platform because it's not reliable\n");
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-01-30 20:31:25 +08:00
|
|
|
#define QFLAG_APPLY_ONCE 0x1
|
|
|
|
#define QFLAG_APPLIED 0x2
|
|
|
|
#define QFLAG_DONE (QFLAG_APPLY_ONCE|QFLAG_APPLIED)
|
2006-09-26 16:52:30 +08:00
|
|
|
struct chipset {
|
2008-01-30 20:31:25 +08:00
|
|
|
u32 vendor;
|
|
|
|
u32 device;
|
|
|
|
u32 class;
|
|
|
|
u32 class_mask;
|
|
|
|
u32 flags;
|
|
|
|
void (*f)(int num, int slot, int func);
|
2006-09-26 16:52:30 +08:00
|
|
|
};
|
|
|
|
|
2009-01-10 04:17:39 +08:00
|
|
|
/*
|
|
|
|
* Only works for devices on the root bus. If you add any devices
|
|
|
|
* not on bus 0 readd another loop level in early_quirks(). But
|
|
|
|
* be careful because at least the Nvidia quirk here relies on
|
|
|
|
* only matching on bus 0.
|
|
|
|
*/
|
2007-04-09 07:04:03 +08:00
|
|
|
static struct chipset early_qrk[] __initdata = {
|
2008-01-30 20:31:25 +08:00
|
|
|
{ PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
|
|
|
|
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, nvidia_bugs },
|
|
|
|
{ PCI_VENDOR_ID_VIA, PCI_ANY_ID,
|
|
|
|
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
|
|
|
|
{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
|
|
|
|
PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
|
2008-10-07 06:11:22 +08:00
|
|
|
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_SMBUS,
|
|
|
|
PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
|
2008-10-15 03:01:15 +08:00
|
|
|
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
|
|
|
|
PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
|
2013-04-17 04:38:32 +08:00
|
|
|
{ PCI_VENDOR_ID_INTEL, 0x3403, PCI_CLASS_BRIDGE_HOST,
|
|
|
|
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
|
2013-07-17 19:13:59 +08:00
|
|
|
{ PCI_VENDOR_ID_INTEL, 0x3405, PCI_CLASS_BRIDGE_HOST,
|
|
|
|
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
|
2013-04-17 04:38:32 +08:00
|
|
|
{ PCI_VENDOR_ID_INTEL, 0x3406, PCI_CLASS_BRIDGE_HOST,
|
|
|
|
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
|
2013-07-27 04:32:52 +08:00
|
|
|
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA, PCI_ANY_ID,
|
2016-04-22 18:45:49 +08:00
|
|
|
QFLAG_APPLY_ONCE, intel_graphics_quirks },
|
2014-04-24 16:18:18 +08:00
|
|
|
/*
|
2015-06-15 17:40:01 +08:00
|
|
|
* HPET on the current version of the Baytrail platform has accuracy
|
|
|
|
* problems: it will halt in deep idle state - so we disable it.
|
|
|
|
*
|
|
|
|
* More details can be found in section 18.10.1.3 of the datasheet:
|
|
|
|
*
|
|
|
|
* http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-1.pdf
|
2014-04-24 16:18:18 +08:00
|
|
|
*/
|
|
|
|
{ PCI_VENDOR_ID_INTEL, 0x0f00,
|
|
|
|
PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
|
2006-09-26 16:52:30 +08:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2008-06-17 06:29:45 +08:00
|
|
|
/**
|
|
|
|
* check_dev_quirk - apply early quirks to a given PCI device
|
|
|
|
* @num: bus number
|
|
|
|
* @slot: slot number
|
|
|
|
* @func: PCI function
|
|
|
|
*
|
|
|
|
* Check the vendor & device ID against the early quirks table.
|
|
|
|
*
|
|
|
|
* If the device is single function, let early_quirks() know so we don't
|
|
|
|
* poke at this device again.
|
|
|
|
*/
|
|
|
|
static int __init check_dev_quirk(int num, int slot, int func)
|
2008-01-30 20:31:26 +08:00
|
|
|
{
|
|
|
|
u16 class;
|
|
|
|
u16 vendor;
|
|
|
|
u16 device;
|
|
|
|
u8 type;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
class = read_pci_config_16(num, slot, func, PCI_CLASS_DEVICE);
|
|
|
|
|
|
|
|
if (class == 0xffff)
|
2008-06-17 06:29:45 +08:00
|
|
|
return -1; /* no class, treat as single function */
|
2008-01-30 20:31:26 +08:00
|
|
|
|
|
|
|
vendor = read_pci_config_16(num, slot, func, PCI_VENDOR_ID);
|
|
|
|
|
|
|
|
device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
|
|
|
|
|
|
|
|
for (i = 0; early_qrk[i].f != NULL; i++) {
|
|
|
|
if (((early_qrk[i].vendor == PCI_ANY_ID) ||
|
|
|
|
(early_qrk[i].vendor == vendor)) &&
|
|
|
|
((early_qrk[i].device == PCI_ANY_ID) ||
|
|
|
|
(early_qrk[i].device == device)) &&
|
|
|
|
(!((early_qrk[i].class ^ class) &
|
|
|
|
early_qrk[i].class_mask))) {
|
|
|
|
if ((early_qrk[i].flags &
|
|
|
|
QFLAG_DONE) != QFLAG_DONE)
|
|
|
|
early_qrk[i].f(num, slot, func);
|
|
|
|
early_qrk[i].flags |= QFLAG_APPLIED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
type = read_pci_config_byte(num, slot, func,
|
|
|
|
PCI_HEADER_TYPE);
|
|
|
|
if (!(type & 0x80))
|
2008-06-17 06:29:45 +08:00
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
2008-01-30 20:31:26 +08:00
|
|
|
}
|
|
|
|
|
2006-09-26 16:52:30 +08:00
|
|
|
void __init early_quirks(void)
|
|
|
|
{
|
2009-01-10 04:17:39 +08:00
|
|
|
int slot, func;
|
2006-09-26 16:52:41 +08:00
|
|
|
|
|
|
|
if (!early_pci_allowed())
|
|
|
|
return;
|
|
|
|
|
2006-09-26 16:52:30 +08:00
|
|
|
/* Poor man's PCI discovery */
|
2009-01-10 04:17:39 +08:00
|
|
|
/* Only scan the root bus */
|
|
|
|
for (slot = 0; slot < 32; slot++)
|
|
|
|
for (func = 0; func < 8; func++) {
|
|
|
|
/* Only probe function 0 on single fn devices */
|
|
|
|
if (check_dev_quirk(0, slot, func))
|
|
|
|
break;
|
|
|
|
}
|
2006-09-26 16:52:30 +08:00
|
|
|
}
|