2013-05-03 23:00:49

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 0/7] Clean up write-combining MTRR addition

A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.

This series adds new functions mtrr_{add,del}_wc_if_needed and
drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is
enabled.

I've only tested the radeon driver, since I don't have test hardware
easily available for the other drivers.

Benefits include:
- Simpler code
- No more complaints about MTRR conflict warnings on PAT systems
- Eventual unexporting of the MTRR API?

This series eliminates about half of the mtrr_add calls in drivers/.

The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup

Andy Lutomirski (7):
x86: Add mtrr_{add,del}_wc_if_needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework
drm_mtrr_{add,del}
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
drm: Use drm_mtrr_add_wc for the AGP aperture
i915: Use drm_mtrr_{add,del}_wc
radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc
uvesafb: Clean up MTRR code

Documentation/fb/uvesafb.txt | 16 +++-----
arch/x86/include/asm/mtrr.h | 21 ++++++++++
arch/x86/kernel/cpu/mtrr/main.c | 53 +++++++++++++++++++++++++
drivers/gpu/drm/ast/ast_ttm.c | 14 ++-----
drivers/gpu/drm/cirrus/cirrus_ttm.c | 15 ++------
drivers/gpu/drm/drm_bufs.c | 11 ++----
drivers/gpu/drm/drm_pci.c | 8 ++--
drivers/gpu/drm/drm_stub.c | 10 +----
drivers/gpu/drm/drm_vm.c | 13 ++++---
drivers/gpu/drm/i915/i915_dma.c | 43 +++------------------
drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 ++-----
drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ++-----
drivers/gpu/drm/radeon/radeon_object.c | 5 ++-
drivers/gpu/drm/savage/savage_bci.c | 42 ++++++++------------
drivers/gpu/drm/savage/savage_drv.h | 5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 ++---
drivers/video/uvesafb.c | 70 +++++++++-------------------------
include/drm/drmP.h | 23 +++++------
include/video/uvesafb.h | 1 +
19 files changed, 169 insertions(+), 218 deletions(-)

--
1.8.1.4


2013-05-03 23:00:58

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 1/7] x86: Add mtrr_{add,del}_wc_if_needed

These MTRR helpers add a WC MTRR if PAT is disabled. Modern drivers should
be using ioremap_wc, etc. to get WC memory; the MTRR is just a fallback
if the system doesn't have PAT. So, rather than allocating an unnecessary
MTRR even on PAT systems and having error handling spread out and handled
differently by different drivers, consolidate it all and don't waste the
MTRR on PAT-supporting systems. (Follow-up changes will update drivers.)

This should be a simple change, a bit of a clean-up, and it will flush
out any drivers that actually depend on the MTRR for write combining.

Signed-off-by: Andy Lutomirski <[email protected]>
---
arch/x86/include/asm/mtrr.h | 21 ++++++++++++++++
arch/x86/kernel/cpu/mtrr/main.c | 53 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 74 insertions(+)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index e235582..cc96c72 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -45,6 +45,18 @@ extern void mtrr_aps_init(void);
extern void mtrr_bp_restore(void);
extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
extern int amd_special_default_mtrr(void);
+
+/*
+ * These are for drivers (mostly video) that want to add WC MTRRs as a
+ * fallback if PAT is unavailable. There is no need to check for errors.
+ *
+ * The handles used by the _if_needed functions are *not* MTRR indices.
+ * mtrr_del_wc_if_needed(0) and mtrr_del_wc_if_needed(-1) are
+ * guaranteed to have no effect.
+ */
+extern int __must_check mtrr_add_wc_if_needed(unsigned long base,
+ unsigned long size);
+extern void mtrr_del_wc_if_needed(int handle);
# else
static inline u8 mtrr_type_lookup(u64 addr, u64 end)
{
@@ -86,6 +98,15 @@ static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
#define set_mtrr_aps_delayed_init() do {} while (0)
#define mtrr_aps_init() do {} while (0)
#define mtrr_bp_restore() do {} while (0)
+
+static inline int __must_check mtrr_add_wc_if_needed(unsigned long base,
+ unsigned long size)
+{
+ return -ENODEV;
+}
+static inline void mtrr_del_wc_if_needed(int handle)
+{
+}
# endif

#ifdef CONFIG_COMPAT
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 726bf96..6370238 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -51,6 +51,7 @@
#include <asm/e820.h>
#include <asm/mtrr.h>
#include <asm/msr.h>
+#include <asm/pat.h>

#include "mtrr.h"

@@ -524,6 +525,58 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)
}
EXPORT_SYMBOL(mtrr_del);

