Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
* Daniel Vetter wrote: > On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote: > > Hi x86 folks, > > > > Ping on getting the gen2 stolen memory early quirk patches into > > the x86 tree. > > > > From our side Daniel and Chris both seemed happy with them, so I'd > > like to get them in at some point. > > Yup, I think this is ready for 3.15. And since there's no direct > depency really between the i915 parts and the x86 early reserve > stuff they can go both in through relevant trees - i915 will simply > fail the stolen setup if the range isn't properly reserved. > > A stable branch somewhere would be good though so that I can pull it > into our integration tree for testing. Please post the x86 bits separately in a standalone series, if they can and should be applied standalone. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote: > Hi x86 folks, > > Ping on getting the gen2 stolen memory early quirk patches into the x86 > tree. > > From our side Daniel and Chris both seemed happy with them, so I'd like > to get them in at some point. Yup, I think this is ready for 3.15. And since there's no direct depency really between the i915 parts and the x86 early reserve stuff they can go both in through relevant trees - i915 will simply fail the stolen setup if the range isn't properly reserved. A stable branch somewhere would be good though so that I can pull it into our integration tree for testing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
Hi x86 folks, Ping on getting the gen2 stolen memory early quirk patches into the x86 tree. >From our side Daniel and Chris both seemed happy with them, so I'd like to get them in at some point. -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
Hi x86 folks, Ping on getting the gen2 stolen memory early quirk patches into the x86 tree. From our side Daniel and Chris both seemed happy with them, so I'd like to get them in at some point. -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote: Hi x86 folks, Ping on getting the gen2 stolen memory early quirk patches into the x86 tree. From our side Daniel and Chris both seemed happy with them, so I'd like to get them in at some point. Yup, I think this is ready for 3.15. And since there's no direct depency really between the i915 parts and the x86 early reserve stuff they can go both in through relevant trees - i915 will simply fail the stolen setup if the range isn't properly reserved. A stable branch somewhere would be good though so that I can pull it into our integration tree for testing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
* Daniel Vetter dan...@ffwll.ch wrote: On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote: Hi x86 folks, Ping on getting the gen2 stolen memory early quirk patches into the x86 tree. From our side Daniel and Chris both seemed happy with them, so I'd like to get them in at some point. Yup, I think this is ready for 3.15. And since there's no direct depency really between the i915 parts and the x86 early reserve stuff they can go both in through relevant trees - i915 will simply fail the stolen setup if the range isn't properly reserved. A stable branch somewhere would be good though so that I can pull it into our integration tree for testing. Please post the x86 bits separately in a standalone series, if they can and should be applied standalone. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
From: Ville Syrjälä
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000ce000-0x000c] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1f6e] usable
[0.00] BIOS-e820: [mem 0x1f6f-0x1f6f7fff] ACPI data
[0.00] BIOS-e820: [mem 0x1f6f8000-0x1f6f] ACPI NVS
[0.00] BIOS-e820: [mem 0x1f70-0x1fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec1] reserved
[0.00] BIOS-e820: [mem 0xffb0-0xffbf] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
That makes max_low_pfn_mapped = 1f6f, 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 0x1f70 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
0x1fee0, and given that the GTT entries occupy 128KB, it looks like
the stolen memory could start at 0x1f70 and the GTT entries would
occupy the last 128KB of the stolen memory.
After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.
Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.
865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.
I tested this on the my 830 and 855 machines, and so far everything
looks peachy.
v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
arch/x86/kernel/early-quirks.c | 132 +
include/drm/i915_drm.h | 20 +++
2 files changed, 152 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fddd4d0..5218dd2 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -247,6 +247,114 @@ static u32 __init intel_stolen_base(int num, int slot,
int func, size_t stolen_s
#define MB(x) (KB (KB (x)))
#define GB(x) (MB (KB (x)))
+static size_t __init i830_tseg_size(void)
+{
+ u8 tmp = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
+
+ if (!(tmp & TSEG_ENABLE))
+ return 0;
+
+ if (tmp & I830_TSEG_SIZE_1M)
+ return MB(1);
+ else
+ return KB(512);
+}
+
+static size_t __init i845_tseg_size(void)
+{
+ u8 tmp = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
+
+ if (!(tmp & TSEG_ENABLE))
+ return 0;
+
+ switch (tmp & I845_TSEG_SIZE_MASK) {
+ case I845_TSEG_SIZE_512K:
+ return KB(512);
+ case I845_TSEG_SIZE_1M:
+ return MB(1);
+ default:
+ WARN_ON(1);
+ return 0;
+ }
+}
+
+static size_t __init i85x_tseg_size(void)
+{
+ u8 tmp = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
+
+ if (!(tmp & TSEG_ENABLE))
+ return 0;
+
+ return MB(1);
+}
+
+static size_t __init i830_mem_size(void)
+{
+ return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
+}
+
+static size_t __init i85x_mem_size(void)
+{
+ return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
+}
+
+/*
+ * On 830/845/85x the stolen memory base isn't available in any
+ * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.
+ */
+static u32 __init
[PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
From: Ville Syrjälä ville.syrj...@linux.intel.com
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000ce000-0x000c] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1f6e] usable
[0.00] BIOS-e820: [mem 0x1f6f-0x1f6f7fff] ACPI data
[0.00] BIOS-e820: [mem 0x1f6f8000-0x1f6f] ACPI NVS
[0.00] BIOS-e820: [mem 0x1f70-0x1fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec1] reserved
[0.00] BIOS-e820: [mem 0xffb0-0xffbf] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
That makes max_low_pfn_mapped = 1f6f, 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 0x1f70 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
0x1fee0, and given that the GTT entries occupy 128KB, it looks like
the stolen memory could start at 0x1f70 and the GTT entries would
occupy the last 128KB of the stolen memory.
After some more digging through chipset documentation, I've determined
the BIOS first allocates space for something called TSEG (something to
do with SMM) from the top of memory, and then it allocates the graphics
stolen memory below that. Accordind to the chipset documentation TSEG
has a fixed size of 1MB on 855. So that explains the top 1MB in the
e820 region. And it also confirms that the GTT entries are in fact at
the end of the the stolen memory region.
Derive the stolen memory base address on gen2 the same as the BIOS does
(TOM-TSEG_SIZE-stolen_size). There are a few differences between the
registers on various gen2 chipsets, so a few different codepaths are
required.
865G is again bit more special since it seems to support enough memory
to hit 4GB address space issues. This means the PCI allocations will
also affect the location of the stolen memory. Fortunately there
appears to be the TOUD register which may give us the correct answer
directly. But the chipset docs are a bit unclear, so I'm not 100%
sure that the graphics stolen memory is always the last thing the
BIOS steals. Someone would need to verify it on a real system.
I tested this on the my 830 and 855 machines, and so far everything
looks peachy.
v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods
v3: Fix TSEG size for 830
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
arch/x86/kernel/early-quirks.c | 132 +
include/drm/i915_drm.h | 20 +++
2 files changed, 152 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index fddd4d0..5218dd2 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -247,6 +247,114 @@ static u32 __init intel_stolen_base(int num, int slot,
int func, size_t stolen_s
#define MB(x) (KB (KB (x)))
#define GB(x) (MB (KB (x)))
+static size_t __init i830_tseg_size(void)
+{
+ u8 tmp = read_pci_config_byte(0, 0, 0, I830_ESMRAMC);
+
+ if (!(tmp TSEG_ENABLE))
+ return 0;
+
+ if (tmp I830_TSEG_SIZE_1M)
+ return MB(1);
+ else
+ return KB(512);
+}
+
+static size_t __init i845_tseg_size(void)
+{
+ u8 tmp = read_pci_config_byte(0, 0, 0, I845_ESMRAMC);
+
+ if (!(tmp TSEG_ENABLE))
+ return 0;
+
+ switch (tmp I845_TSEG_SIZE_MASK) {
+ case I845_TSEG_SIZE_512K:
+ return KB(512);
+ case I845_TSEG_SIZE_1M:
+ return MB(1);
+ default:
+ WARN_ON(1);
+ return 0;
+ }
+}
+
+static size_t __init i85x_tseg_size(void)
+{
+ u8 tmp = read_pci_config_byte(0, 0, 0, I85X_ESMRAMC);
+
+ if (!(tmp TSEG_ENABLE))
+ return 0;
+
+ return MB(1);
+}
+
+static size_t __init i830_mem_size(void)
+{
+ return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
+}
+
+static size_t __init i85x_mem_size(void)
+{
+ return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
+}
+
+/*
+ * On 830/845/85x the stolen memory base isn't available in
