| 
									
										
										
										
											2006-01-02 20:14:23 +11:00
										 |  |  | /*
 | 
					
						
							| 
									
										
										
										
											2005-06-23 22:46:46 +10:00
										 |  |  |  * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. | 
					
						
							|  |  |  |  * All Rights Reserved. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * Permission is hereby granted, free of charge, to any person obtaining a | 
					
						
							|  |  |  |  * copy of this software and associated documentation files (the | 
					
						
							|  |  |  |  * "Software"), to deal in the Software without restriction, including | 
					
						
							|  |  |  |  * without limitation the rights to use, copy, modify, merge, publish, | 
					
						
							|  |  |  |  * distribute, sub license, and/or sell copies of the Software, and to | 
					
						
							|  |  |  |  * permit persons to whom the Software is furnished to do so, subject to | 
					
						
							|  |  |  |  * the following conditions: | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * The above copyright notice and this permission notice (including the | 
					
						
							|  |  |  |  * next paragraph) shall be included in all copies or substantial portions | 
					
						
							|  |  |  |  * of the Software. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS | 
					
						
							|  |  |  |  * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF | 
					
						
							|  |  |  |  * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. | 
					
						
							|  |  |  |  * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR | 
					
						
							|  |  |  |  * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, | 
					
						
							|  |  |  |  * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE | 
					
						
							|  |  |  |  * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. | 
					
						
							|  |  |  |  * | 
					
						
							| 
									
										
										
										
											2006-01-02 20:14:23 +11:00
										 |  |  |  */ | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | #ifndef _I915_DRM_H_
 | 
					
						
							|  |  |  | #define _I915_DRM_H_
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-07-26 13:32:51 -07:00
										 |  |  | #include <drm/i915_pciids.h>
 | 
					
						
							| 
									
										
										
										
											2012-10-04 18:21:50 +01:00
										 |  |  | #include <uapi/drm/i915_drm.h>
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2010-05-14 15:41:14 -07:00
										 |  |  | /* For use by IPS driver */ | 
					
						
							|  |  |  | extern unsigned long i915_read_mch_val(void); | 
					
						
							|  |  |  | extern bool i915_gpu_raise(void); | 
					
						
							|  |  |  | extern bool i915_gpu_lower(void); | 
					
						
							|  |  |  | extern bool i915_gpu_busy(void); | 
					
						
							|  |  |  | extern bool i915_gpu_turbo_disable(void); | 
					
						
							| 
									
										
										
										
											2013-07-26 13:32:51 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-07-26 13:32:52 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * The Bridge device's PCI config space has information about the | 
					
						
							|  |  |  |  * fb aperture size and the amount of pre-reserved memory. | 
					
						
							|  |  |  |  * This is all handled in the intel-gtt.ko module. i915.ko only | 
					
						
							|  |  |  |  * cares about the vga bit for the vga rbiter. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | #define INTEL_GMCH_CTRL		0x52
 | 
					
						
							|  |  |  | #define INTEL_GMCH_VGA_DISABLE  (1 << 1)
 | 
					
						
							|  |  |  | #define SNB_GMCH_CTRL		0x50
 | 
					
						
							|  |  |  | #define    SNB_GMCH_GGMS_SHIFT	8 /* GTT Graphics Memory Size */
 | 
					
						
							|  |  |  | #define    SNB_GMCH_GGMS_MASK	0x3
 | 
					
						
							|  |  |  | #define    SNB_GMCH_GMS_SHIFT   3 /* Graphics Mode Select */
 | 
					
						
							|  |  |  | #define    SNB_GMCH_GMS_MASK    0x1f
 | 
					
						
							| 
									
										
										
										
											2013-11-03 16:53:55 -08:00
										 |  |  | #define    BDW_GMCH_GGMS_SHIFT	6
 | 
					
						
							|  |  |  | #define    BDW_GMCH_GGMS_MASK	0x3
 | 
					
						
							|  |  |  | #define    BDW_GMCH_GMS_SHIFT   8
 | 
					
						
							|  |  |  | #define    BDW_GMCH_GMS_MASK    0xff
 | 
					
						
							| 
									
										
										
										
											2013-07-26 13:32:52 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | #define I830_GMCH_CTRL			0x52
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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-05 21:28:59 +02:00
										 |  |  | #define I830_GMCH_GMS_MASK		0x70
 | 
					
						
							|  |  |  | #define I830_GMCH_GMS_LOCAL		0x10
 | 
					
						
							|  |  |  | #define I830_GMCH_GMS_STOLEN_512	0x20
 | 
					
						
							|  |  |  | #define I830_GMCH_GMS_STOLEN_1024	0x30
 | 
					
						
							|  |  |  | #define I830_GMCH_GMS_STOLEN_8192	0x40
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-07-26 13:32:52 -07:00
										 |  |  | #define I855_GMCH_GMS_MASK		0xF0
 | 
					
						
							|  |  |  | #define I855_GMCH_GMS_STOLEN_0M		0x0
 | 
					
						
							|  |  |  | #define I855_GMCH_GMS_STOLEN_1M		(0x1 << 4)
 | 
					
						
							|  |  |  | #define I855_GMCH_GMS_STOLEN_4M		(0x2 << 4)
 | 
					
						
							|  |  |  | #define I855_GMCH_GMS_STOLEN_8M		(0x3 << 4)
 | 
					
						
							|  |  |  | #define I855_GMCH_GMS_STOLEN_16M	(0x4 << 4)
 | 
					
						
							|  |  |  | #define I855_GMCH_GMS_STOLEN_32M	(0x5 << 4)
 | 
					
						
							|  |  |  | #define I915_GMCH_GMS_STOLEN_48M	(0x6 << 4)
 | 
					
						
							|  |  |  | #define I915_GMCH_GMS_STOLEN_64M	(0x7 << 4)
 | 
					
						
							|  |  |  | #define G33_GMCH_GMS_STOLEN_128M	(0x8 << 4)
 | 
					
						
							|  |  |  | #define G33_GMCH_GMS_STOLEN_256M	(0x9 << 4)
 | 
					
						
							|  |  |  | #define INTEL_GMCH_GMS_STOLEN_96M	(0xa << 4)
 | 
					
						
							|  |  |  | #define INTEL_GMCH_GMS_STOLEN_160M	(0xb << 4)
 | 
					
						
							|  |  |  | #define INTEL_GMCH_GMS_STOLEN_224M	(0xc << 4)
 | 
					
						
							|  |  |  | #define INTEL_GMCH_GMS_STOLEN_352M	(0xd << 4)
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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-05 21:28:59 +02:00
										 |  |  | #define I830_DRB3		0x63
 | 
					
						
							|  |  |  | #define I85X_DRB3		0x43
 | 
					
						
							|  |  |  | #define I865_TOUD		0xc4
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #define I830_ESMRAMC		0x91
 | 
					
						
							|  |  |  | #define I845_ESMRAMC		0x9e
 | 
					
						
							|  |  |  | #define I85X_ESMRAMC		0x61
 | 
					
						
							|  |  |  | #define    TSEG_ENABLE		(1 << 0)
 | 
					
						
							|  |  |  | #define    I830_TSEG_SIZE_512K	(0 << 1)
 | 
					
						
							|  |  |  | #define    I830_TSEG_SIZE_1M	(1 << 1)
 | 
					
						
							|  |  |  | #define    I845_TSEG_SIZE_MASK	(3 << 1)
 | 
					
						
							|  |  |  | #define    I845_TSEG_SIZE_512K	(2 << 1)
 | 
					
						
							|  |  |  | #define    I845_TSEG_SIZE_1M	(3 << 1)
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2005-04-16 15:20:36 -07:00
										 |  |  | #endif				/* _I915_DRM_H_ */
 |