+/**
+ * mtrr_add_wc_if_needed - add a WC MTRR and handle errors if PAT is unavailable
+ * @base: Physical base address
+ * @size: Size of region
+ *
+ * If PAT is available, this does nothing. If PAT is unavailable, it
+ * attempts to add a WC MTRR covering size bytes starting at base and
+ * logs an error if this fails.
+ *
+ * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
+ * but drivers should not try to interpret that return value.
+ */
+int mtrr_add_wc_if_needed(unsigned long base, unsigned long size)
+{
+ int ret;
+
+ if (pat_enabled) {
+ /*
+ * Don't bother -- we don't need the MTRR. Return an error
+ * so that no one gets confused.
+ */
+ return -EBUSY; /* The error doesn't matter. */
+ }
+
+ ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true);
+ if (ret < 0) {
+ pr_warn("Failed to add WC MTRR for [%p-%p]; performance will suffer.",
+ (void *)base, (void *)(base + size - 1));
+ return ret;
+ }
+ return ret + 1000;
+}
+EXPORT_SYMBOL(mtrr_add_wc_if_needed);
+
+/*
+ * mtrr_del_wc_if_needed - undoes mtrr_add_wc_if_needed
+ * @handle: Return value from mtrr_add_wc_if_needed
+ *
+ * This cleans up after mtrr_add_wc_if_needed.
+ *
+ * The API guarantees that mtrr_del_wc_if_needed(-1) and
+ * mtrr_del_wc_if_needed(0) do nothing.
+ */
+extern void mtrr_del_wc_if_needed(int handle)
+{
+ if (handle >= 1) {
+ WARN_ON(handle < 1000);
+ mtrr_del(handle - 1000, 0, 0);
+ }
+}
+EXPORT_SYMBOL(mtrr_del_wc_if_needed);
+
/*
* HACK ALERT!
* These should be called implicitly, but we can't yet until all the initcall
--
1.8.1.4

2013-05-03 23:01:10

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 5/7] i915: Use drm_mtrr_{add,del}_wc

i915 open-coded logic that was essentially equivalent to the new
drm_mtrr_{add,del}_wc.

Signed-off-by: Andy Lutomirski <[email protected]>
---
drivers/gpu/drm/i915/i915_dma.c | 43 ++++++-----------------------------------
1 file changed, 6 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4fa6beb..0fc95ba 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1393,29 +1393,6 @@ void i915_master_destroy(struct drm_device *dev, struct drm_master *master)
master->driver_priv = NULL;
}

-static void
-i915_mtrr_setup(struct drm_i915_private *dev_priv, unsigned long base,
- unsigned long size)
-{
- dev_priv->mm.gtt_mtrr = -1;
-
-#if defined(CONFIG_X86_PAT)
- if (cpu_has_pat)
- 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
- * 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");
- }
-}
-
static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
{
struct apertures_struct *ap;
@@ -1552,8 +1529,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
goto out_rmmap;
}

- i915_mtrr_setup(dev_priv, dev_priv->gtt.mappable_base,
- aperture_size);
+ dev_priv->mm.gtt_mtrr = drm_mtrr_add_wc(dev_priv->gtt.mappable_base,
+ aperture_size);

/* The i915 workqueue is primarily used for batched retirement of
* requests (and thus managing bo) once the task has been completed
@@ -1656,12 +1633,8 @@ out_gem_unload:
intel_teardown_mchbar(dev);
destroy_workqueue(dev_priv->wq);
out_mtrrfree:
- if (dev_priv->mm.gtt_mtrr >= 0) {
- mtrr_del(dev_priv->mm.gtt_mtrr,
- dev_priv->gtt.mappable_base,
- aperture_size);
- dev_priv->mm.gtt_mtrr = -1;
- }
+ drm_mtrr_del_wc(dev_priv->mm.gtt_mtrr);
+ dev_priv->mm.gtt_mtrr = -1;
io_mapping_free(dev_priv->gtt.mappable);
out_rmmap:
pci_iounmap(dev->pdev, dev_priv->regs);
@@ -1697,12 +1670,8 @@ int i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(&dev_priv->mm.retire_work);

io_mapping_free(dev_priv->gtt.mappable);
- if (dev_priv->mm.gtt_mtrr >= 0) {
- mtrr_del(dev_priv->mm.gtt_mtrr,
- dev_priv->gtt.mappable_base,
- dev_priv->gtt.mappable_end);
- dev_priv->mm.gtt_mtrr = -1;
- }
+ drm_mtrr_del_wc(dev_priv->mm.gtt_mtrr);
+ dev_priv->mm.gtt_mtrr = -1;

acpi_video_unregister();

--
1.8.1.4

2013-05-03 23:01:18

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 7/7] uvesafb: Clean up MTRR code

The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).

UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.

As an added bonus, any MTRR added is freed on unload.

Signed-off-by: Andy Lutomirski <[email protected]>
---

I can't test this -- the link to v86d in Documentation/fb/uvesafb.txt
seems to be broken, and Fedora doesn't seem to package it.

Documentation/fb/uvesafb.txt | 16 ++++------
drivers/video/uvesafb.c | 70 ++++++++++++--------------------------------
include/video/uvesafb.h | 1 +
3 files changed, 24 insertions(+), 63 deletions(-)

diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index eefdd91..f6362d8 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -81,17 +81,11 @@ pmipal Use the protected mode interface for palette changes.

mtrr:n Setup memory type range registers for the framebuffer
where n:
- 0 - disabled (equivalent to nomtrr) (default)
- 1 - uncachable
- 2 - write-back
- 3 - write-combining
- 4 - write-through
-
- If you see the following in dmesg, choose the type that matches
- the old one. In this example, use "mtrr:2".
-...
-mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
-...
+ 0 - disabled (equivalent to nomtrr)
+ 3 - write-combining (default)
+
+ Values other than 0 and 3 will result in a warning and will be
+ treated just like 3.

nomtrr Do not use memory type range registers.

diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index d428445..4f447ad 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -24,9 +24,7 @@
#ifdef CONFIG_X86
#include <video/vga.h>
#endif
-#ifdef CONFIG_MTRR
#include <asm/mtrr.h>
-#endif
#include "edid.h"

static struct cb_id uvesafb_cn_id = {
@@ -1540,67 +1538,31 @@ static void uvesafb_init_info(struct fb_info *info, struct vbe_mode_ib *mode)

static void uvesafb_init_mtrr(struct fb_info *info)
{
-#ifdef CONFIG_MTRR
+ struct uvesafb_par *par = info->par;
+
if (mtrr && !(info->fix.smem_start & (PAGE_SIZE - 1))) {
int temp_size = info->fix.smem_len;
- unsigned int type = 0;

- switch (mtrr) {
- case 1:
- type = MTRR_TYPE_UNCACHABLE;
- break;
- case 2:
- type = MTRR_TYPE_WRBACK;
- break;
- case 3:
- type = MTRR_TYPE_WRCOMB;
- break;
- case 4:
- type = MTRR_TYPE_WRTHROUGH;
- break;
- default:
- type = 0;
- break;
- }
+ int rc;

- if (type) {
- int rc;
+ /* Find the largest power-of-two */
+ temp_size = roundup_pow_of_two(temp_size);

