[PATCH 1/3] x86: EXPORT_SYMBOL(pat_enabled)

[PATCH 1/3] x86: EXPORT_SYMBOL(pat_enabled)

[Adam Jackson]

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 arch/x86/mm/pat.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index f6ff57b..b56c269 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -34,6 +34,7 @@
 
 #ifdef CONFIG_X86_PAT
 int __read_mostly pat_enabled = 1;
+EXPORT_SYMBOL(pat_enabled);
 
 static inline void pat_disable(const char *reason)
 {
-- 
1.7.7.6

[PATCH 2/3] drm/i915: Pull MTRR setup to its own function

[Adam Jackson]

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/i915/i915_dma.c |   29 +++++++++++++++++------------
 1 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ddfe3d9..d52f4a5 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1893,6 +1893,22 @@ ips_ping_for_i915_load(void)
 	}
 }
 
+static void
+i915_mtrr_setup(struct drm_i915_private *dev_priv, unsigned long base,
+		unsigned long size)
+{
+	/* Set up a WC MTRR for non-PAT systems.  This is more common than
+	 * one would think, because the kernel disables PAT on first
+	 * generation Core chips because WC PAT gets overridden by a UC
+	 * MTRR if present.  Even if a UC MTRR isn't present.
+	 */
+	dev_priv->mm.gtt_mtrr = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+	if (dev_priv->mm.gtt_mtrr < 0) {
+		DRM_INFO("MTRR allocation failed.  Graphics "
+			 "performance may suffer.\n");
+	}
+}
+
 /**
  * i915_driver_load - setup chip and create an initial config
  * @dev: DRM device
@@ -1969,18 +1985,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 		goto out_rmmap;
 	}
 
-	/* Set up a WC MTRR for non-PAT systems.  This is more common than
-	 * one would think, because the kernel disables PAT on first
-	 * generation Core chips because WC PAT gets overridden by a UC
-	 * MTRR if present.  Even if a UC MTRR isn't present.
-	 */
-	dev_priv->mm.gtt_mtrr = mtrr_add(dev->agp->base,
-					 agp_size,
-					 MTRR_TYPE_WRCOMB, 1);
-	if (dev_priv->mm.gtt_mtrr < 0) {
-		DRM_INFO("MTRR allocation failed.  Graphics "
-			 "performance may suffer.\n");
-	}
+	i915_mtrr_setup(dev_priv, dev->agp->base, agp_size);
 
 	/* The i915 workqueue is primarily used for batched retirement of
 	 * requests (and thus managing bo) once the task has been completed
-- 
1.7.7.6

[PATCH 3/3] drm/i915: Don't do MTRR setup if PAT is enabled

[Adam Jackson]

Some newer BIOSes are shipping with all MTRRs already populated.  These
BIOSes are all on machines with sufficiently new CPUs that the
referenced errata doesn't apply anyway, so just don't try to claim the
MTRR.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 drivers/gpu/drm/i915/i915_dma.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d52f4a5..cc0e70a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <acpi/video.h>
+#include <asm/pat.h>
 
 static void i915_write_hws_pga(struct drm_device *dev)
 {
@@ -1897,6 +1898,11 @@ static void
 i915_mtrr_setup(struct drm_i915_private *dev_priv, unsigned long base,
 		unsigned long size)
 {
+#if defined(CONFIG_X86_PAT)
+	if (pat_enabled)
+		return;
+#endif
+
 	/* Set up a WC MTRR for non-PAT systems.  This is more common than
 	 * one would think, because the kernel disables PAT on first
 	 * generation Core chips because WC PAT gets overridden by a UC
-- 
1.7.7.6

Re: [PATCH 3/3] drm/i915: Don't do MTRR setup if PAT is enabled

[Adam Jackson]

On 3/13/12 2:02 PM, H. Peter Anvin wrote:

> However, for the overall goal of the patch sequence, I think it is a
> good thing to not use MTRRs when PAT is available.  Part of me is
> wondering if we shouldn't simply turn off the X86_FEATURE_PAT in
> boot_cpu_info when PAT is disabled.

It looks like the only user of cpu_has_pat is the PAT code itself, so 
that should be safe in the sense of not breaking anyone's expectations. 
  And it would avoid needing to export another symbol.  I like.

Will respin to do that, with better descriptions.

- ajax