- /* Find the largest power-of-two */
- temp_size = roundup_pow_of_two(temp_size);
+ /* Try and find a power of two to add */
+ do {
+ rc = mtrr_add_wc_if_needed(info->fix.smem_start,
+ temp_size);
+ temp_size >>= 1;
+ } while (temp_size >= PAGE_SIZE && rc == -EINVAL);

- /* Try and find a power of two to add */
- do {
- rc = mtrr_add(info->fix.smem_start,
- temp_size, type, 1);
- temp_size >>= 1;
- } while (temp_size >= PAGE_SIZE && rc == -EINVAL);
- }
+ if (rc >= 0)
+ par->mtrr_handle = rc;
}
-#endif /* CONFIG_MTRR */
}

static void uvesafb_ioremap(struct fb_info *info)
{
-#ifdef CONFIG_X86
- switch (mtrr) {
- case 1: /* uncachable */
- info->screen_base = ioremap_nocache(info->fix.smem_start, info->fix.smem_len);
- break;
- case 2: /* write-back */
- info->screen_base = ioremap_cache(info->fix.smem_start, info->fix.smem_len);
- break;
- case 3: /* write-combining */
- info->screen_base = ioremap_wc(info->fix.smem_start, info->fix.smem_len);
- break;
- case 4: /* write-through */
- default:
- info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
- break;
- }
-#else
- info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
-#endif /* CONFIG_X86 */
+ info->screen_base = ioremap_wc(info->fix.smem_start, info->fix.smem_len);
}

static ssize_t uvesafb_show_vbe_ver(struct device *dev,
@@ -1851,6 +1813,7 @@ static int uvesafb_remove(struct platform_device *dev)
unregister_framebuffer(info);
release_region(0x3c0, 32);
iounmap(info->screen_base);
+ mtrr_del_wc_if_needed(par->mtrr_handle);
release_mem_region(info->fix.smem_start, info->fix.smem_len);
fb_destroy_modedb(info->monspecs.modedb);
fb_dealloc_cmap(&info->cmap);
@@ -1930,6 +1893,9 @@ static int uvesafb_setup(char *options)
}
}

+ if (mtrr != 3 && mtrr != 1)
+ pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is unsupported", mtrr);
+
return 0;
}
#endif /* !MODULE */
diff --git a/include/video/uvesafb.h b/include/video/uvesafb.h
index 1a91850..30f5362 100644
--- a/include/video/uvesafb.h
+++ b/include/video/uvesafb.h
@@ -134,6 +134,7 @@ struct uvesafb_par {

int mode_idx;
struct vbe_crtc_ib crtc;
+ int mtrr_handle;
};

#endif /* _UVESAFB_H */
--
1.8.1.4

2013-05-03 23:01:38

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 6/7] radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc

Signed-off-by: Andy Lutomirski <[email protected]>
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..01d4906 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -321,8 +321,8 @@ void radeon_bo_force_delete(struct radeon_device *rdev)
int radeon_bo_init(struct radeon_device *rdev)
{
/* Add an MTRR for the VRAM */
- rdev->mc.vram_mtrr = mtrr_add(rdev->mc.aper_base, rdev->mc.aper_size,
- MTRR_TYPE_WRCOMB, 1);
+ rdev->mc.vram_mtrr = drm_mtrr_add_wc(rdev->mc.aper_base,
+ rdev->mc.aper_size);
DRM_INFO("Detected VRAM RAM=%lluM, BAR=%lluM\n",
rdev->mc.mc_vram_size >> 20,
(unsigned long long)rdev->mc.aper_size >> 20);
@@ -334,6 +334,7 @@ int radeon_bo_init(struct radeon_device *rdev)
void radeon_bo_fini(struct radeon_device *rdev)
{
radeon_ttm_fini(rdev);
+ drm_mtrr_del_wc(rdev->mc.vram_mtrr);
}

void radeon_bo_list_add_object(struct radeon_bo_list *lobj,
--
1.8.1.4

2013-05-03 23:01:05

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

Signed-off-by: Andy Lutomirski <[email protected]>
---

This needs careful review. I don't really know what this code does, nor
do I have the hardware. (I don't understand AGP and the associated
caching implications.)

drivers/gpu/drm/drm_bufs.c | 11 ++++-------
drivers/gpu/drm/drm_vm.c | 13 +++++++------
2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 0128147..0ae9cbb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -210,8 +210,8 @@ static int drm_addmap_core(struct drm_device * dev, resource_size_t offset,
if (drm_core_has_MTRR(dev)) {
if (map->type == _DRM_FRAME_BUFFER ||
(map->flags & _DRM_WRITE_COMBINING)) {
- map->mtrr = mtrr_add(map->offset, map->size,
- MTRR_TYPE_WRCOMB, 1);
+ map->mtrr =
+ drm_mtrr_add_wc(map->offset, map->size);
}
}
if (map->type == _DRM_REGISTERS) {
@@ -451,11 +451,8 @@ int drm_rmmap_locked(struct drm_device *dev, struct drm_local_map *map)
iounmap(map->handle);
/* FALLTHROUGH */
case _DRM_FRAME_BUFFER:
- if (drm_core_has_MTRR(dev) && map->mtrr >= 0) {
- int retcode;
- retcode = mtrr_del(map->mtrr, map->offset, map->size);
- DRM_DEBUG("mtrr_del=%d\n", retcode);
- }
+ if (drm_core_has_MTRR(dev))
+ drm_mtrr_del_wc(map->mtrr);
break;
case _DRM_SHM:
vfree(map->handle);
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..b255fd7 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -43,15 +43,16 @@
static void drm_vm_open(struct vm_area_struct *vma);
static void drm_vm_close(struct vm_area_struct *vma);

-static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma)
+static pgprot_t drm_io_prot(struct drm_local_map *map,
+ struct vm_area_struct *vma)
{
pgprot_t tmp = vm_get_page_prot(vma->vm_flags);

#if defined(__i386__) || defined(__x86_64__)
- if (boot_cpu_data.x86 > 3 && map_type != _DRM_AGP) {
- pgprot_val(tmp) |= _PAGE_PCD;
- pgprot_val(tmp) &= ~_PAGE_PWT;
- }
+ if (map->flags & _DRM_WRITE_COMBINING)
+ tmp = pgprot_writecombine(tmp);
+ else if (map->type != _DRM_AGP)
+ tmp = pgprot_noncached(tmp);
#elif defined(__powerpc__)
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map_type == _DRM_REGISTERS)
@@ -617,7 +618,7 @@ int drm_mmap_locked(struct file *filp, struct vm_area_struct *vma)
case _DRM_REGISTERS:
offset = drm_core_get_reg_ofs(dev);
vma->vm_flags |= VM_IO; /* not in core dump */
- vma->vm_page_prot = drm_io_prot(map->type, vma);
+ vma->vm_page_prot = drm_io_prot(map, vma);
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
--
1.8.1.4

2013-05-03 23:02:03

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 4/7] drm: Use drm_mtrr_add_wc for the AGP aperture

Signed-off-by: Andy Lutomirski <[email protected]>
---
drivers/gpu/drm/drm_pci.c | 8 ++++----
drivers/gpu/drm/drm_stub.c | 10 ++--------
2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..3628683 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -278,10 +278,10 @@ int drm_pci_agp_init(struct drm_device *dev)
}
if (drm_core_has_MTRR(dev)) {
if (dev->agp)
- dev->agp->agp_mtrr =
- mtrr_add(dev->agp->agp_info.aper_base,
- dev->agp->agp_info.aper_size *
- 1024 * 1024, MTRR_TYPE_WRCOMB, 1);
+ dev->agp->agp_mtrr = drm_mtrr_add_wc(
+ dev->agp->agp_info.aper_base,
+ dev->agp->agp_info.aper_size *
+ 1024 * 1024);
}
}
return 0;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 7d30802..96e21bd 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -451,14 +451,8 @@ void drm_put_dev(struct drm_device *dev)

drm_lastclose(dev);

- if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) &&
- dev->agp && dev->agp->agp_mtrr >= 0) {
- int retval;
- retval = mtrr_del(dev->agp->agp_mtrr,
- dev->agp->agp_info.aper_base,
- dev->agp->agp_info.aper_size * 1024 * 1024);
- DRM_DEBUG("mtrr_del=%d\n", retval);
- }
+ if (drm_core_has_MTRR(dev) && drm_core_has_AGP(dev) && dev->agp)
+ drm_mtrr_del_wc(dev->agp->agp_mtrr);

if (dev->driver->unload)
dev->driver->unload(dev);
--
1.8.1.4

2013-05-03 23:02:28

by Andy Lutomirski

[permalink] [raw]
Subject: [PATCH 2/7] drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework drm_mtrr_{add,del}

This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything) and it uses
mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
that don't need them.

Signed-off-by: Andy Lutomirski <[email protected]>
---
drivers/gpu/drm/ast/ast_ttm.c | 14 ++++--------
drivers/gpu/drm/cirrus/cirrus_ttm.c | 15 ++++---------
drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 ++++--------
drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ++++-------
drivers/gpu/drm/savage/savage_bci.c | 42 +++++++++++++----------------------
drivers/gpu/drm/savage/savage_drv.h | 5 +----
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 ++++-----
include/drm/drmP.h | 23 ++++++++-----------
8 files changed, 45 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 3602731..5286c96 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -271,26 +271,20 @@ int ast_mm_init(struct ast_private *ast)
return ret;
}

- ast->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0),
- DRM_MTRR_WC);
+ ast->fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 0),
+ pci_resource_len(dev->pdev, 0));

return 0;
}

void ast_mm_fini(struct ast_private *ast)
{
- struct drm_device *dev = ast->dev;
ttm_bo_device_release(&ast->ttm.bdev);

ast_ttm_global_release(ast);

- if (ast->fb_mtrr >= 0) {
- drm_mtrr_del(ast->fb_mtrr,
- pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0), DRM_MTRR_WC);
- ast->fb_mtrr = -1;
- }
+ drm_mtrr_del_wc(ast->fb_mtrr);
+ ast->fb_mtrr = -1;
}

void ast_ttm_placement(struct ast_bo *bo, int domain)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 1413a26..95e87ee 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -271,9 +271,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
return ret;
}

- cirrus->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0),
- DRM_MTRR_WC);
+ cirrus->fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 0),
+ pci_resource_len(dev->pdev, 0));

cirrus->mm_inited = true;
return 0;
@@ -281,8 +280,6 @@ int cirrus_mm_init(struct cirrus_device *cirrus)

void cirrus_mm_fini(struct cirrus_device *cirrus)
{
- struct drm_device *dev = cirrus->dev;
-
if (!cirrus->mm_inited)
return;

@@ -290,12 +287,8 @@ void cirrus_mm_fini(struct cirrus_device *cirrus)

cirrus_ttm_global_release(cirrus);

- if (cirrus->fb_mtrr >= 0) {
- drm_mtrr_del(cirrus->fb_mtrr,
- pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0), DRM_MTRR_WC);
- cirrus->fb_mtrr = -1;
- }
+ drm_mtrr_del_wc(cirrus->fb_mtrr);
+ cirrus->fb_mtrr = -1;
}

void cirrus_ttm_placement(struct cirrus_bo *bo, int domain)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 8fc9d92..62245b4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -270,26 +270,20 @@ int mgag200_mm_init(struct mga_device *mdev)
return ret;
}

- mdev->fb_mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0),
- DRM_MTRR_WC);
+ mdev->fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 0),
+ pci_resource_len(dev->pdev, 0));

return 0;
}

void mgag200_mm_fini(struct mga_device *mdev)
{
- struct drm_device *dev = mdev->dev;
ttm_bo_device_release(&mdev->ttm.bdev);

mgag200_ttm_global_release(mdev);

- if (mdev->fb_mtrr >= 0) {
- drm_mtrr_del(mdev->fb_mtrr,
- pci_resource_start(dev->pdev, 0),
- pci_resource_len(dev->pdev, 0), DRM_MTRR_WC);
- mdev->fb_mtrr = -1;
- }
+ drm_mtrr_del_wc(mdev->fb_mtrr);
+ mdev->fb_mtrr = -1;
}

void mgag200_ttm_placement(struct mgag200_bo *bo, int domain)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 9be9cb5..1506d78 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -377,9 +377,8 @@ nouveau_ttm_init(struct nouveau_drm *drm)
return ret;
}

- drm->ttm.mtrr = drm_mtrr_add(pci_resource_start(dev->pdev, 1),
- pci_resource_len(dev->pdev, 1),
- DRM_MTRR_WC);
+ drm->ttm.mtrr = drm_mtrr_add_wc(pci_resource_start(dev->pdev, 1),
+ pci_resource_len(dev->pdev, 1));

/* GART init */
if (drm->agp.stat != ENABLED) {
@@ -414,10 +413,6 @@ nouveau_ttm_fini(struct nouveau_drm *drm)

nouveau_ttm_global_release(drm);

- if (drm->ttm.mtrr >= 0) {
- drm_mtrr_del(drm->ttm.mtrr,
- pci_resource_start(drm->dev->pdev, 1),
- pci_resource_len(drm->dev->pdev, 1), DRM_MTRR_WC);
- drm->ttm.mtrr = -1;
- }
+ drm_mtrr_del_wc(drm->ttm.mtrr);
+ drm->ttm.mtrr = -1;
}
diff --git a/drivers/gpu/drm/savage/savage_bci.c b/drivers/gpu/drm/savage/savage_bci.c
index b55c1d6..5b15215 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/drivers/gpu/drm/savage/savage_bci.c
@@ -570,9 +570,9 @@ int savage_driver_firstopen(struct drm_device *dev)
unsigned int fb_rsrc, aper_rsrc;
int ret = 0;

- dev_priv->mtrr[0].handle = -1;
- dev_priv->mtrr[1].handle = -1;
- dev_priv->mtrr[2].handle = -1;
+ dev_priv->mtrr_handles[0] = -1;
+ dev_priv->mtrr_handles[1] = -1;
+ dev_priv->mtrr_handles[2] = -1;
if (S3_SAVAGE3D_SERIES(dev_priv->chipset)) {
fb_rsrc = 0;
fb_base = pci_resource_start(dev->pdev, 0);
@@ -584,21 +584,14 @@ int savage_driver_firstopen(struct drm_device *dev)
if (pci_resource_len(dev->pdev, 0) == 0x08000000) {
/* Don't make MMIO write-cobining! We need 3
* MTRRs. */
- dev_priv->mtrr[0].base = fb_base;
- dev_priv->mtrr[0].size = 0x01000000;
- dev_priv->mtrr[0].handle =
- drm_mtrr_add(dev_priv->mtrr[0].base,
- dev_priv->mtrr[0].size, DRM_MTRR_WC);
- dev_priv->mtrr[1].base = fb_base + 0x02000000;
- dev_priv->mtrr[1].size = 0x02000000;
- dev_priv->mtrr[1].handle =
- drm_mtrr_add(dev_priv->mtrr[1].base,
- dev_priv->mtrr[1].size, DRM_MTRR_WC);
- dev_priv->mtrr[2].base = fb_base + 0x04000000;
- dev_priv->mtrr[2].size = 0x04000000;
- dev_priv->mtrr[2].handle =
- drm_mtrr_add(dev_priv->mtrr[2].base,
- dev_priv->mtrr[2].size, DRM_MTRR_WC);
+ dev_priv->mtrr_handles[0] =
+ drm_mtrr_add_wc(fb_base, 0x01000000);
+ dev_priv->mtrr_handles[1] =
+ drm_mtrr_add_wc(fb_base + 0x02000000,
+ 0x02000000);
+ dev_priv->mtrr_handles[2] =
+ drm_mtrr_add_wc(fb_base + 0x04000000,
+ 0x04000000);
} else {
DRM_ERROR("strange pci_resource_len %08llx\n",
(unsigned long long)
@@ -616,11 +609,9 @@ int savage_driver_firstopen(struct drm_device *dev)
if (pci_resource_len(dev->pdev, 1) == 0x08000000) {
/* Can use one MTRR to cover both fb and
* aperture. */
- dev_priv->mtrr[0].base = fb_base;
- dev_priv->mtrr[0].size = 0x08000000;
- dev_priv->mtrr[0].handle =
- drm_mtrr_add(dev_priv->mtrr[0].base,
- dev_priv->mtrr[0].size, DRM_MTRR_WC);
+ dev_priv->mtrr_handles[0] =
+ drm_mtrr_add_wc(fb_base,
+ 0x08000000);
} else {
DRM_ERROR("strange pci_resource_len %08llx\n",
(unsigned long long)
@@ -661,10 +652,7 @@ void savage_driver_lastclose(struct drm_device *dev)
int i;

for (i = 0; i < 3; ++i)
- if (dev_priv->mtrr[i].handle >= 0)
- drm_mtrr_del(dev_priv->mtrr[i].handle,
- dev_priv->mtrr[i].base,
- dev_priv->mtrr[i].size, DRM_MTRR_WC);
+ drm_mtrr_del_wc(dev_priv->mtrr_handles[i]);
}

int savage_driver_unload(struct drm_device *dev)
diff --git a/drivers/gpu/drm/savage/savage_drv.h b/drivers/gpu/drm/savage/savage_drv.h
index df2aac6..c05082a 100644
--- a/drivers/gpu/drm/savage/savage_drv.h
+++ b/drivers/gpu/drm/savage/savage_drv.h
@@ -160,10 +160,7 @@ typedef struct drm_savage_private {
drm_local_map_t *cmd_dma;
drm_local_map_t fake_dma;

- struct {
- int handle;
- unsigned long base, size;
- } mtrr[3];
+ int mtrr_handles[3];

/* BCI and status-related stuff */
volatile uint32_t *status_ptr, *bci_ptr;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 07dfd82..c104ae4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -565,8 +565,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset)
dev_priv->has_gmr = false;
}

- dev_priv->mmio_mtrr = drm_mtrr_add(dev_priv->mmio_start,
- dev_priv->mmio_size, DRM_MTRR_WC);
+ dev_priv->mmio_mtrr = drm_mtrr_add_wc(dev_priv->mmio_start,
+ dev_priv->mmio_size);

dev_priv->mmio_virt = ioremap_wc(dev_priv->mmio_start,
dev_priv->mmio_size);
@@ -664,8 +664,7 @@ out_no_device:
out_err4:
iounmap(dev_priv->mmio_virt);
out_err3:
- drm_mtrr_del(dev_priv->mmio_mtrr, dev_priv->mmio_start,
- dev_priv->mmio_size, DRM_MTRR_WC);
+ drm_mtrr_del_wc(dev_priv->mmio_mtrr);
if (dev_priv->has_gmr)
(void) ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_GMR);
(void)ttm_bo_clean_mm(&dev_priv->bdev, TTM_PL_VRAM);
@@ -709,8 +708,7 @@ static int vmw_driver_unload(struct drm_device *dev)

ttm_object_device_release(&dev_priv->tdev);
iounmap(dev_priv->mmio_virt);
- drm_mtrr_del(dev_priv->mmio_mtrr, dev_priv->mmio_start,
- dev_priv->mmio_size, DRM_MTRR_WC);
+ drm_mtrr_del_wc(dev_priv->mmio_mtrr);
if (dev_priv->has_gmr)
(void)ttm_bo_clean_mm(&dev_priv->bdev, VMW_PL_GMR);
(void)ttm_bo_clean_mm(&dev_priv->bdev, TTM_PL_VRAM);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..2a3e1fd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device *dev)
return drm_core_check_feature(dev, DRIVER_USE_MTRR);
}

-#define DRM_MTRR_WC MTRR_TYPE_WRCOMB
-
-static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
- unsigned int flags)
+static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
+ unsigned long size)
{
- return mtrr_add(offset, size, flags, 1);
+ return mtrr_add_wc_if_needed(offset, size);
}

-static inline int drm_mtrr_del(int handle, unsigned long offset,
- unsigned long size, unsigned int flags)
+static inline void drm_mtrr_del_wc(int handle)
{
- return mtrr_del(handle, offset, size);
+ mtrr_del_wc_if_needed(handle);
}

#else
@@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned long offset,

#define DRM_MTRR_WC 0

-static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
- unsigned int flags)
+static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
+ unsigned long size)
{
- return 0;
+ return -1;
}

-static inline int drm_mtrr_del(int handle, unsigned long offset,
- unsigned long size, unsigned int flags)
+static inline void drm_mtrr_del_wc(int handle)
{
- return 0;
}
#endif

--
1.8.1.4

2013-05-04 17:42:53

by Daniel Vetter

[permalink] [raw]
Subject: Re: [PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}

On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
> interface is simplified (because the base and size parameters to
> drm_mtrr_del never did anything) and it uses
> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
> that don't need them.
>
> Signed-off-by: Andy Lutomirski <[email protected]>
> ---

[snip]

> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 2d94d74..2a3e1fd 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device *dev)
> return drm_core_check_feature(dev, DRIVER_USE_MTRR);
> }
>
> -#define DRM_MTRR_WC MTRR_TYPE_WRCOMB
> -
> -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
> - unsigned int flags)
> +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
> + unsigned long size)
> {
> - return mtrr_add(offset, size, flags, 1);
> + return mtrr_add_wc_if_needed(offset, size);
> }
>
> -static inline int drm_mtrr_del(int handle, unsigned long offset,
> - unsigned long size, unsigned int flags)
> +static inline void drm_mtrr_del_wc(int handle)
> {
> - return mtrr_del(handle, offset, size);
> + mtrr_del_wc_if_needed(handle);
> }
>
> #else
> @@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned long offset,
>
> #define DRM_MTRR_WC 0
>
> -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
> - unsigned int flags)
> +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
> + unsigned long size)
> {
> - return 0;
> + return -1;
> }
>
> -static inline int drm_mtrr_del(int handle, unsigned long offset,
> - unsigned long size, unsigned int flags)
> +static inline void drm_mtrr_del_wc(int handle)
> {
> - return 0;
> }

Tbh I'm not a big fan of the drm_ indirection. Historically that was
useful as an OS abstraction layer so that the same drivers could be used
unchanged on Linux and the *BSD. But those days are long gone and drm
drivers are now proper Linux drivers, and generally OS HALs seem to be
frowned upon.

Is there another reason than just being consistent with the historic stuff
here? If we need dummy functions for !CONFIG_MTRR I think those should
simply be in the core.

And if the inconsistency bugs you I'd volunteer myself to ditch the old
drm_ mtrr helpers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

2013-05-04 17:48:56

by Andy Lutomirski

[permalink] [raw]
Subject: Re: [PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}

On Sat, May 4, 2013 at 10:45 AM, Daniel Vetter <[email protected]> wrote:
> On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
>> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
>> interface is simplified (because the base and size parameters to
>> drm_mtrr_del never did anything) and it uses
>> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
>> that don't need them.
>>
>> Signed-off-by: Andy Lutomirski <[email protected]>
>> ---
>
>
> Tbh I'm not a big fan of the drm_ indirection. Historically that was
> useful as an OS abstraction layer so that the same drivers could be used
> unchanged on Linux and the *BSD. But those days are long gone and drm
> drivers are now proper Linux drivers, and generally OS HALs seem to be
> frowned upon.
>
> Is there another reason than just being consistent with the historic stuff
> here? If we need dummy functions for !CONFIG_MTRR I think those should
> simply be in the core.


I admit to a bit of cargo-culting. There was a layer of indirection,
so I kept it. I'll just call mtrr_add/del_wc_if_needed directly in v2
(I added those functions in patch 1 of this series).

I'd assume you're okay with skipping mtrr addition if PAT is available
since i915 already does it :) (Although the current logic is buggy --
cpu_has_pat is the wrong flag to check -- I think pat_enabled is
better.)

Note to self: I should remove #include <asm/pat.h> in i915_dma.c in v2.

--Andy

2013-05-06 21:23:01

by Andy Lutomirski

[permalink] [raw]
Subject: Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski <[email protected]> wrote:
> Signed-off-by: Andy Lutomirski <[email protected]>
> ---
>
> This needs careful review. I don't really know what this code does, nor
> do I have the hardware. (I don't understand AGP and the associated
> caching implications.)

This patch is wrong (I didn't update the matching mtrr_del), and I'm
reworking this whole series. But I may need some help on this one:
why is the mtrr handle of a map (whatever a map is) exported to
userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is
userspace supposed to do with it? Do I need to return a valid MTRR
register number? Is there any userspace code at all that sets
_DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
and needs the MTRR, for which the drm driver doesn't already add the
MTRR?

--Andy

2013-05-06 23:05:06

by Jerome Glisse

[permalink] [raw]
Subject: Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski <[email protected]> wrote:
> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski <[email protected]> wrote:
>> Signed-off-by: Andy Lutomirski <[email protected]>
>> ---
>>
>> This needs careful review. I don't really know what this code does, nor
>> do I have the hardware. (I don't understand AGP and the associated
>> caching implications.)
>
> This patch is wrong (I didn't update the matching mtrr_del), and I'm
> reworking this whole series. But I may need some help on this one:
> why is the mtrr handle of a map (whatever a map is) exported to
> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is
> userspace supposed to do with it? Do I need to return a valid MTRR
> register number? Is there any userspace code at all that sets
> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
> and needs the MTRR, for which the drm driver doesn't already add the
> MTRR?
>
> --Andy

>From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
cover it with a write combine MTRR. The whole ioctl is use by some ddx
or maybe even directly the XServer to do this mtrr mess in userspace.

Sorry for the bad news, but that's what i remember on that front
thought i would need to read all the code again.

Cheers,
Jerome

2013-05-06 23:39:43

by Andy Lutomirski

[permalink] [raw]
Subject: Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse <[email protected]> wrote:
> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski <[email protected]> wrote:
>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski <[email protected]> wrote:
>>> Signed-off-by: Andy Lutomirski <[email protected]>
>>> ---
>>>
>>> This needs careful review. I don't really know what this code does, nor
>>> do I have the hardware. (I don't understand AGP and the associated
>>> caching implications.)
>>
>> This patch is wrong (I didn't update the matching mtrr_del), and I'm
>> reworking this whole series. But I may need some help on this one:
>> why is the mtrr handle of a map (whatever a map is) exported to
>> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is
>> userspace supposed to do with it? Do I need to return a valid MTRR
>> register number? Is there any userspace code at all that sets
>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
>> and needs the MTRR, for which the drm driver doesn't already add the
>> MTRR?
>>
>> --Andy
>
> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
> cover it with a write combine MTRR. The whole ioctl is use by some ddx
> or maybe even directly the XServer to do this mtrr mess in userspace.

Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to
work fine, but almost nothing uses it.

I'm amazed this stuff works in the current code, though. Apparently
the memory type (WC or UC) of a drm mapping is determined by the mtrr
the driver set, but if one part of the BAR is textures or the
framebuffer and another part is an outgoing command ring, won't one of
them end up with the wrong memory type?

I'd really hate to have to track fake mtrrs in the drm core to emulate
real mtrrs.

>
> Sorry for the bad news, but that's what i remember on that front
> thought i would need to read all the code again.

On the bright side, in the entire 2005 monolithic xorg tarball, the
only thing that looks at the mtrr exported to userspace appears to be
dritests.

--Andy

2013-05-07 03:09:51

by Dave Airlie

[permalink] [raw]
Subject: Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

>>
>> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
>> cover it with a write combine MTRR. The whole ioctl is use by some ddx
>> or maybe even directly the XServer to do this mtrr mess in userspace.
>
> Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to
> work fine, but almost nothing uses it.
>
> I'm amazed this stuff works in the current code, though. Apparently
> the memory type (WC or UC) of a drm mapping is determined by the mtrr
> the driver set, but if one part of the BAR is textures or the
> framebuffer and another part is an outgoing command ring, won't one of
> them end up with the wrong memory type?

Nobody sane puts the command ring in VRAM.

Dave.

2013-05-07 14:09:04

by Alex Deucher

[permalink] [raw]
Subject: Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski <[email protected]> wrote:
> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse <[email protected]> wrote:
>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski <[email protected]> wrote:
>>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski <[email protected]> wrote:
>>>> Signed-off-by: Andy Lutomirski <[email protected]>
>>>> ---
>>>>
>>>> This needs careful review. I don't really know what this code does, nor
>>>> do I have the hardware. (I don't understand AGP and the associated
>>>> caching implications.)
>>>
>>> This patch is wrong (I didn't update the matching mtrr_del), and I'm
>>> reworking this whole series. But I may need some help on this one:
>>> why is the mtrr handle of a map (whatever a map is) exported to
>>> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is
>>> userspace supposed to do with it? Do I need to return a valid MTRR
>>> register number? Is there any userspace code at all that sets
>>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
>>> and needs the MTRR, for which the drm driver doesn't already add the
>>> MTRR?
>>>
>>> --Andy
>>
>> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
>> cover it with a write combine MTRR. The whole ioctl is use by some ddx
>> or maybe even directly the XServer to do this mtrr mess in userspace.
>
> Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to
> work fine, but almost nothing uses it.
>
> I'm amazed this stuff works in the current code, though. Apparently
> the memory type (WC or UC) of a drm mapping is determined by the mtrr
> the driver set, but if one part of the BAR is textures or the
> framebuffer and another part is an outgoing command ring, won't one of
> them end up with the wrong memory type?

A lot of old chips used to put the registers and framebuffer in the
same BAR. IIRC, the xserver and later libpciaccess had workarounds to
deal with this.

Alex

2013-05-07 16:46:17

by Andy Lutomirski

[permalink] [raw]
Subject: Re: [PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

On Tue, May 7, 2013 at 7:08 AM, Alex Deucher <[email protected]> wrote:
> On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski <[email protected]> wrote:
>> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse <[email protected]> wrote:
>>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski <[email protected]> wrote:
>>>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski <[email protected]> wrote:
>>>>> Signed-off-by: Andy Lutomirski <[email protected]>
>>>>> ---
>>>>>
>>>>> This needs careful review. I don't really know what this code does, nor
>>>>> do I have the hardware. (I don't understand AGP and the associated
>>>>> caching implications.)
>>>>
>>>> This patch is wrong (I didn't update the matching mtrr_del), and I'm
>>>> reworking this whole series. But I may need some help on this one:
>>>> why is the mtrr handle of a map (whatever a map is) exported to
>>>> userspace via the ADD_MAP and GET_MAP ioctls? What (if anything) is
>>>> userspace supposed to do with it? Do I need to return a valid MTRR
>>>> register number? Is there any userspace code at all that sets
>>>> _DRM_WRITE_COMBINING in DRM_IOCTL_ADD_MAP with appropriate alignment
>>>> and needs the MTRR, for which the drm driver doesn't already add the
>>>> MTRR?
>>>>
>>>> --Andy
>>>
>>> From memory, even on pat system we need mtrr for VRAM is PCI BAR. We
>>> cover it with a write combine MTRR. The whole ioctl is use by some ddx
>>> or maybe even directly the XServer to do this mtrr mess in userspace.
>>
>> Egads! So we have a _DRM_WRITE_COMBINING flag, which will continue to
>> work fine, but almost nothing uses it.
>>
>> I'm amazed this stuff works in the current code, though. Apparently
>> the memory type (WC or UC) of a drm mapping is determined by the mtrr
>> the driver set, but if one part of the BAR is textures or the
>> framebuffer and another part is an outgoing command ring, won't one of
>> them end up with the wrong memory type?
>
> A lot of old chips used to put the registers and framebuffer in the
> same BAR. IIRC, the xserver and later libpciaccess had workarounds to
> deal with this.

I think I read the code wrong (so my patch is garbage). Maybe there's
actually no problem -- if DRM_AGP and DRM_FRAME_BUFFER are always WC,
DRM_REGISTERS is only WC if explicitly requested, and DRM_SHM is
always WB, so everything should be covered.

Anything using libpciaccess ought to be unaffected by my changes -- I
don't want to change /proc/mtrr or the sysfs stuff. The only possible
issue is if there's a memtype conflict, but that's nothing new.

--Andy