[PATCH v1 36/47] video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
The same area used for MTRR is used for the ioremap() area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/i810/i810.h | 3 +--
drivers/video/fbdev/i810/i810_main.c | 11 +++
drivers/video/fbdev/i810/i810_main.h | 26 --
3 files changed, 8 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810.h b/drivers/video/fbdev/i810/i810.h
index 1414b73..7b1c002 100644
--- a/drivers/video/fbdev/i810/i810.h
+++ b/drivers/video/fbdev/i810/i810.h
@@ -199,7 +199,6 @@
#define HAS_FONTCACHE 8
/* driver flags */
-#define HAS_MTRR1
#define HAS_ACCELERATION2
#define ALWAYS_SYNC 4
#define LOCKUP 8
@@ -281,7 +280,7 @@ struct i810fb_par {
u32 ovract;
u32 cur_state;
u32 ddc_num;
- int mtrr_reg;
+ int wc_cookie;
u16 bltcntl;
u8 interlace;
};
diff --git a/drivers/video/fbdev/i810/i810_main.c
b/drivers/video/fbdev/i810/i810_main.c
index bb674e4..025b882 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -41,6 +41,7 @@
#include linux/resource.h
#include linux/unistd.h
#include linux/console.h
+#include linux/io.h
#include asm/io.h
#include asm/div64.h
@@ -1816,7 +1817,9 @@ static void i810_init_device(struct i810fb_par *par)
u8 reg;
u8 __iomem *mmio = par-mmio_start_virtual;
- if (mtrr) set_mtrr(par);
+ if (mtrr)
+ par-wc_cookie= arch_phys_wc_add((u32) par-aperture.physical,
+par-aperture.size);
i810_init_cursor(par);
@@ -1865,8 +1868,8 @@ static int i810_allocate_pci_resource(struct i810fb_par
*par,
}
par-res_flags |= FRAMEBUFFER_REQ;
- par-aperture.virtual = ioremap_nocache(par-aperture.physical,
- par-aperture.size);
+ par-aperture.virtual = ioremap_wc(par-aperture.physical,
+ par-aperture.size);
if (!par-aperture.virtual) {
printk(i810fb_init: cannot
[PATCH v1 39/47] video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/pm2fb.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 3b85b64..aa8d288 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -38,10 +38,6 @@
#include linux/fb.h
#include linux/init.h
#include linux/pci.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/permedia2.h
#include video/cvisionppc.h
@@ -81,10 +77,7 @@ static char *mode_option;
static bool lowhsync;
static bool lowvsync;
static bool noaccel;
-/* mtrr option */
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
/*
* The hardware state of the graphics card that isn't part of the
@@ -100,7 +93,7 @@ struct pm2fb_par
u32 mem_control;/* MemControl reg at probe */
u32 boot_address; /* BootAddress reg at probe */
u32 palette[16];
- int mtrr_handle;
+ int wc_cookie;
};
/*
@@ -1637,21 +1630,16 @@ static int pm2fb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto err_exit_mmio;
}
info-screen_base =
- ioremap_nocache(pm2fb_fix.smem_start, pm2fb_fix.smem_len);
+ ioremap_wc(pm2fb_fix.smem_start, pm2fb_fix.smem_len);
if (!info-screen_base) {
printk(KERN_WARNING pm2fb: Can't ioremap smem area.\n);
release_mem_region(pm2fb_fix.smem_start, pm2fb_fix.smem_len);
goto err_exit_mmio;
}
-#ifdef CONFIG_MTRR
- default_par-mtrr_handle = -1;
if (!nomtrr)
- default_par-mtrr_handle =
- mtrr_add(pm2fb_fix.smem_start,
-pm2fb_fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+ default_par-wc_cookie = arch_phys_wc_add(pm2fb_fix.smem_start,
+ pm2fb_fix.smem_len);
info-fbops = pm2fb_ops;
info-fix = pm2fb_fix;
@@ -1733,12 +1721,7 @@ static void pm2fb_remove(struct pci_dev *pdev)
struct pm2fb_par *par = info-par;
unregister_framebuffer(info);
-
-#ifdef CONFIG_MTRR
- if (par-mtrr_handle = 0)
- mtrr_del(par-mtrr_handle, info-fix.smem_start
[PATCH v1 38/47] video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/kyro/fbdev.c | 33 +++--
include/video/kyro.h | 4 +---
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 65041e1..5bb0153 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -22,9 +22,6 @@
#include linux/pci.h
#include asm/io.h
#include linux/uaccess.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include video/kyro.h
@@ -84,9 +81,7 @@ static device_info_t deviceInfo;
static char *mode_option = NULL;
static int nopan = 0;
static int nowrap = 1;
-#ifdef CONFIG_MTRR
static int nomtrr = 0;
-#endif
/* PCI driver prototypes */
static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -570,10 +565,8 @@ static int __init kyrofb_setup(char *options)
nopan = 1;
} else if (strcmp(this_opt, nowrap) == 0) {
nowrap = 1;
-#ifdef CONFIG_MTRR
} else if (strcmp(this_opt, nomtrr) == 0) {
nomtrr = 1;
-#endif
} else {
mode_option = this_opt;
}
@@ -691,17 +684,16 @@ static int kyrofb_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
currentpar-regbase = deviceInfo.pSTGReg =
ioremap_nocache(kyro_fix.mmio_start, kyro_fix.mmio_len);
+ if (!currentpar-regbase)
+ goto out_free_fb;
- info-screen_base = ioremap_nocache(kyro_fix.smem_start,
- kyro_fix.smem_len);
+ info-screen_base = pci_ioremap_wc_bar(pdev, 0);
+ if (!info-screen_base)
+ goto out_unmap_regs;
-#ifdef CONFIG_MTRR
if (!nomtrr)
- currentpar-mtrr_handle =
- mtrr_add(kyro_fix.smem_start,
-kyro_fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+ currentpar-wc_cookie = arch_phys_wc_add(kyro_fix.smem_start,
+kyro_fix.smem_len);
kyro_fix.ypanstep = nopan ? 0 : 1;
kyro_fix.ywrapstep = nowrap ? 0 : 1;
@@ -745,8 +737,10 @@ static int kyrofb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return 0;
out_unmap:
- iounmap(currentpar-regbase);
iounmap(info
[PATCH v1 45/47] video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
From: Luis R. Rodriguez mcg...@suse.com The driver doesn't use mtrr_add() or arch_phys_wc_add() but since we know the framebuffer is isolated already on an ioremap() we can take advantage of write combining for performance where possible. In this case there are a few motivations for this: a) Take advantage of PAT when available b) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e) Cc: Suresh Siddha suresh.b.sid...@intel.com Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com Cc: Ingo Molnar mi...@elte.hu Cc: Thomas Gleixner t...@linutronix.de Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- drivers/video/fbdev/geode/gxfb_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c index 124d7c7..ec9fc9a 100644 --- a/drivers/video/fbdev/geode/gxfb_core.c +++ b/drivers/video/fbdev/geode/gxfb_core.c @@ -263,7 +263,8 @@ static int gxfb_map_video_memory(struct fb_info *info, struct pci_dev *dev) info-fix.smem_start = pci_resource_start(dev, 0); info-fix.smem_len = vram ? vram : gx_frame_buffer_size(); - info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len); + info-screen_base = ioremap_wc(info-fix.smem_start, + info-fix.smem_len); if (!info-screen_base) return -ENOMEM; -- 2.3.2.209.gd67f9d5.dirty -- 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 v1 06/47] mtrr: add __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on PATs with errata, another situation is observed on
old device drivers where devices had combined MMIO
register access with whatever area they typically
later wanted to end up using MTRR for on the same
PCI BAR. This situation can still be addressed by
splitting up ioremap'd PCI BAR into two ioremap'd
calls, one for MMIO registers, and another for whatever
is desirable for write-combining -- in order to
accomplish this though quite a bit of driver
restructuring is required.
Device drivers which are known to require large
amount of re-work in order to split ioremap'd areas
can use __arch_phys_wc_add() to avoid regressions
when PAT is enabled.
For a good example driver where things are neatly
split up on a PCI BAR refer the infiniband qib
driver. For a good example of a driver where good
amount of work is required refer to the infiniband
ipath driver.
This is *only* a transitive API -- and as such no new
drivers are ever expected to use this.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/include/asm/io.h | 4
arch/x86/kernel/cpu/mtrr/main.c | 36 +---
include/linux/io.h | 4
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34a5b93..a144d05 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -338,6 +338,10 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec
*vec1,
#define IO_SPACE_LIMIT 0x
#ifdef CONFIG_MTRR
+extern int __must_check __arch_phys_wc_add(unsigned long base,
+ unsigned long size);
+#define __arch_phys_wc_add __arch_phys_wc_add
+
extern int __must_check arch_phys_wc_add(unsigned long base,
unsigned long size);
extern void arch_phys_wc_del(int handle);
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 7db9c47..5ae830b 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -538,23 +538,24 @@ int mtrr_del(int reg, unsigned long base, unsigned long
size)
EXPORT_SYMBOL(mtrr_del);
/**
- * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
+ * __arch_phys_wc_add - add a WC MTRR even if PAT is available
* @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.
+ * We typically do not want to use MTRR if PAT is available but there
+ * are some drivers which require significant work to get this to work
+ * properly. This call should only be used by those drivers where it is
+ * clear that hard work is required to modify them to use arch_phys_wc_add()
*
* 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 arch_phys_wc_add(unsigned long base, unsigned long size)
+int __arch_phys_wc_add(unsigned long base, unsigned long size)
{
int ret;
- if (pat_enabled || !mtrr_enabled)
- return 0; /* Success! (We don't need to do anything.) */
+ if (!mtrr_enabled)
+ return 0;
ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true);
if (ret 0) {
@@ -564,6 +565,27 @@ int arch_phys_wc_add(unsigned long base, unsigned long
size)
}
return ret + MTRR_TO_PHYS_WC_OFFSET;
}
+EXPORT_SYMBOL_GPL(__arch_phys_wc_add);
+
+/**
+ * arch_phys_wc_add - 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 arch_phys_wc_add(unsigned long base, unsigned long size)
+{
+ if (pat_enabled || !mtrr_enabled)
+ return 0; /* Success! (We don't need to do anything.) */
+
+ return __arch_phys_wc_add(base
[PATCH v1 11/47] IB/qib: add acounting for MTRR
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
index 81b225f..fe0850a 100644
--- a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
+++ b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
@@ -118,7 +118,7 @@ int qib_enable_wc(struct qib_devdata *dd)
if (!ret) {
int cookie;
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+ cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
qib_devinfo(dd-pcidev,
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 17/47] video: fbdev: vesafb: only support MTRR_TYPE_WRCOMB
From: Luis R. Rodriguez mcg...@suse.com
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs and
can replace it in a much cleaner way, where so long as the
proper ioremap_wc() or variant API is used the right thing will
be done behind the scenes. This is the only driver left using the
other MTRR types -- and since there is no good reason for it now
rip them out.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vesafb.c | 62
1 file changed, 16 insertions(+), 46 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index d79a0ac..191156b 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -404,60 +404,30 @@ static int vesafb_probe(struct platform_device *dev)
* region already (FIXME) */
request_region(0x3c0, 32, vesafb);
+ if (mtrr == 3) {
#ifdef CONFIG_MTRR
- if (mtrr) {
unsigned int temp_size = size_total;
- unsigned int type = 0;
+ int rc;
- 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;
- }
-
- 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(vesafb_fix.smem_start, temp_size,
- type, 1);
- temp_size = 1;
- } while (temp_size = PAGE_SIZE rc == -EINVAL);
- }
- }
+ /* Try and find a power of two to add */
+ do {
+ rc = mtrr_add(vesafb_fix.smem_start, temp_size,
+ MTRR_TYPE_WRCOMB, 1);
+ temp_size = 1;
+ } while (temp_size = PAGE_SIZE rc == -EINVAL);
#endif
-
- switch (mtrr) {
- case 1: /* uncachable */
- info-screen_base = ioremap_nocache(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
- case 2: /* write-back */
- info-screen_base = ioremap_cache(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
- case 3: /* write-combining */
info-screen_base = ioremap_wc(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
- case 4: /* write-through */
- default:
+ } else {
+#ifdef CONFIG_MTRR
+ if (mtrr mtrr != 3)
+ WARN_ONCE(1, Only MTRR_TYPE_WRCOMB (3) make sense\n);
+#endif
info-screen_base = ioremap(vesafb_fix.smem_start,
vesafb_fix.smem_len);
- break;
}
+
if (!info-screen_base) {
printk(KERN_ERR
vesafb: abort, cannot ioremap video memory 0x%x @
0x%lx\n,
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 24/47] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/arkfb.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e..6a317de 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
#include linux/console.h /* Why should fb driver call console functions?
because console_lock() */
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct arkfb_info {
int mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
static char *mode_option = 640x480-8@60;
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
MODULE_AUTHOR((c) 2007 Ondrej Zajicek santi...@crfreenet.org);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(fbdev driver for ARK 2000PV);
@@ -115,11 +107,6 @@ MODULE_PARM_DESC(mode_option, Default video mode
('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, Default video mode ('640x480-8@60', etc)
(deprecated));
-#ifdef CONFIG_MTRR
-module_param(mtrr, int, 0444);
-MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
-
static int threshold = 4;
module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info-fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -1057,14 +1044,8 @@ static int ark_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
-
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
/* Error handling */
@@ -1092,14 +1073,7 @@ static void ark_pci_remove(struct
[PATCH v1 01/47] x86: mtrr: annotate mtrr_type_lookup() is only implemented on generic_mtrr_ops
From: Luis R. Rodriguez mcg...@suse.com There area few users of mtrr_type_lookup(), including PAT. Note that PAT can be in theory enabled without MTRR fully kicking in, such is the case with Xen. Cc: Andy Lutomirski l...@amacapital.net Cc: Suresh Siddha suresh.b.sid...@intel.com Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com Cc: Ingo Molnar mi...@elte.hu Cc: Thomas Gleixner t...@linutronix.de Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Dave Hansen dave.han...@linux.intel.com Cc: venkatesh.pallip...@intel.com Cc: Stefan Bader stefan.ba...@canonical.com Cc: konrad.w...@oracle.com Cc: ville.syrj...@linux.intel.com Cc: david.vra...@citrix.com Cc: jbeul...@suse.com Cc: toshi.k...@hp.com Cc: bhelg...@google.com Cc: Roger Pau Monné roger@citrix.com Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-de...@lists.xensource.com Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/kernel/cpu/mtrr/generic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c index 7d74f7b..09c82de 100644 --- a/arch/x86/kernel/cpu/mtrr/generic.c +++ b/arch/x86/kernel/cpu/mtrr/generic.c @@ -230,6 +230,8 @@ u8 mtrr_type_lookup(u64 start, u64 end) int repeat; u64 partial_end; + /* XXX: Currently only implemented on generic_mtrr_ops */ + type = __mtrr_type_lookup(start, end, partial_end, repeat); /* -- 2.3.2.209.gd67f9d5.dirty -- 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 v1 08/47] video: fbdev: atyfb: clarify ioremap() base and length used
From: Luis R. Rodriguez mcg...@suse.com
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI we *know* this defaults to 0x80.
atyfb_setup_generic() is *only* used on PCI probe.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 16936bb..8025624 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3489,7 +3489,9 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
/* Map in frame buffer */
info-fix.smem_start = addr;
- info-screen_base = ioremap(addr, 0x80);
+ info-fix.smem_len = 0x80;
+
+ info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len);
if (info-screen_base == NULL) {
ret = -ENOMEM;
goto atyfb_setup_generic_fail;
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 16/47] fusion: use __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Nagalakshmi Nandigama nagalakshmi.nandig...@avagotech.com
Cc: Praveen Krishnamoorthy praveen.krishnamoor...@avagotech.com
Cc: Sreekanth Reddy sreekanth.re...@avagotech.com
Cc: Abhijit Mahajan abhijit.maha...@avagotech.com
Cc: Juergen Gross jgr...@suse.com
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: mpt-fusionlinux@avagotech.com
Cc: linux-s...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/message/fusion/mptbase.c | 19 ---
drivers/message/fusion/mptbase.h | 2 +-
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 187f836..c7b1a55 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -59,10 +59,6 @@
#include linux/delay.h
#include linux/interrupt.h /* needed for in_interrupt() proto */
#include linux/dma-mapping.h
-#include asm/io.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include linux/kthread.h
#include scsi/scsi_host.h
@@ -2820,11 +2816,8 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
pci_disable_device(ioc-pcidev);
pci_release_selected_regions(ioc-pcidev, ioc-bars);
-#if defined(CONFIG_MTRR) 0
- if (ioc-mtrr_reg 0) {
- mtrr_del(ioc-mtrr_reg, 0, 0);
- dprintk(ioc, printk(MYIOC_s_INFO_FMT MTRR region
de-registered\n, ioc-name));
- }
+#if 0
+ __arch_phys_wc_del(ioc-wc_cookie);
#endif
/* Zap the adapter lookup ptr! */
@@ -4512,17 +4505,13 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
ioc-req_frames_low_dma = (u32) (alloc_dma 0x);
-#if defined(CONFIG_MTRR) 0
+#if 0
/*
* Enable Write Combining MTRR for IOC's memory region.
* (at least as much as we can; size and base must be
* multiples of 4 kiB
*/
- ioc-mtrr_reg = mtrr_add(ioc-req_frames_dma,
-sz,
-MTRR_TYPE_WRCOMB, 1);
- dprintk(ioc, printk(MYIOC_s_DEBUG_FMT MTRR region registered
(base:size=%08x:%x)\n,
- ioc-name, ioc-req_frames_dma, sz));
+ ioc-wc_cookie = arch_phys_wc_add(ioc-req_frames_dma, sz);
#endif
for (i = 0; i ioc-req_depth; i++) {
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index 8f14090..f0bff11 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -671,7 +671,7 @@ typedef struct _MPT_ADAPTER
u8 *HostPageBuffer; /* SAS - host page buffer
support */
u32 HostPageBuffer_sz;
dma_addr_t HostPageBuffer_dma;
- int mtrr_reg;
+ int wc_cookie;
struct pci_dev *pcidev;/* struct pci_dev pointer */
int bars; /* bitmask of BAR's that must
be configured */
int msi_enable;
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 22/47] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/staging/sm750fb/sm750.c| 34 --
drivers/staging/sm750fb/sm750.h| 3 ---
drivers/staging/sm750fb/sm750_hw.c | 3 +--
3 files changed, 5 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..ea59471 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
#includelinux/vmalloc.h
#includelinux/pagemap.h
#include linux/console.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include asm/fb.h
#include sm750.h
#include sm750_hw.h
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*,struct
pci_dev*);
/* common var for all device */
static int g_hwcursor = 1;
static int g_noaccel = 0;
-#ifdef CONFIG_MTRR
static int g_nomtrr = 0;
-#endif
static const char * g_fbmode[] = {NULL,NULL};
static const char * g_def_fbmode = 800x600-16@60;
static char * g_settings = NULL;
@@ -1102,11 +1097,8 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
pr_info(share-revid = %02x\n,share-revid);
share-pdev = pdev;
-#ifdef CONFIG_MTRR
share-mtrr_off = g_nomtrr;
share-mtrr.vram = 0;
- share-mtrr.vram_added = 0;
-#endif
share-accel_off = g_noaccel;
share-dual = g_dualview;
spin_lock_init(share-slock);
@@ -1134,22 +1126,9 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
goto err_map;
}
-#ifdef CONFIG_MTRR
- if(!share-mtrr_off){
- pr_info(enable mtrr\n);
- share-mtrr.vram = mtrr_add(share-vidmem_start,
- share-vidmem_size,
- MTRR_TYPE_WRCOMB,1);
-
- if(share-mtrr.vram 0){
- /* don't block driver with the failure of MTRR */
- pr_err(Unable to setup MTRR.\n);
- }else{
- share-mtrr.vram_added = 1;
- pr_info(MTRR added succesfully\n);
- }
- }
-#endif
+ if (!share-mtrr_off)
+ share-mtrr.vram = arch_phys_wc_add(share-vidmem_start,
+ share-vidmem_size);
memset(share-pvMem,0,share-vidmem_size);
@@ -1250,10 +1229,7 @@ static void __exit lynxfb_pci_remove(struct pci_dev *
pdev)
/* release frame buffer
[PATCH v1 31/47] video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/s3fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a..13b1090 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
#include linux/i2c.h
#include linux/i2c-algo-bit.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct s3fb_info {
int chip, rev, mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
-
static int fasttext = 1;
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
MODULE_PARM_DESC(mode_option, Default video mode ('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, Default video mode ('640x480-8@60', etc)
(deprecated));
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
module_param(fasttext, int, 0644);
MODULE_PARM_DESC(fasttext, Enable S3 fast text mode (1=enable, 0=disable,
default=1));
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info-fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -1365,12 +1354,9 @@ static int s3_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
@@ -1405,14 +1391,7 @@ static void
[PATCH v1 00/47] mtrr/x86/drivers: bury MTRR
From: Luis R. Rodriguez mcg...@suse.com When a system has PAT support enabled you don't need to be using MTRRs. Andy had added arch_phys_wc_add() long ago to help with this but not all drivers were converted over. We have to take care to only convert drivers where we know that the proper ioremap_wc() API has been used. Doing this requires a bit of work on verifying the driver split out the ioremap'd areas -- and if not doing that ourselves. Verifying a driver uses the same areas can be hard but with a bit of love Coccinelle can help with that. We're motivated to change drivers for a few reasons: 1) Take advantage of PAT when available 2) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e) 3) Bury MTRR code away from drivers as it is architecture specific While working on the conversion I noticed a few things. a) Run time disabling of MTRR Some systems can technically have both PAT and MTRR enabled and even if they support it, a system may end up not enabling MTRR. There are a few reasons why this can happen but the code right now doesn't address this well. This leads to another point: PAT code right now is not a first class citizen on x86 -- pat_init() depends on MTRR code so we can't actually enable PAT without building MTRR. Doing this requires quite a bit more work so let this serve as a starting point for conversation if we want to address that. b) Driver work and required ioremap split In order to take advantage of PAT device drivers that were using MTRR must make sure that the area that was using MTRR is ioremap'd separately. Fortunately a lot of drivers already do this, but there's quite a bit of drivers that require some love to get that happen. This leaves us needing to expose an last resort API to annotate this and also avoid a regression on performance for systems that may have PAT but can't yet move away from using MTRR. To find the drivers that need love check out __arch_phys_wc_add(). For a good example driver where the work was done refer to the atyfb driver fixes. c) Missing APIs for write-combining There's a few API calls missing to take advantage of write-combining, this series add those. d) Further framebuffer driver MTRR usage simplication We can simplify MTRR usage by having the framebuffer core add the MTRR by passing a flag when register_framebuffer() is called, this could for instance be done on very few drivers where the smem_len and smem_start are both used for the ioremap_wc() and also for the arch_phys_wc_add(). Coccinelle can be easily used to do a transformation here. I didn't do that here given that it does not work for all device drivers *and* DRM drivers already have something similar. Lastly this technically could also be done on some other generic helper --- but figured its best we review that here. One reason to *not* do this is that tons of framebuffer drivers have mtrr options exposed -- we'd need to generalize those and provide a port ... or deal with the fact that we are going to remove all that. Luis R. Rodriguez (47): x86: mtrr: annotate mtrr_type_lookup() is only implemented on generic_mtrr_ops x86: mtrr: generalize run time disabling of MTRR devres: add devm_ioremap_wc() pci: add pci_ioremap_wc_bar() pci: add pci_iomap_wc() variants mtrr: add __arch_phys_wc_add() video: fbdev: atyfb: move framebuffer length fudging to helper video: fbdev: atyfb: clarify ioremap() base and length used vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc() IB/qib: add acounting for MTRR IB/qib: use arch_phys_wc_add() IB/ipath: add counting for MTRR IB/ipath: use __arch_phys_wc_add() [media] media: ivtv: use __arch_phys_wc_add() fusion: use __arch_phys_wc_add() video: fbdev: vesafb: only support MTRR_TYPE_WRCOMB vidoe: fbdev: vesafb: add missing mtrr_del() for added MTRR video: fbdev: vesafb: use arch_phys_wc_add() mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index() ethernet: myri10ge: use arch_phys_wc_add() staging: sm750fb: use arch_phys_wc_add() and ioremap_wc() staging: xgifb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc() video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: gbefb: add missing mtrr_del() calls video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc() video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc() video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc() video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc() video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc() video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc() video: fbdev
[PATCH v1 05/47] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO registers, sometimes we can address
the changes in drivers, other times the change requires
intrusive changes.
Although there is also arch_phys_wc_add() that makes use of
architecture specific write-combinging alternatives (MTRR on
x86 when a system does not have PAT) we void polluting
pci_iomap() space with it and force drivers and subsystems
that want to use it to be explicit.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
include/asm-generic/pci_iomap.h | 14 ++
lib/pci_iomap.c | 61 +
2 files changed, 75 insertions(+)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87..b1e17fc 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long
max);
extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
int bar, unsigned lon
return NULL;
}
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar,
unsigned long max)
+{
+ return NULL;
+}
static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
{
return NULL;
}
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f1..30b65ae 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
EXPORT_SYMBOL(pci_iomap_range);
/**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way. When possible write combining
+ * is used.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR from offset to the end, pass %0 here.
+ * */
+void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
+int bar
[PATCH v1 28/47] video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Although this driver gives the framebuffer layer a different
size for the framebuffer it uses the entire aperture PCI BAR
size for the MTRR. Since the framebuffer is included in that
range and MTRR was used on the entire PCI BAR WC will have
been preferred on that range as well. This propagates the
WC preference on the same entire PCI BAR.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/intelfb/intelfb.h| 4 +---
drivers/video/fbdev/intelfb/intelfbdrv.c | 38
2 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/video/fbdev/intelfb/intelfb.h
b/drivers/video/fbdev/intelfb/intelfb.h
index 6b51175..37f8339 100644
--- a/drivers/video/fbdev/intelfb/intelfb.h
+++ b/drivers/video/fbdev/intelfb/intelfb.h
@@ -285,9 +285,7 @@ struct intelfb_info {
/* use a gart reserved fb mem */
u8 fbmem_gart;
- /* mtrr support */
- int mtrr_reg;
- u32 has_mtrr;
+ int wc_cookie;
/* heap data */
struct intelfb_heap_data aperture;
diff --git a/drivers/video/fbdev/intelfb/intelfbdrv.c
b/drivers/video/fbdev/intelfb/intelfbdrv.c
index b847d53..bbec737 100644
--- a/drivers/video/fbdev/intelfb/intelfbdrv.c
+++ b/drivers/video/fbdev/intelfb/intelfbdrv.c
@@ -124,10 +124,6 @@
#include asm/io.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include intelfb.h
#include intelfbhw.h
#include ../edid.h
@@ -411,33 +407,6 @@ module_init(intelfb_init);
module_exit(intelfb_exit);
/***
- * mtrr support functions *
- ***/
-
-#ifdef CONFIG_MTRR
-static inline void set_mtrr(struct intelfb_info *dinfo)
-{
- dinfo-mtrr_reg = mtrr_add(dinfo-aperture.physical,
- dinfo-aperture.size, MTRR_TYPE_WRCOMB, 1);
- if (dinfo-mtrr_reg 0) {
- ERR_MSG(unable to set MTRR\n);
- return;
- }
- dinfo-has_mtrr = 1;
-}
-static inline void unset_mtrr(struct intelfb_info *dinfo)
-{
- if (dinfo-has_mtrr)
- mtrr_del(dinfo-mtrr_reg, dinfo-aperture.physical,
-dinfo-aperture.size);
-}
-#else
-#define set_mtrr(x) WRN_MSG(MTRR is disabled in the kernel\n)
-
-#define unset_mtrr(x) do { } while (0)
-#endif /* CONFIG_MTRR */
-
-/***
*driver init
[PATCH v1 29/47] video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same ioremap()'d area for the MTRR.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/matrox/matroxfb_base.c | 36 +++---
drivers/video/fbdev/matrox/matroxfb_base.h | 27 +-
2 files changed, 14 insertions(+), 49 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 62539ca..2f70365 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -370,12 +370,9 @@ static void matroxfb_remove(struct matrox_fb_info *minfo,
int dummy)
matroxfb_unregister_device(minfo);
unregister_framebuffer(minfo-fbcon);
matroxfb_g450_shutdown(minfo);
-#ifdef CONFIG_MTRR
- if (minfo-mtrr.vram_valid)
- mtrr_del(minfo-mtrr.vram, minfo-video.base, minfo-video.len);
-#endif
- mga_iounmap(minfo-mmio.vbase);
- mga_iounmap(minfo-video.vbase);
+ arch_phys_wc_del(minfo-wc_cookie);
+ iounmap(minfo-mmio.vbase.vaddr);
+ iounmap(minfo-video.vbase.vaddr);
release_mem_region(minfo-video.base, minfo-video.len_maximum);
release_mem_region(minfo-mmio.base, 16384);
kfree(minfo);
@@ -1256,9 +1253,7 @@ static int nobios;/*
matroxfb:nobios */
static int noinit = 1; /* matroxfb:init */
static int inverse;/* matroxfb:inverse */
static int sgram; /* matroxfb:sgram */
-#ifdef CONFIG_MTRR
static int mtrr = 1; /* matroxfb:nomtrr */
-#endif
static int grayscale; /* matroxfb:grayscale */
static int dev = -1; /* matroxfb:dev:x */
static unsigned int vesa = ~0; /* matroxfb:vesa:x */
@@ -1717,14 +1712,17 @@ static int initMatrox2(struct matrox_fb_info *minfo,
struct board *b)
if (mem (mem memsize))
memsize = mem;
err = -ENOMEM;
- if (mga_ioremap(ctrlptr_phys, 16384, MGA_IOREMAP_MMIO,
minfo-mmio.vbase)) {
+
+ minfo-mmio.vbase.vaddr = ioremap_nocache(ctrlptr_phys, 16384);
+ if (!minfo-mmio.vbase.vaddr) {
printk(KERN_ERR matroxfb: cannot ioremap(%lX, 16384), matroxfb
disabled\n, ctrlptr_phys);
goto failVideoMR;
}
minfo-mmio.base = ctrlptr_phys;
minfo-mmio.len = 16384;
minfo-video.base = video_base_phys;
- if (mga_ioremap(video_base_phys, memsize, MGA_IOREMAP_FB,
minfo
[PATCH v1 35/47] video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/aty128fb.c | 36 ++--
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/drivers/video/fbdev/aty/aty128fb.c
b/drivers/video/fbdev/aty/aty128fb.c
index aedf2fb..f41955b 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -80,10 +80,6 @@
#include asm/btext.h
#endif /* CONFIG_BOOTX_TEXT */
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/aty128.h
/* Debug flag */
@@ -399,10 +395,7 @@ static int default_cmode = CMODE_8;
static int default_crt_on = 0;
static int default_lcd_on = 1;
-
-#ifdef CONFIG_MTRR
static bool mtrr = true;
-#endif
#ifdef CONFIG_FB_ATY128_BACKLIGHT
#ifdef CONFIG_PMAC_BACKLIGHT
@@ -456,9 +449,7 @@ struct aty128fb_par {
u32 vram_size; /* onboard video ram */
int chip_gen;
const struct aty128_meminfo *mem; /* onboard mem info*/
-#ifdef CONFIG_MTRR
- struct { int vram; int vram_valid; } mtrr;
-#endif
+ int wc_cookie;
int blitter_may_be_busy;
int fifo_slots; /* free slots in FIFO (64 max) */
@@ -1725,12 +1716,10 @@ static int aty128fb_setup(char *options)
#endif
continue;
}
-#ifdef CONFIG_MTRR
if(!strncmp(this_opt, nomtrr, 6)) {
mtrr = 0;
continue;
}
-#endif
#ifdef CONFIG_PPC_PMAC
/* vmode and cmode deprecated */
if (!strncmp(this_opt, vmode:, 6)) {
@@ -2133,7 +2122,7 @@ static int aty128_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
par-vram_size = aty_ld_le32(CNFG_MEMSIZE) 0x03FF;
/* Virtualize the framebuffer */
- info-screen_base = ioremap(fb_addr, par-vram_size);
+ info-screen_base = ioremap_wc(fb_addr, par-vram_size);
if (!info-screen_base)
goto err_unmap_out;
@@ -2170,15 +2159,9 @@ static int aty128_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (!aty128_init(pdev, ent))
goto err_out;
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr.vram = mtrr_add(info-fix.smem_start,
- par-vram_size, MTRR_TYPE_WRCOMB, 1);
- par-mtrr.vram_valid = 1;
- /* let there be speed */
- printk(KERN_INFO aty128fb: Rage128 MTRR set to ON\n
[PATCH v1 44/47] video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/atmel_lcdfb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c
b/drivers/video/fbdev/atmel_lcdfb.c
index 94a8d04..abadc49 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1266,7 +1266,8 @@ static int __init atmel_lcdfb_probe(struct
platform_device *pdev)
goto stop_clk;
}
- info-screen_base = ioremap(info-fix.smem_start,
info-fix.smem_len);
+ info-screen_base = ioremap_wc(info-fix.smem_start,
+ info-fix.smem_len);
if (!info-screen_base) {
ret = -ENOMEM;
goto release_intmem;
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 10/47] video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb.h | 4 +---
drivers/video/fbdev/aty/atyfb_base.c | 41 +---
2 files changed, 11 insertions(+), 34 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 89ec439..63c4842 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -182,9 +182,7 @@ struct atyfb_par {
unsigned long irq_flags;
unsigned int irq;
spinlock_t int_lock;
-#ifdef CONFIG_MTRR
- int mtrr_aper;
-#endif
+ int wc_cookie;
u32 mem_cntl;
struct crtc saved_crtc;
union aty_pll saved_pll;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8875e56..af278bb 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -98,9 +98,6 @@
#ifdef CONFIG_PMAC_BACKLIGHT
#include asm/backlight.h
#endif
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
/*
* Debug flags.
@@ -303,9 +300,7 @@ static struct fb_ops atyfb_ops = {
};
static bool noaccel;
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
static int vram;
static int pll;
static int mclk;
@@ -2628,14 +2623,9 @@ static int aty_init(struct fb_info *info)
aty_st_le32(BUS_CNTL, aty_ld_le32(BUS_CNTL, par) |
BUS_APER_REG_DIS, par);
-#ifdef CONFIG_MTRR
- par-mtrr_aper = -1;
- if (!nomtrr) {
- par-mtrr_aper = mtrr_add(info-fix.smem_start,
- info-fix.smem_len,
- MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (!nomtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
info-fbops = atyfb_ops;
info-pseudo_palette = par-pseudo_palette;
@@ -2763,13 +2753,8 @@ aty_init_exit:
/* restore video mode */
aty_set_crtc(par, par-saved_crtc);
par-pll_ops-set_pll(info, par-saved_pll);
+ arch_phys_wc_del(par-wc_cookie);
-#ifdef CONFIG_MTRR
- if (par-mtrr_aper = 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
-#endif
return ret;
}
@@ -3478,7 +3463,8 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info
[PATCH v1 13/47] IB/ipath: add counting for MTRR
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+ cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
dev_info(dd-pcidev-dev,
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 19/47] video: fbdev: vesafb: use arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vesafb.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index a2261d0..5bc94d3 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -19,10 +19,9 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/screen_info.h
+#include linux/io.h
#include video/vga.h
-#include asm/io.h
-#include asm/mtrr.h
#define dac_reg(0x3c8)
#define dac_val(0x3c9)
@@ -179,16 +178,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static void vesafb_destroy(struct fb_info *info)
{
-#ifdef CONFIG_MTRR
struct vesafb_par *par = info-par;
-#endif
fb_dealloc_cmap(info-cmap);
-
-#ifdef CONFIG_MTRR
- if (par-wc_cookie = 0)
- mtrr_del(par-wc_cookie, 0, 0);
-#endif
+ arch_phys_wc_del(par-wc_cookie);
if (info-screen_base)
iounmap(info-screen_base);
release_mem_region(info-apertures-ranges[0].base,
info-apertures-ranges[0].size);
@@ -419,7 +412,6 @@ static int vesafb_probe(struct platform_device *dev)
request_region(0x3c0, 32, vesafb);
if (mtrr == 3) {
-#ifdef CONFIG_MTRR
unsigned int temp_size = size_total;
/* Find the largest power-of-two */
@@ -427,18 +419,16 @@ static int vesafb_probe(struct platform_device *dev)
/* Try and find a power of two to add */
do {
- par-wc_cookie = mtrr_add(vesafb_fix.smem_start,
- temp_size,
- MTRR_TYPE_WRCOMB, 1);
+ par-wc_cookie =
+ arch_phys_wc_add(vesafb_fix.smem_start,
+temp_size);
temp_size = 1;
- } while (temp_size = PAGE_SIZE par-wc_cookie == -EINVAL);
-#endif
+ } while (temp_size = PAGE_SIZE par-wc_cookie 0);
+
info-screen_base = ioremap_wc(vesafb_fix.smem_start,
vesafb_fix.smem_len);
} else {
-#ifdef CONFIG_MTRR
if (mtrr mtrr != 3)
WARN_ONCE(1, Only MTRR_TYPE_WRCOMB (3
[PATCH v1 18/47] vidoe: fbdev: vesafb: add missing mtrr_del() for added MTRR
From: Luis R. Rodriguez mcg...@suse.com
The MTRR added was never being deleted.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vesafb.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
index 191156b..a2261d0 100644
--- a/drivers/video/fbdev/vesafb.c
+++ b/drivers/video/fbdev/vesafb.c
@@ -29,6 +29,10 @@
/* - */
+struct vesafb_par {
+ int wc_cookie;
+};
+
static struct fb_var_screeninfo vesafb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
@@ -175,7 +179,16 @@ static int vesafb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static void vesafb_destroy(struct fb_info *info)
{
+#ifdef CONFIG_MTRR
+ struct vesafb_par *par = info-par;
+#endif
+
fb_dealloc_cmap(info-cmap);
+
+#ifdef CONFIG_MTRR
+ if (par-wc_cookie = 0)
+ mtrr_del(par-wc_cookie, 0, 0);
+#endif
if (info-screen_base)
iounmap(info-screen_base);
release_mem_region(info-apertures-ranges[0].base,
info-apertures-ranges[0].size);
@@ -228,6 +241,7 @@ static int vesafb_setup(char *options)
static int vesafb_probe(struct platform_device *dev)
{
struct fb_info *info;
+ struct vesafb_par *par;
int i, err;
unsigned int size_vmode;
unsigned int size_remap;
@@ -297,8 +311,8 @@ static int vesafb_probe(struct platform_device *dev)
return -ENOMEM;
}
platform_set_drvdata(dev, info);
- info-pseudo_palette = info-par;
- info-par = NULL;
+ info-pseudo_palette = NULL;
+ par = info-par;
/* set vesafb aperture size for generic probing */
info-apertures = alloc_apertures(1);
@@ -407,17 +421,17 @@ static int vesafb_probe(struct platform_device *dev)
if (mtrr == 3) {
#ifdef CONFIG_MTRR
unsigned int temp_size = size_total;
- int rc;
/* 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(vesafb_fix.smem_start, temp_size,
- MTRR_TYPE_WRCOMB, 1);
+ par-wc_cookie = mtrr_add(vesafb_fix.smem_start,
+ temp_size,
+ MTRR_TYPE_WRCOMB, 1);
temp_size = 1;
- } while (temp_size = PAGE_SIZE rc == -EINVAL);
+ } while (temp_size = PAGE_SIZE par-wc_cookie == -EINVAL);
#endif
info-screen_base = ioremap_wc(vesafb_fix.smem_start,
vesafb_fix.smem_len);
} else {
@@ -462,6 +476,10 @@ static int vesafb_probe(struct platform_device *dev)
fb_info(info, %s frame buffer device\n, info-fix.id);
return 0;
err:
+#ifdef CONFIG_MTRR
+ if (par-wc_cookie = 0)
+ mtrr_del(par-wc_cookie, 0, 0);
+#endif
if (info-screen_base)
iounmap(info-screen_base);
framebuffer_release(info);
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 23/47] staging: xgifb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/staging/xgifb/XGI_main_26.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c
b/drivers/staging/xgifb/XGI_main_26.c
index 74e8820..943d463 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -8,10 +8,7 @@
#include linux/sizes.h
#include linux/module.h
-
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
+#include linux/pci.h
#include XGI_main.h
#include vb_init.h
@@ -1770,7 +1767,7 @@ static int xgifb_probe(struct pci_dev *pdev,
}
xgifb_info-video_vbase = hw_info-pjVideoMemoryAddress =
- ioremap(xgifb_info-video_base, xgifb_info-video_size);
+ ioremap_wc(xgifb_info-video_base, xgifb_info-video_size);
xgifb_info-mmio_vbase = ioremap(xgifb_info-mmio_base,
xgifb_info-mmio_size);
@@ -2014,12 +2011,8 @@ static int xgifb_probe(struct pci_dev *pdev,
fb_alloc_cmap(fb_info-cmap, 256, 0);
-#ifdef CONFIG_MTRR
- xgifb_info-mtrr = mtrr_add(xgifb_info-video_base,
- xgifb_info-video_size, MTRR_TYPE_WRCOMB, 1);
- if (xgifb_info-mtrr = 0)
- dev_info(pdev-dev, Added MTRR\n);
-#endif
+ xgifb_info-mtrr = arch_phys_wc_add(xgifb_info-video_base,
+ xgifb_info-video_size);
if (register_framebuffer(fb_info) 0) {
ret = -EINVAL;
@@ -2031,11 +2024,7 @@ static int xgifb_probe(struct pci_dev *pdev,
return 0;
error_mtrr:
-#ifdef CONFIG_MTRR
- if (xgifb_info-mtrr = 0)
- mtrr_del(xgifb_info-mtrr, xgifb_info-video_base,
- xgifb_info-video_size);
-#endif /* CONFIG_MTRR */
+ arch_phys_wc_del(xgifb_info-mtrr);
error_1:
iounmap(xgifb_info-mmio_vbase);
iounmap(xgifb_info-video_vbase);
@@ -2059,11 +2048,7 @@ static void xgifb_remove(struct pci_dev *pdev)
struct fb_info *fb_info = xgifb_info-fb_info;
unregister_framebuffer(fb_info);
-#ifdef CONFIG_MTRR
- if (xgifb_info-mtrr = 0)
- mtrr_del(xgifb_info-mtrr, xgifb_info-video_base,
- xgifb_info-video_size);
-#endif /* CONFIG_MTRR */
+ arch_phys_wc_del(xgifb_info-mtrr);
iounmap(xgifb_info-mmio_vbase);
iounmap(xgifb_info-video_vbase);
release_mem_region
[PATCH v1 34/47] video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/sis/sis.h | 2 +-
drivers/video/fbdev/sis/sis_main.c | 27 ++-
2 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis.h b/drivers/video/fbdev/sis/sis.h
index 1987f1b7..ea1d1c9 100644
--- a/drivers/video/fbdev/sis/sis.h
+++ b/drivers/video/fbdev/sis/sis.h
@@ -458,7 +458,7 @@ struct sis_video_info {
unsigned char *bios_abase;
- int mtrr;
+ int wc_cookie;
u32 sisfb_mem;
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index fcf610e..e923038 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -53,9 +53,6 @@
#include linux/types.h
#include linux/uaccess.h
#include asm/io.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include sis.h
#include sis_main.h
@@ -4130,13 +4127,13 @@ static void sisfb_post_map_vram(struct sis_video_info
*ivideo,
if (*mapsize (min 20))
return;
- ivideo-video_vbase = ioremap(ivideo-video_base, (*mapsize));
+ ivideo-video_vbase = ioremap_wc(ivideo-video_base, (*mapsize));
if(!ivideo-video_vbase) {
printk(KERN_ERR
sisfb: Unable to map maximum video RAM for size
detection\n);
(*mapsize) = 1;
- while((!(ivideo-video_vbase = ioremap(ivideo-video_base,
(*mapsize) {
+ while((!(ivideo-video_vbase = ioremap_wc(ivideo-video_base,
(*mapsize) {
(*mapsize) = 1;
if((*mapsize) (min 20))
break;
@@ -6186,7 +6183,7 @@ static int sisfb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto error_2;
}
- ivideo-video_vbase = ioremap(ivideo-video_base, ivideo-video_size);
+ ivideo-video_vbase = ioremap_wc(ivideo-video_base,
ivideo-video_size);
ivideo-SiS_Pr.VideoMemoryAddress = ivideo-video_vbase;
if(!ivideo-video_vbase) {
printk(KERN_ERR sisfb: Fatal error: Unable to map framebuffer
memory\n);
@@ -6254,8 +6251,6 @@ error_3: vfree(ivideo-bios_abase);
ivideo-SiS_Pr.VideoMemoryAddress += ivideo-video_offset;
ivideo-SiS_Pr.VideoMemorySize = ivideo-sisfb_mem;
- ivideo-mtrr = -1;
-
ivideo-vbflags = 0
[PATCH v1 04/47] pci: add pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 81f06e8..6afd507 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -137,6 +137,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
bar)
pci_resource_len(pdev, bar));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
+ return ioremap_wc(pci_resource_start(pdev, bar),
+ pci_resource_len(pdev, bar));
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
#define PCI_FIND_CAP_TTL 48
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 211e9da..c235b09 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1667,6 +1667,7 @@ static inline void pci_mmcfg_late_init(void) { }
int pci_ext_cfg_avail(void);
void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
#ifdef CONFIG_PCI_IOV
int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 14/47] IB/ipath: use __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver sadly does not have the MMIO registers and WC
desired areas (PIO buffers in this case) properly split up
and addressing a split is considerable work, as such this
such requires using the __arch_phys_wc_add() call to
ensure write combining is enforced using MTRR on x86
even when PAT is available.
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_driver.c| 7 ++--
drivers/infiniband/hw/ipath/ipath_kernel.h| 4 +--
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 47 ++-
3 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..464f39c 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -542,6 +542,7 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
#else
+ /* XXX: split pio on a separate ioremap_wc() */
dd-ipath_kregbase = ioremap_nocache(addr, len);
#endif
@@ -587,12 +588,8 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ret = ipath_enable_wc(dd);
- if (ret) {
- ipath_dev_err(dd, Write combining not enabled
- (err %d): performance may be poor\n,
- -ret);
+ if (ret)
ret = 0;
- }
ipath_verify_pioperf(dd);
diff --git a/drivers/infiniband/hw/ipath/ipath_kernel.h
b/drivers/infiniband/hw/ipath/ipath_kernel.h
index e08db70..f0f9471 100644
--- a/drivers/infiniband/hw/ipath/ipath_kernel.h
+++ b/drivers/infiniband/hw/ipath/ipath_kernel.h
@@ -463,9 +463,7 @@ struct ipath_devdata {
/* offset in HT config space of slave/primary interface block */
u8 ipath_ht_slave_off;
/* for write combining settings */
- unsigned long ipath_wc_cookie;
- unsigned long ipath_wc_base;
- unsigned long ipath_wc_len;
+ int wc_cookie;
/* ref count for each pkey */
atomic_t ipath_pkeyrefs[4];
/* shadow copy of struct page *'s for exp tid pages */
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 70c1f3a..88709c1 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -37,7 +37,6 @@
*/
#include linux/pci.h
-#include asm/mtrr.h
#include asm/processor.h
#include ipath_kernel.h
@@ -122,27 +121,26 @@ int ipath_enable_wc(struct ipath_devdata *dd)
}
if (!ret) {
- int cookie;
ipath_cdbg(VERBOSE, Setting mtrr for chip to WC
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
- if (cookie 0) {
- {
- dev_info(dd-pcidev-dev,
-mtrr_add() WC for PIO bufs
-failed (%d)\n,
-cookie);
- ret = -EINVAL;
- }
- } else {
- ipath_cdbg(VERBOSE, Set mtrr for chip to WC,
- cookie is %d\n, cookie);
- dd-ipath_wc_cookie = cookie;
- dd-ipath_wc_base = (unsigned long) pioaddr;
- dd-ipath_wc_len = (unsigned long) piolen
[PATCH v1 20/47] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()
From: Luis R. Rodriguez mcg...@suse.com
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/include/asm/io.h | 2 ++
arch/x86/include/asm/mtrr.h | 5 -
arch/x86/kernel/cpu/mtrr/main.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 14 +-
include/linux/io.h | 6 ++
5 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index a144d05..5e3f1f2 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -346,6 +346,8 @@ extern int __must_check arch_phys_wc_add(unsigned long base,
unsigned long size);
extern void arch_phys_wc_del(int handle);
#define arch_phys_wc_add arch_phys_wc_add
+extern int arch_phys_wc_index(int handle);
+#define arch_phys_wc_index arch_phys_wc_index
#endif
#endif /* _ASM_X86_IO_H */
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index cade917..380bb4b 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -49,7 +49,6 @@ 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);
-extern int phys_wc_to_mtrr_index(int handle);
# else
static const int mtrr_enabled;
static inline u8 mtrr_type_lookup(u64 addr, u64 end)
@@ -86,10 +85,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long
end_pfn)
static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
{
}
-static inline int phys_wc_to_mtrr_index(int handle)
-{
- return -1;
-}
#define mtrr_ap_init() do {} while (0)
#define mtrr_bp_init() do {} while (0)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 5ae830b..b68b671 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -607,7 +607,7 @@ void arch_phys_wc_del(int handle)
EXPORT_SYMBOL(arch_phys_wc_del);
/*
- * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
+ * arch_phys_wc_index - translates arch_phys_wc_add's return value
* @handle: Return value from arch_phys_wc_add
*
* This will turn the return value from arch_phys_wc_add into an mtrr
@@ -617,14 +617,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
* in printk line. Alas there is an illegitimate use in some ancient
* drm ioctls.
*/
-int phys_wc_to_mtrr_index(int handle)
+int arch_phys_wc_index(int handle)
{
if (handle MTRR_TO_PHYS_WC_OFFSET)
return -1;
else
return handle - MTRR_TO_PHYS_WC_OFFSET;
}
-EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
+EXPORT_SYMBOL_GPL(arch_phys_wc_index);
/*
* HACK ALERT!
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a6d773a..e597cdd 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,9 +36,6 @@
#include linux/pci.h
#include linux/export.h
-#ifdef CONFIG_X86
-#include asm/mtrr.h
-#endif
static int drm_version(struct drm_device *dev, void *data,
struct drm_file *file_priv);
@@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
map-type = r_list-map-type;
map-flags = r_list-map-flags;
map-handle = (void *)(unsigned long) r_list-user_token;
-
-#ifdef CONFIG_X86
- /*
-* There appears to be exactly one user of the mtrr index: dritest.
-* It's easy enough to keep it working on non-PAT systems.
-*/
- map-mtrr = phys_wc_to_mtrr_index(r_list-map-mtrr);
-#else
- map-mtrr = -1;
-#endif
+ map-mtrr = arch_phys_wc_index(r_list-map-mtrr);
mutex_unlock(dev-struct_mutex);
diff --git a/include/linux/io.h b/include/linux/io.h
index ecc51c3..1676437 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -115,6 +115,12 @@ static inline void arch_phys_wc_del(int handle)
#define __arch_phys_wc_add arch_phys_wc_add
#endif
+#ifndef arch_phys_wc_index
+static inline int arch_phys_wc_index(int handle)
+{
+ return -1;
+}
+#define arch_phys_wc_index arch_phys_wc_index
#endif
#endif /* _LINUX_IO_H */
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from
[PATCH v1 30/47] video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/neofb.c | 26 +++---
include/video/neomagic.h| 5 +
2 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c
index 44f99a6..db023a9 100644
--- a/drivers/video/fbdev/neofb.c
+++ b/drivers/video/fbdev/neofb.c
@@ -71,11 +71,6 @@
#include asm/io.h
#include asm/irq.h
#include asm/pgtable.h
-
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include video/vga.h
#include video/neomagic.h
@@ -1710,6 +1705,7 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
int video_len)
{
//unsigned long addr;
+ struct neofb_par *par = info-par;
DBG(neo_map_video);
@@ -1723,7 +1719,7 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
}
info-screen_base =
- ioremap(info-fix.smem_start, info-fix.smem_len);
+ ioremap_wc(info-fix.smem_start, info-fix.smem_len);
if (!info-screen_base) {
printk(neofb: unable to map screen memory\n);
release_mem_region(info-fix.smem_start,
@@ -1733,11 +1729,8 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
printk(KERN_INFO neofb: mapped framebuffer at %p\n,
info-screen_base);
-#ifdef CONFIG_MTRR
- ((struct neofb_par *)(info-par))-mtrr =
- mtrr_add(info-fix.smem_start, pci_resource_len(dev, 0),
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ pci_resource_len(dev, 0));
/* Clear framebuffer, it's all white in memory after boot */
memset_io(info-screen_base, 0, info-fix.smem_len);
@@ -1754,16 +1747,11 @@ static int neo_map_video(struct fb_info *info, struct
pci_dev *dev,
static void neo_unmap_video(struct fb_info *info)
{
- DBG(neo_unmap_video);
+ struct neofb_par *par = info-par;
-#ifdef CONFIG_MTRR
- {
- struct neofb_par *par = info-par;
+ DBG(neo_unmap_video);
- mtrr_del(par-mtrr, info-fix.smem_start,
-info-fix.smem_len);
- }
-#endif
+ arch_phys_wc_del(par-wc_cookie);
iounmap(info-screen_base);
info-screen_base = NULL;
diff --git a/include/video/neomagic.h b/include/video/neomagic.h
index bc5013e..91e225a 100644
[PATCH v1 40/47] video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/pm3fb.c | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/pm3fb.c b/drivers/video/fbdev/pm3fb.c
index 77b99ed..6ff5077 100644
--- a/drivers/video/fbdev/pm3fb.c
+++ b/drivers/video/fbdev/pm3fb.c
@@ -32,9 +32,6 @@
#include linux/fb.h
#include linux/init.h
#include linux/pci.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include video/pm3fb.h
@@ -58,11 +55,7 @@
static int hwcursor = 1;
static char *mode_option;
static bool noaccel;
-
-/* mtrr option */
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
/*
* This structure defines the hardware state of the graphics card. Normally
@@ -76,7 +69,7 @@ struct pm3_par {
u32 video; /* video flags before blanking */
u32 base; /* screen base in 128 bits unit */
u32 palette[16];
- int mtrr_handle;
+ int wc_cookie;
};
/*
@@ -1374,8 +1367,8 @@ static int pm3fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
printk(KERN_WARNING pm3fb: Can't reserve smem.\n);
goto err_exit_mmio;
}
- info-screen_base =
- ioremap_nocache(pm3fb_fix.smem_start, pm3fb_fix.smem_len);
+ info-screen_base = ioremap_wc(pm3fb_fix.smem_start,
+ pm3fb_fix.smem_len);
if (!info-screen_base) {
printk(KERN_WARNING pm3fb: Can't ioremap smem area.\n);
release_mem_region(pm3fb_fix.smem_start, pm3fb_fix.smem_len);
@@ -1383,12 +1376,9 @@ static int pm3fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
}
info-screen_size = pm3fb_fix.smem_len;
-#ifdef CONFIG_MTRR
if (!nomtrr)
- par-mtrr_handle = mtrr_add(pm3fb_fix.smem_start,
- pm3fb_fix.smem_len,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par-wc_cookie = arch_phys_wc_add(pm3fb_fix.smem_start,
+ pm3fb_fix.smem_len);
info-fbops = pm3fb_ops;
par-video = PM3_READ_REG(par, PM3VideoControl);
@@ -1478,11 +1468,7 @@ static void pm3fb_remove(struct pci_dev *dev)
unregister_framebuffer(info);
fb_dealloc_cmap(info-cmap
[PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
From: Luis R. Rodriguez mcg...@suse.com
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
to kick through fully functionally. This can happen
for instance on Xen where MTRR is not supported but
PAT is, this can happen now on Linux as of commit
47591df50 by Juergen introduced as of v3.19.
Technically we should assume the proper CPU
bits would be set to disable MTRR but we can't
always rely on this. At least on the Xen Hypervisor
for instance only X86_FEATURE_MTRR was disabled
as of Xen 4.4 through Xen commit 586ab6a [0],
but not X86_FEATURE_K6_MTRR, X86_FEATURE_CENTAUR_MCR,
or X86_FEATURE_CYRIX_ARR for instance.
x86 mtrr code relies on quite a bit of checks for
mtrr_if being set to check to see if MTRR did get
set up, instead of using that lets provide a generic
setter which when set we know MTRR is enabled. This
also adds a few checks where they were not before
which could potentially safeguard ourselves against
incorrect usage of MTRR where this was not desirable.
Where possible match error codes as if MTRR was
disabled on arch/x86/include/asm/mtrr.h.
Lastly, since disabling MTRR can happen at run time
and we could end up with PAT enabled best record now
on our logs when MTRR is disabled.
[0] ~/devel/xen (git::stable-4.5)$ git describe --contains 586ab6a
4.4.0-rc1~18
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: bhelg...@google.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/include/asm/mtrr.h| 2 ++
arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
arch/x86/kernel/cpu/mtrr/generic.c | 5 +++--
arch/x86/kernel/cpu/mtrr/if.c | 3 +++
arch/x86/kernel/cpu/mtrr/main.c| 31 ++-
5 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index f768f62..cade917 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -31,6 +31,7 @@
* arch_phys_wc_add and arch_phys_wc_del.
*/
# ifdef CONFIG_MTRR
+extern int mtrr_enabled;
extern u8 mtrr_type_lookup(u64 addr, u64 end);
extern void mtrr_save_fixed_ranges(void *);
extern void mtrr_save_state(void);
@@ -50,6 +51,7 @@ extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
extern int amd_special_default_mtrr(void);
extern int phys_wc_to_mtrr_index(int handle);
# else
+static const int mtrr_enabled;
static inline u8 mtrr_type_lookup(u64 addr, u64 end)
{
/*
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c
b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 5f90b85..784dc55 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -880,7 +880,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
* Make sure we only trim uncachable memory on machines that
* support the Intel MTRR architecture:
*/
- if (!is_cpu(INTEL) || disable_mtrr_trim)
+ if (!is_cpu(INTEL) || disable_mtrr_trim || !mtrr_enabled)
return 0;
rdmsr(MSR_MTRRdefType, def, dummy);
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index 09c82de..df321b2 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -116,7 +116,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64
*partial_end, int *repeat)
u8 prev_match, curr_match;
*repeat = 0;
- if (!mtrr_state_set)
+ /* generic_mtrr_ops is only set for generic_mtrr_ops */
+ if (!mtrr_state_set || !mtrr_enabled)
return 0xFF;
if (!mtrr_state.enabled)
@@ -290,7 +291,7 @@ static void get_fixed_ranges(mtrr_type *frs)
void mtrr_save_fixed_ranges(void *info)
{
- if (cpu_has_mtrr)
+ if (mtrr_enabled cpu_has_mtrr)
get_fixed_ranges(mtrr_state.fixed_ranges);
}
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index d76f13d..e9e001a 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -436,6 +436,9 @@ static int __init mtrr_if_init(void)
{
struct cpuinfo_x86 *c = boot_cpu_data;
+ if (!mtrr_enabled
[PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
From: Luis R. Rodriguez mcg...@suse.com
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap() the full framebuffer
including the MMIO space *and* ___then___ use an MTRR with
MTRR_TYPE_WRCOMB on the full PCI BAR... and finally hole
in an MTRR_TYPE_UNCACHABLE MTRR only for MMIO.
This is a terrible fucking work around, and should by no means
be necessary however evidence through a large series of conversion
of drivers to ioremap_wc() for the framebuffer shows that around
the time MTRR started becoming popular devices did not have things
lined up for easily separating the framebuffer and MMIO register
access. In some cases a driver requires significant intrusive
changes in order to make the split for an ioremap() for MMIO registers
and another ioremap_wc() for the framebuffer, at other times a
bit of careful study of the driver suffices. This example driver
falls into the later category.
We can replace the MTRR MTRR_TYPE_UNCACHABLE
work around by using ioremap_nocache(), the length of the
MMIO space should already be correct. The other part we
need to correct is ensuring we ioremap() for the framebuffer
only the required size. Since the ioremap() happens early
on probe for PCI devices before aty_init() where we typically
adjust the length and know how to do it, we can fix this by
pegging the bus type as PCI on PCI probe, and finally fudging
and framebuffer length just as we do on aty_init().
The last thing we do must do to remain sane is ensure we
use the info-fix.smem_start and info-fix.smem_len for
the framebuffer MTRR as we know that is always well adjusted.
The *one* concern here would be if the MTRR is not in units
of 4K __but__ we already know that in the PCI case this cannot
happen, in the shared space setting the MTRR would be up to
0x7ff000 and assuming a 4K page:
; 0x7ff000 / 0x1000
2047
Also, internally when MTRR is used mtrr_add() will use mtrr_check()
and that should splat a warning when the MTRR base and size are
not compatible with what is expected for MTRR usage.
This fix lets us nuke the MTRR_TYPE_UNCACHABLE MTRR hole.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 28 ++--
2 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 1f39a62..89ec439 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -184,7 +184,6 @@ struct atyfb_par {
spinlock_t int_lock;
#ifdef CONFIG_MTRR
int mtrr_aper;
- int mtrr_reg;
#endif
u32 mem_cntl;
struct crtc saved_crtc;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr_aper = 0 !par-aux_start) {
- /* Make a hole for mmio. */
- par-mtrr_reg = mtrr_add(par-res_start + 0x80 -
-GUI_RESERVE, GUI_RESERVE,
-MTRR_TYPE_UNCACHABLE, 1);
- if (par-mtrr_reg 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
- }
}
#endif
@@ -2776,10 +2765,6 @@ aty_init_exit:
par-pll_ops-set_pll(info, par-saved_pll);
#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
if (par-mtrr_aper = 0) {
mtrr_del(par
[PATCH v1 12/47] IB/qib: use arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Dennis Dalessandro dennis.dalessan...@intel.com
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
index fe0850a..6d61ef9 100644
--- a/drivers/infiniband/hw/qib/qib_wc_x86_64.c
+++ b/drivers/infiniband/hw/qib/qib_wc_x86_64.c
@@ -116,21 +116,9 @@ int qib_enable_wc(struct qib_devdata *dd)
}
if (!ret) {
- int cookie;
-
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
- if (cookie 0) {
- {
- qib_devinfo(dd-pcidev,
-mtrr_add() WC for PIO bufs failed
(%d)\n,
-cookie);
- ret = -EINVAL;
- }
- } else {
- dd-wc_cookie = cookie;
- dd-wc_base = (unsigned long) pioaddr;
- dd-wc_len = (unsigned long) piolen;
- }
+ dd-wc_cookie = arch_phys_wc_add(pioaddr, piolen);
+ if (dd-wc_cookie 0)
+ ret = -EINVAL;
}
return ret;
@@ -142,18 +130,7 @@ int qib_enable_wc(struct qib_devdata *dd)
*/
void qib_disable_wc(struct qib_devdata *dd)
{
- if (dd-wc_cookie) {
- int r;
-
- r = mtrr_del(dd-wc_cookie, dd-wc_base,
-dd-wc_len);
- if (r 0)
- qib_devinfo(dd-pcidev,
-mtrr_del(%lx, %lx, %lx) failed: %d\n,
-dd-wc_cookie, dd-wc_base,
-dd-wc_len, r);
- dd-wc_cookie = 0; /* even on failure */
- }
+ arch_phys_wc_del(dd-wc_cookie);
}
/**
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 15/47] [media] media: ivtv: use __arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
Sadly this driver requires a bit of work in order
to use ioremap_wc() on the range currently used
for MTRR write-combining. We'd need to ensure two
ioremap() calls are done. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-me...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/media/pci/ivtv/ivtvfb.c | 51 +++--
1 file changed, 14 insertions(+), 37 deletions(-)
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..ceefa6f 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,10 +44,6 @@
#include linux/ivtvfb.h
#include linux/slab.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include ivtv-driver.h
#include ivtv-cards.h
#include ivtv-i2c.h
@@ -155,12 +151,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+ int wc_cookie;
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1094,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
static int ivtvfb_init_io(struct ivtv *itv)
{
struct osd_info *oi = itv-osd_info;
+ /* Find the largest power of two that maps the whole buffer */
+ int size_shift = 31;
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1129,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
-#ifdef CONFIG_MTRR
- {
- /* Find the largest power of two that maps the whole buffer */
- int size_shift = 31;
-
- while (!(oi-video_buffer_size (1 size_shift))) {
- size_shift--;
- }
- size_shift++;
- oi-fb_start_aligned_physaddr = oi-video_pbase ~((1
size_shift) - 1);
- oi-fb_end_aligned_physaddr = oi-video_pbase +
oi-video_buffer_size;
- oi-fb_end_aligned_physaddr += (1 size_shift) - 1;
- oi-fb_end_aligned_physaddr = ~((1 size_shift) - 1);
- if (mtrr_add(oi-fb_start_aligned_physaddr,
- oi-fb_end_aligned_physaddr -
oi-fb_start_aligned_physaddr,
-MTRR_TYPE_WRCOMB, 1) 0) {
- IVTVFB_INFO(disabled mttr\n);
- oi-fb_start_aligned_physaddr = 0;
- oi-fb_end_aligned_physaddr = 0;
- }
- }
-#endif
-
+ while (!(oi-video_buffer_size (1 size_shift)))
+ size_shift--;
+ size_shift++;
+ oi-fb_start_aligned_physaddr = oi-video_pbase ~((1 size_shift) -
1);
+ oi-fb_end_aligned_physaddr = oi-video_pbase + oi-video_buffer_size;
+ oi-fb_end_aligned_physaddr += (1 size_shift) - 1;
+ oi-fb_end_aligned_physaddr = ~((1 size_shift) - 1);
+ oi-wc_cookie = __arch_phys_wc_add(oi-fb_start_aligned_physaddr,
+ oi-fb_end_aligned_physaddr -
+ oi-fb_start_aligned_physaddr);
/* Blank the entire osd. */
memset_io(oi-video_vbase, 0, oi-video_buffer_size);
@@ -1172,14 +1156,7 @@ static void ivtvfb_release_buffers (struct ivtv *itv)
/* Release pseudo palette */
kfree(oi-ivtvfb_info.pseudo_palette);
-
-#ifdef CONFIG_MTRR
- if (oi-fb_end_aligned_physaddr) {
- mtrr_del(-1, oi-fb_start_aligned_physaddr,
- oi-fb_end_aligned_physaddr -
oi-fb_start_aligned_physaddr);
- }
-#endif
-
+ arch_phys_wc_del(oi-wc_cookie);
kfree(oi
[PATCH v1 21/47] ethernet: myri10ge: use arch_phys_wc_add()
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Hyong-Youb Kim hy...@myri.com
Cc: net...@vger.kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 36 ++--
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index 1412f5a..01e4069 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -69,11 +69,7 @@
#include net/ip.h
#include net/tcp.h
#include asm/byteorder.h
-#include asm/io.h
#include asm/processor.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include net/busy_poll.h
#include myri10ge_mcp.h
@@ -242,8 +238,7 @@ struct myri10ge_priv {
unsigned int rdma_tags_available;
int intr_coal_delay;
__be32 __iomem *intr_coal_delay_ptr;
- int mtrr;
- int wc_enabled;
+ int wc_cookie;
int down_cnt;
wait_queue_head_t down_wq;
struct work_struct watchdog_work;
@@ -1984,7 +1979,6 @@ myri10ge_get_ethtool_stats(struct net_device *netdev,
data[i] = ((u64 *)link_stats)[i];
data[i++] = (unsigned int)mgp-tx_boundary;
- data[i++] = (unsigned int)mgp-wc_enabled;
data[i++] = (unsigned int)mgp-pdev-irq;
data[i++] = (unsigned int)mgp-msi_enabled;
data[i++] = (unsigned int)mgp-msix_enabled;
@@ -4040,14 +4034,7 @@ static int myri10ge_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
mgp-board_span = pci_resource_len(pdev, 0);
mgp-iomem_base = pci_resource_start(pdev, 0);
- mgp-mtrr = -1;
- mgp-wc_enabled = 0;
-#ifdef CONFIG_MTRR
- mgp-mtrr = mtrr_add(mgp-iomem_base, mgp-board_span,
-MTRR_TYPE_WRCOMB, 1);
- if (mgp-mtrr = 0)
- mgp-wc_enabled = 1;
-#endif
+ mgp-wc_cookie = arch_phys_wc_add(mgp-iomem_base, mgp-board_span);
mgp-sram = ioremap_wc(mgp-iomem_base, mgp-board_span);
if (mgp-sram == NULL) {
dev_err(pdev-dev, ioremap failed for %ld bytes at 0x%lx\n,
@@ -4146,14 +4133,14 @@ static int myri10ge_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
goto abort_with_state;
}
if (mgp-msix_enabled)
- dev_info(dev, %d MSI-X IRQs, tx bndry %d, fw %s, WC %s\n,
+ dev_info(dev, %d MSI-X IRQs, tx bndry %d, fw %s, MTRR %s, WC
Enabled\n,
mgp-num_slices, mgp-tx_boundary, mgp-fw_name,
-(mgp-wc_enabled ? Enabled : Disabled));
+(mgp-wc_cookie 0 ? Enabled : Disabled));
else
- dev_info(dev, %s IRQ %d, tx bndry %d, fw %s, WC %s\n,
+ dev_info(dev, %s IRQ %d, tx bndry %d, fw %s, MTRR %s, WC
Enabled\n,
mgp-msi_enabled ? MSI : xPIC,
pdev-irq, mgp-tx_boundary, mgp-fw_name,
-(mgp-wc_enabled ? Enabled : Disabled));
+(mgp-wc_cookie 0 ? Enabled : Disabled));
board_number++;
return 0;
@@ -4175,10 +4162,7 @@ abort_with_ioremap:
iounmap(mgp-sram);
abort_with_mtrr:
-#ifdef CONFIG_MTRR
- if (mgp-mtrr = 0)
- mtrr_del(mgp-mtrr, mgp-iomem_base, mgp-board_span);
-#endif
+ arch_phys_wc_del(mgp-wc_cookie);
dma_free_coherent(pdev-dev, sizeof(*mgp-cmd),
mgp-cmd, mgp-cmd_bus);
@@ -4220,11 +4204,7 @@ static void myri10ge_remove(struct pci_dev *pdev)
pci_restore_state(pdev);
iounmap(mgp-sram);
-
-#ifdef CONFIG_MTRR
- if (mgp-mtrr = 0)
- mtrr_del(mgp-mtrr, mgp-iomem_base, mgp-board_span);
-#endif
+ arch_phys_wc_del(mgp-wc_cookie);
myri10ge_free_slices(mgp);
kfree(mgp-msix_vectors);
dma_free_coherent(pdev-dev, sizeof(*mgp-cmd),
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 26/47] video: fbdev: gbefb: add missing mtrr_del() calls
From: Luis R. Rodriguez mcg...@suse.com
This driver never removed the MTRRs. Fix that.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/gbefb.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 6d9ef39..f48ea7e 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -38,6 +38,7 @@ static struct sgi_gbe *gbe;
struct gbefb_par {
struct fb_var_screeninfo var;
struct gbe_timing_info timing;
+ int wc_cookie;
int valid;
};
@@ -1199,7 +1200,8 @@ static int gbefb_probe(struct platform_device *p_dev)
}
#ifdef CONFIG_X86
- mtrr_add(gbe_mem_phys, gbe_mem_size, MTRR_TYPE_WRCOMB, 1);
+ info-wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
+ MTRR_TYPE_WRCOMB, 1);
#endif
/* map framebuffer memory into tiles table */
@@ -1240,6 +1242,10 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
out_gbe_unmap:
+#ifdef CONFIG_MTRR
+ if (info-wc_cookie = 0)
+ mtrr_del(info-wc_cookie, 0, 0);
+#endif
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
out_tiles_free:
@@ -1259,6 +1265,10 @@ static int gbefb_remove(struct platform_device* p_dev)
unregister_framebuffer(info);
gbe_turn_off();
+#ifdef CONFIG_MTRR
+ if (info-wc_cookie = 0)
+ mtrr_del(info-wc_cookie, 0, 0);
+#endif
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 32/47] video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR and ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/nvidia/nv_type.h | 7 +--
drivers/video/fbdev/nvidia/nvidia.c | 37 ++--
2 files changed, 7 insertions(+), 37 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_type.h
b/drivers/video/fbdev/nvidia/nv_type.h
index c03f7f5..6ff321a 100644
--- a/drivers/video/fbdev/nvidia/nv_type.h
+++ b/drivers/video/fbdev/nvidia/nv_type.h
@@ -148,12 +148,7 @@ struct nvidia_par {
u32 forceCRTC;
u32 open_count;
u8 DDCBase;
-#ifdef CONFIG_MTRR
- struct {
- int vram;
- int vram_valid;
- } mtrr;
-#endif
+ int wc_cookie;
struct nvidia_i2c_chan chan[3];
volatile u32 __iomem *REGS;
diff --git a/drivers/video/fbdev/nvidia/nvidia.c
b/drivers/video/fbdev/nvidia/nvidia.c
index def0412..781f5e7 100644
--- a/drivers/video/fbdev/nvidia/nvidia.c
+++ b/drivers/video/fbdev/nvidia/nvidia.c
@@ -21,9 +21,6 @@
#include linux/pci.h
#include linux/console.h
#include linux/backlight.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -80,9 +77,7 @@ static int paneltweak = 0;
static int vram = 0;
static int bpp = 8;
static int reverse_i2c;
-#ifdef CONFIG_MTRR
static bool nomtrr = false;
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
static int backlight = 1;
#else
@@ -1365,7 +1360,8 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
par-ScratchBufferStart = par-FbUsableSize - par-ScratchBufferSize;
par-CursorStart = par-FbUsableSize + (32 * 1024);
- info-screen_base = ioremap(nvidiafb_fix.smem_start, par-FbMapSize);
+ info-screen_base = ioremap_wc(nvidiafb_fix.smem_start,
+ par-FbMapSize);
info-screen_size = par-FbUsableSize;
nvidiafb_fix.smem_len = par-RamAmountKBytes * 1024;
@@ -1376,20 +1372,9 @@ static int nvidiafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
par-FbStart = info-screen_base;
-#ifdef CONFIG_MTRR
- if (!nomtrr) {
- par-mtrr.vram = mtrr_add(nvidiafb_fix.smem_start,
- par-RamAmountKBytes * 1024,
- MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr.vram 0) {
- printk(KERN_ERR PFX unable to setup MTRR\n);
- } else
[PATCH v1 37/47] video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/i740fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c
index a2b4204..452e116 100644
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -27,24 +27,15 @@
#include linux/console.h
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include i740_reg.h
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
struct i740fb_par {
unsigned char __iomem *regs;
bool has_sgram;
-#ifdef CONFIG_MTRR
- int mtrr_reg;
-#endif
+ int wc_cookie;
bool ddc_registered;
struct i2c_adapter ddc_adapter;
struct i2c_algo_bit_data ddc_algo;
@@ -1040,7 +1031,7 @@ static int i740fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
goto err_request_regions;
}
- info-screen_base = pci_ioremap_bar(dev, 0);
+ info-screen_base = pci_ioremap_wc_bar(dev, 0);
if (!info-screen_base) {
dev_err(info-device, error remapping base\n);
ret = -ENOMEM;
@@ -1144,13 +1135,9 @@ static int i740fb_probe(struct pci_dev *dev, const
struct pci_device_id *ent)
fb_info(info, %s frame buffer device\n, info-fix.id);
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
- info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
err_reg_framebuffer:
@@ -1177,13 +1164,7 @@ static void i740fb_remove(struct pci_dev *dev)
if (info) {
struct i740fb_par *par = info-par;
-
-#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
-#endif
+ arch_phys_wc_del(par-wc_cookie);
unregister_framebuffer(info);
fb_dealloc_cmap(info-cmap);
if (par-ddc_registered)
@@ -1287,10 +1268,8 @@ static int __init i740fb_setup(char *options)
while ((opt = strsep(options, ,)) != NULL) {
if (!*opt
[PATCH v1 41/47] video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/riva/fbdev.c | 39 +++
drivers/video/fbdev/riva/rivafb.h | 4 +---
2 files changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index be73727..854b86d 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -41,9 +41,6 @@
#include linux/pci.h
#include linux/backlight.h
#include linux/bitrev.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -208,9 +205,7 @@ MODULE_DEVICE_TABLE(pci, rivafb_pci_tbl);
static int flatpanel = -1; /* Autodetect later */
static int forceCRTC = -1;
static bool noaccel = 0;
-#ifdef CONFIG_MTRR
static bool nomtrr = 0;
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
static int backlight = 1;
#else
@@ -2013,28 +2008,18 @@ static int rivafb_probe(struct pci_dev *pd, const
struct pci_device_id *ent)
rivafb_fix.smem_len = riva_get_memlen(default_par) * 1024;
default_par-dclk_max = riva_get_maxdclk(default_par) * 1000;
- info-screen_base = ioremap(rivafb_fix.smem_start,
- rivafb_fix.smem_len);
+ info-screen_base = ioremap_wc(rivafb_fix.smem_start,
+ rivafb_fix.smem_len);
if (!info-screen_base) {
printk(KERN_ERR PFX cannot ioremap FB base\n);
ret = -EIO;
goto err_iounmap_pramin;
}
-#ifdef CONFIG_MTRR
- if (!nomtrr) {
- default_par-mtrr.vram = mtrr_add(rivafb_fix.smem_start,
- rivafb_fix.smem_len,
- MTRR_TYPE_WRCOMB, 1);
- if (default_par-mtrr.vram 0) {
- printk(KERN_ERR PFX unable to setup MTRR\n);
- } else {
- default_par-mtrr.vram_valid = 1;
- /* let there be speed */
- printk(KERN_INFO PFX RIVA MTRR set to ON\n);
- }
- }
-#endif /* CONFIG_MTRR */
+ if (!nomtrr)
+ default_par-wc_cookie =
+ arch_phys_wc_add(rivafb_fix.smem_start,
+rivafb_fix.smem_len);
info-fbops = riva_fb_ops;
info-fix = rivafb_fix;
@@ -2108,13
[PATCH v1 42/47] video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/tdfxfb.c | 41 ++---
include/video/tdfx.h | 2 +-
2 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index f761fe3..621fa44 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -78,24 +78,6 @@
#define DPRINTK(a, b...) pr_debug(fb: %s: a, __func__ , ## b)
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#else
-/* duplicate asm/mtrr.h defines to work on archs without mtrr */
-#define MTRR_TYPE_WRCOMB 1
-
-static inline int mtrr_add(unsigned long base, unsigned long size,
- unsigned int type, char increment)
-{
-return -ENODEV;
-}
-static inline int mtrr_del(int reg, unsigned long base,
- unsigned long size)
-{
-return -ENODEV;
-}
-#endif
-
#define BANSHEE_MAX_PIXCLOCK 27
#define VOODOO3_MAX_PIXCLOCK 30
#define VOODOO5_MAX_PIXCLOCK 35
@@ -167,7 +149,6 @@ static int nopan;
static int nowrap = 1; /* not implemented (yet) */
static int hwcursor = 1;
static char *mode_option;
-/* mtrr option */
static bool nomtrr;
/* -
@@ -1454,8 +1435,8 @@ static int tdfxfb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto out_err_regbase;
}
- info-screen_base = ioremap_nocache(info-fix.smem_start,
- info-fix.smem_len);
+ info-screen_base = ioremap_wc(info-fix.smem_start,
+ info-fix.smem_len);
if (!info-screen_base) {
printk(KERN_ERR fb: Can't remap %s framebuffer.\n,
info-fix.id);
@@ -1473,11 +1454,9 @@ static int tdfxfb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
printk(KERN_INFO fb: %s memory = %dK\n, info-fix.id,
info-fix.smem_len 10);
- default_par-mtrr_handle = -1;
if (!nomtrr)
- default_par-mtrr_handle =
- mtrr_add(info-fix.smem_start, info-fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
+ default_par-wc_cookie= arch_phys_wc_add(info-fix.smem_start,
+info-fix.smem_len);
info
[PATCH v1 47/47] mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
From: Luis R. Rodriguez mcg...@suse.com The crusade to replace mtrr_add() with architecture agnostic arch_phys_wc_add() is complete, this will ensure write-combining implementations (PAT on x86) is taken advantage instead of using MTRR. With the crusade done now, hide direct MTRR access for drivers. Cc: Suresh Siddha suresh.b.sid...@intel.com Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com Cc: Ingo Molnar mi...@elte.hu Cc: Thomas Gleixner t...@linutronix.de Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/kernel/cpu/mtrr/main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index b68b671..f0e19db 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -446,7 +446,6 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type, return mtrr_add_page(base PAGE_SHIFT, size PAGE_SHIFT, type, increment); } -EXPORT_SYMBOL(mtrr_add); /** * mtrr_del_page - delete a memory type region @@ -535,7 +534,6 @@ int mtrr_del(int reg, unsigned long base, unsigned long size) return -EINVAL; return mtrr_del_page(reg, base PAGE_SHIFT, size PAGE_SHIFT); } -EXPORT_SYMBOL(mtrr_del); /** * __arch_phys_wc_add - add a WC MTRR even if PAT is available -- 2.3.2.209.gd67f9d5.dirty -- 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 v1 03/47] devres: add devm_ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
Documentation/driver-model/devres.txt | 1 +
include/linux/io.h| 2 ++
lib/devres.c | 29 +
3 files changed, 32 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index e1e2bbd..831a536 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -276,6 +276,7 @@ IOMAP
devm_ioport_unmap()
devm_ioremap()
devm_ioremap_nocache()
+ devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_iounmap()
pcim_iomap()
diff --git a/include/linux/io.h b/include/linux/io.h
index 4cc299c..91101a1 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -72,6 +72,8 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
resource_size_t size);
void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
resource_size_t size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 0f1dd2e..2eb2bfe 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,35 @@ void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap_nocache);
/**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+ resource_size_t size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL_GPL(devm_ioremap_wc);
+
+/**
* devm_iounmap - Managed iounmap()
* @dev: Generic device to unmap for
* @addr: Address to unmap
--
2.3.2.209.gd67f9d5.dirty
--
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 v1 27/47] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/gbefb.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index f48ea7e..ef81215 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -22,9 +22,6 @@
#include linux/module.h
#include linux/io.h
-#ifdef CONFIG_X86
-#include asm/mtrr.h
-#endif
#ifdef CONFIG_MIPS
#include asm/addrspace.h
#endif
@@ -1176,8 +1173,8 @@ static int gbefb_probe(struct platform_device *p_dev)
if (gbe_mem_phys) {
/* memory was allocated at boot time */
- gbe_mem = devm_ioremap_nocache(p_dev-dev, gbe_mem_phys,
- gbe_mem_size);
+ gbe_mem = devm_ioremap_wc(p_dev-dev, gbe_mem_phys,
+ gbe_mem_size);
if (!gbe_mem) {
printk(KERN_ERR gbefb: couldn't map framebuffer\n);
ret = -ENOMEM;
@@ -1188,8 +1185,8 @@ static int gbefb_probe(struct platform_device *p_dev)
} else {
/* try to allocate memory with the classical allocator
* this has high chance to fail on low memory machines */
- gbe_mem = dma_alloc_coherent(NULL, gbe_mem_size, gbe_dma_addr,
-GFP_KERNEL);
+ gbe_mem = dma_alloc_writecombine(NULL, gbe_mem_size,
+gbe_dma_addr, GFP_KERNEL);
if (!gbe_mem) {
printk(KERN_ERR gbefb: couldn't allocate framebuffer
memory\n);
ret = -ENOMEM;
@@ -1199,10 +1196,7 @@ static int gbefb_probe(struct platform_device *p_dev)
gbe_mem_phys = (unsigned long) gbe_dma_addr;
}
-#ifdef CONFIG_X86
- info-wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ info-wc_cookie = arch_phys_wc_add(gbe_mem_phys, gbe_mem_size);
/* map framebuffer memory into tiles table */
for (i = 0; i (gbe_mem_size TILE_SHIFT); i++)
@@ -1242,10 +1236,7 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
out_gbe_unmap:
-#ifdef CONFIG_MTRR
- if (info-wc_cookie = 0)
- mtrr_del(info-wc_cookie, 0, 0);
-#endif
+ arch_phys_wc_del(info-wc_cookie);
if (gbe_dma_addr
[PATCH v1 33/47] video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/savage/savagefb.h| 4 +---
drivers/video/fbdev/savage/savagefb_driver.c | 17 +++--
2 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/video/fbdev/savage/savagefb.h
b/drivers/video/fbdev/savage/savagefb.h
index 8ff4ab1..aba04af 100644
--- a/drivers/video/fbdev/savage/savagefb.h
+++ b/drivers/video/fbdev/savage/savagefb.h
@@ -213,9 +213,7 @@ struct savagefb_par {
void __iomem *vbase;
u32pbase;
u32len;
-#ifdef CONFIG_MTRR
- intmtrr;
-#endif
+ intwc_cookie;
} video;
struct {
diff --git a/drivers/video/fbdev/savage/savagefb_driver.c
b/drivers/video/fbdev/savage/savagefb_driver.c
index 4dbf45f..6c77ab0 100644
--- a/drivers/video/fbdev/savage/savagefb_driver.c
+++ b/drivers/video/fbdev/savage/savagefb_driver.c
@@ -57,10 +57,6 @@
#include asm/irq.h
#include asm/pgtable.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include savagefb.h
@@ -1775,7 +1771,7 @@ static int savage_map_video(struct fb_info *info, int
video_len)
par-video.pbase = pci_resource_start(par-pcidev, resource);
par-video.len = video_len;
- par-video.vbase = ioremap(par-video.pbase, par-video.len);
+ par-video.vbase = ioremap_wc(par-video.pbase, par-video.len);
if (!par-video.vbase) {
printk(savagefb: unable to map screen memory\n);
@@ -1787,11 +1783,7 @@ static int savage_map_video(struct fb_info *info, int
video_len)
info-fix.smem_start = par-video.pbase;
info-fix.smem_len = par-video.len - par-cob_size;
info-screen_base= par-video.vbase;
-
-#ifdef CONFIG_MTRR
- par-video.mtrr = mtrr_add(par-video.pbase, video_len,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par-video.wc_cookie = arch_phys_wc_add(par-video.pbase, video_len);
/* Clear framebuffer, it's all white in memory after boot */
memset_io(par-video.vbase, 0, par-video.len);
@@ -1806,10 +1798,7 @@ static void savage_unmap_video(struct fb_info *info)
DBG(savage_unmap_video);
if (par-video.vbase) {
-#ifdef CONFIG_MTRR
- mtrr_del(par-video.mtrr, par-video.pbase, par-video.len);
-#endif
-
+ arch_phys_wc_del(par-video.wc_cookie);
iounmap(par-video.vbase);
par
[PATCH v1 43/47] video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/vt8623fb.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index ea7f056..60f24828 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
#include linux/console.h /* Why should fb driver call console functions?
because console_lock() */
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct vt8623fb_info {
char __iomem *mmio_base;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
/* Module parameters */
static char *mode_option = 640x480-8@60;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
MODULE_AUTHOR((c) 2006 Ondrej Zajicek santi...@crfreenet.org);
MODULE_LICENSE(GPL);
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
MODULE_PARM_DESC(mode_option, Default video mode ('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0);
MODULE_PARM_DESC(mode, Default video mode e.g. '648x480-8@60' (deprecated));
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
/* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
info-fix.mmio_len = pci_resource_len(dev, 1);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -781,12 +771,9 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start
[PATCH v1 46/47] video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..f19133a 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
info-fix.smem_start = fb_phys;
info-fix.smem_len = pci_resource_len(pdev, 1);
- info-screen_base = pci_ioremap_bar(pdev, 1);
+ info-screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info-screen_base) {
dev_err(pdev-dev, gxt4500: cannot map framebuffer\n);
goto err_unmap_regs;
--
2.3.2.209.gd67f9d5.dirty
--
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: [RFC v1 2/2] x86: kconfig: remove UP [IO]APIC options
On Tue, Mar 10, 2015 at 05:58:27PM -0700, David Rientjes wrote: On Tue, 10 Mar 2015, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com These were here mostly to help as wrappers for PCI_MSI under certain UP 32-bit build scenarios, now that PCI_MSI properly selects what it needs and when it needs it these Kconfig options are now only enabling users reduce the size of 32-bit kernels optionally. Since 32-bit kernels are not in a huge state of flux and since there is no penalty for adding APIC support other than a bit of size moving forward we simply expect folks to enable APIC options on 32-bit systems when a system needs it, as with PCI_MSI. This lets us remove clutter from the x86 Kconfig file. Check out Linus's latest tree at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and see how it looks after commit 50849eefea3b (x86/Kconfig: Simplify X86_UP_APIC handling) and commit b1da1e715d4f (x86/Kconfig: Simplify X86_IO_APIC dependencies). OK thanks yeah I see that now, yeah this can be simplified further, will send a follow up based on top of these two. Luis -- 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 v1 0/2] x86: simplify UP APIC conditions
From: Luis R. Rodriguez mcg...@suse.com There is no need for UP APIC Kconfig entries given x86 is not in a state of flux for 32-bit and the options really don't have major impact on kernel size or performance. Things can also be expressed very clearly in a more simplified way, doing that also removes all the UP APIC kconfig clutter. Luis R. Rodriguez (2): x86: kconfig: remove X86_UP_IOAPIC x86: kconfig: remove X86_UP_APIC arch/x86/Kconfig| 30 ++ drivers/pci/Kconfig | 2 ++ 2 files changed, 4 insertions(+), 28 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- 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: [RFC v1 1/2] x86: kconfig: simplify enabling [IO]APIC for PCI_MSI
On Tue, Mar 10, 2015 at 05:49:10PM -0700, David Rientjes wrote: On Tue, 10 Mar 2015, Luis R. Rodriguez wrote: diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index 0d920d5..7306d2c 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -71,10 +71,7 @@ will simply fail and the device will continue to use pin-based interrupts. 4.1 Include kernel support for MSIs To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI -option enabled. This option is only available on some architectures, -and it may depend on some other options also being set. For example, -on x86, you must also enable X86_UP_APIC or SMP in order to see the -CONFIG_PCI_MSI option. +option enabled. This option is only available on some architectures. 4.2 Using MSI diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d038475..0ecdeb1 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -902,10 +902,6 @@ config X86_UP_APIC performance counters), and the NMI watchdog which detects hard lockups. -config X86_UP_APIC_MSI - def_bool y - select X86_UP_APIC if X86_32 !SMP !X86_32_NON_STANDARD PCI_MSI - config X86_UP_IOAPIC bool IO-APIC support on uniprocessors depends on X86_UP_APIC @@ -924,7 +920,7 @@ config X86_LOCAL_APIC select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ config X86_IO_APIC - def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC + def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC || PCI_MSI depends on X86_LOCAL_APIC select IRQ_DOMAIN diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 7a8f1c5..01370c0 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -5,6 +5,8 @@ config PCI_MSI bool Message Signaled Interrupts (MSI and MSI-X) depends on PCI select GENERIC_MSI_IRQ + select X86_LOCAL_APIC if X86_32 !SMP !X86_32_NON_STANDARD + select X86_IO_APIC if X86_32 !SMP !X86_32_NON_STANDARD help This allows device drivers to enable MSI (Message Signaled Interrupts). Message Signaled Interrupts enable a device to and I think I prefer the simplification done there over the additional selects for PCI_MSI. OK found a way to address that which makes it even easier to read. Luis -- 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 v1 2/2] x86: kconfig: remove X86_UP_APIC
From: Luis R. Rodriguez mcg...@suse.com X86_UP_APIC is used for two reasons on 32-bit systems: 1) set a series of dependencies under which we would like to express we want X86_LOCAL_APIC enabled 2) under the above conditions if PCI_MSI is enabled always force X86_LOCAL_APIC to be enabled 3) Let users opt in or out of X86_LOCAL_APIC if PCI_MSI is not enabled We don't really need a Kconfig entry to address 1) for 2) and 3) as X86_LOCAL_APIC already has the dependencies which we wish to match. Instead since 2) is desirable we can just select X86_LOCAL_APIC on PCI_MSI and it will be enabled when the dependencies are met. The only thing we loose with this then is letting users elect to enable or not X86_LOCAL_APIC on UP 32-bit systems but since: a) enabling X86_LOCAL_APIC will in no way slow down your kernel b) enabling X86_LOCAL_APIC only increases your kernel by 19264 bytes (19 KiB) c) x86 is not in a state of flux We can compromise here and just always enable X86_LOCAL_APIC when PCI_MSI is enabled. Using: (a hacked up patch to enable X86_LOCAL_APIC any time) export ARCH=i386 make allnoconfig -- Enabling or disabling X86_LOCAL_APIC make localyesconfig With X86_LOCAL_APIC: mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage 508496 arch/x86/boot/bzImage With X86_LOCAL_APIC: mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage 489232 arch/x86/boot/bzImage Cc: David Rientjes rient...@google.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Bryan O'Donoghue pure.lo...@nexus-software.ie Cc: Thomas Gleixner t...@linutronix.de Cc: Andy Shevchenko andy.shevche...@gmail.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Ingo Molnar mi...@kernel.org Cc: Borislav Petkov b...@suse.de Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Juergen Gross jgr...@suse.com Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/Kconfig| 17 + drivers/pci/Kconfig | 2 ++ 2 files changed, 3 insertions(+), 16 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b17a8ea..37d3e6e 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -895,24 +895,9 @@ config UP_LATE_INIT def_bool y depends on !SMP X86_LOCAL_APIC -config X86_UP_APIC - bool Local APIC support on uniprocessors if !PCI_MSI - default PCI_MSI - depends on X86_32 !SMP !X86_32_NON_STANDARD - select X86_IO_APIC - ---help--- - A local APIC (Advanced Programmable Interrupt Controller) is an - integrated interrupt controller in the CPU. If you have a single-CPU - system which has a processor with a local APIC, you can say Y here to - enable and use it. If you say Y here even though your machine doesn't - have a local APIC, then the kernel will still run with no slowdown at - all. The local APIC supports CPU-generated self-interrupts (timer, - performance counters), and the NMI watchdog which detects hard - lockups. - config X86_LOCAL_APIC def_bool y - depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI + depends on X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ config X86_IO_APIC diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 7a8f1c5..fa9739e 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -5,6 +5,8 @@ config PCI_MSI bool Message Signaled Interrupts (MSI and MSI-X) depends on PCI select GENERIC_MSI_IRQ + select X86_LOCAL_APIC + select X86_IO_APIC help This allows device drivers to enable MSI (Message Signaled Interrupts). Message Signaled Interrupts enable a device to -- 2.3.2.209.gd67f9d5.dirty -- 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 v1 1/2] x86: kconfig: remove X86_UP_IOAPIC
From: Luis R. Rodriguez mcg...@suse.com X86_UP_IOAPIC is a way so that 32-bit UP systems can enable X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if you are on a 32-bit system but have X86_UP_APIC enabled. X86_UP_APIC will be enabled by force if you have PCI_MSI on 32-bit systems now, X86_UP_APIC will now only be user selectable if you didn't have PCI_MSI enabled and are also not on a X86_32_NON_STANDARD system. Bryan's original patch (refactored commit log in commit 38a1dfda) [0] describes that Intel CE, Intel MID and Intel Quark are all 32-bit uniprocessor systems with IO-APICs, the code change however only *re-enabled* UP_IOAPIC as an *option* when PCI_MSI was enabled, but given that: 1) enabling X86_IOAPIC is the real end goal here 2) enabling X86_IOAPIC only increases the kernel only by 12064 bytes (~12 KiB) 3) enabling X86_IOAPIC will in no way slow down your kernel Let's make a compromise for 32-bit systems and always enable X86_IOAPIC when X86_UP_IOAPIC is enabled as 32-bit systems are not in a state of flux and the price for the size is small with no performance impact. Using: export ARCH=i386 make allnoconfig -- Enabling PCI_MSI make localyesconfig With X86_IO_APIC: mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage 734608 arch/x86/boot/bzImage Without X86_IO_APIC: mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage 722544 arch/x86/boot/bzImage [0] https://lkml.org/lkml/2015/1/22/718 Cc: David Rientjes rient...@google.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Bryan O'Donoghue pure.lo...@nexus-software.ie Cc: Thomas Gleixner t...@linutronix.de Cc: Andy Shevchenko andy.shevche...@gmail.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Ingo Molnar mi...@kernel.org Cc: Borislav Petkov b...@suse.de Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Juergen Gross jgr...@suse.com Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/Kconfig | 15 ++- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 110f6ae..b17a8ea 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -899,6 +899,7 @@ config X86_UP_APIC bool Local APIC support on uniprocessors if !PCI_MSI default PCI_MSI depends on X86_32 !SMP !X86_32_NON_STANDARD + select X86_IO_APIC ---help--- A local APIC (Advanced Programmable Interrupt Controller) is an integrated interrupt controller in the CPU. If you have a single-CPU @@ -909,18 +910,6 @@ config X86_UP_APIC performance counters), and the NMI watchdog which detects hard lockups. -config X86_UP_IOAPIC - bool IO-APIC support on uniprocessors - depends on X86_UP_APIC - ---help--- - An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an - SMP-capable replacement for PC-style interrupt controllers. Most - SMP systems and many recent uniprocessor systems have one. - - If you have a single-CPU system with an IO-APIC, you can say Y here - to use it. If you say Y here even though your machine doesn't have - an IO-APIC, then the kernel will still run with no slowdown at all. - config X86_LOCAL_APIC def_bool y depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI @@ -928,7 +917,7 @@ config X86_LOCAL_APIC config X86_IO_APIC def_bool y - depends on X86_LOCAL_APIC || X86_UP_IOAPIC + depends on X86_LOCAL_APIC select IRQ_DOMAIN config X86_REROUTE_FOR_BROKEN_BOOT_IRQS -- 2.3.2.209.gd67f9d5.dirty -- 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: [Xen-devel] kasan_map_early_shadow() on Xen
On Fri, Mar 06, 2015 at 11:02:50AM -0500, Konrad Rzeszutek Wilk wrote: On Wed, Mar 04, 2015 at 05:47:03PM -0800, Luis R. Rodriguez wrote: On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote: If it is like that - then just using what had to be implemented for the stack protection as a template ought to pave most of the work? Probably. I think I could make this work. However, I won't be able to work on this until the end of the next week. While a solution is likely possible here I'd like for us to notice how two features have gone now under our nose for Xen on v4.0 which have issues. Proactive maintainer reviews would detect these issues but we can't bet on these, and testing is just as reactive and slow. I'm Hmm, I see you saying 'Proactive maintainer review would detect' these but that assumes that the maintainer would even be copied on these patches? None of the Xen maintainers were copied on this. That is a damn shame. More on this below. And while we all strive to be pro-active I have to remind you maintainers are usually swamped. Right, I expected this, its why I in no way am saying its the roles which would cause this. hinting we keep our eyes out for an architectural solution that would avoid these issues. Don't ask me what that is just yet... Keep in mind that a lot of these issues get resolved during merge window thanks to the resiliancy of Boris monitoring these tests with an sharp eye! If this is about testing then its reactive. Its still great work but reactive is never better than a proactive engineering solution. After all that is what merge windows are - things break during them. Sure. What was highlighting, and now with a bit different emphasis, is the fragile nature of using different entry points for both PV Xen and bare metal x86_64 init, as well as other things involved with Xen which require careful surgery and analysis. I was alluding to the possibility of seeing if we can somehow draw up a solution to make it rather hard for these sorts of issues to creep up again and for Xen to reactively correct them, with what you point out that even the Xen maintainers were not copied on these patches it makes this a bit more of an important issue otherwise we're going to be in the same situation for v4.1, v4.2 and so on. If I had a technical solution to this problem I'd propose it but I don't, I'm just flagging it right now and hope we can come up with one. Luis -- 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 v1 1/2] x86: kconfig: remove X86_UP_IOAPIC
On Thu, Mar 12, 2015 at 01:19:14AM +, Bryan O'Donoghue wrote: On 11/03/15 23:10, Luis R. Rodriguez wrote: ACK the concept - the logic to compile up APIC support is circuitous to say the least. It took me a while to grok this and indeed the goal was to make it much simpler to read, but at the same time to see if we can reach a compromise to simplify it for 32-bit. Personally think we should just always compile up the APIC code if the arch declares support and let the bootstrap code interrogate CPUID. This would be the *next* level of compromise to make, I felt comfortable in raising the size compromise question for 32-bit but its not clear to me if this is a general question which we can address for all x86. There is indeed no performance pentalty for both so the question comes down to tex size increase, and its why I provided the numbers. My preference was to leave the optimization question for all x86 as a rather secondary question *iff* we can agree on something for 32-bit. Who in 2015 is really running a system without an APIC/IO-APIC and tip-of-tree Linux and does that one user care about adding 12k to her kernel ? I suspect not and in any case can force the APIC off with a command line argument I also figured this was the case, but figured it was safer to pose the question for 32-bit. If indeed folks who produce the hardware can conclude the size increase is reasonable for all platforms given no performance penalty then we can surely keep this even simpler -- I think its safer to ask this question for 32-bit and leave only the larger picture questoin as an evolutionairy question. @@ -899,6 +899,7 @@ config X86_UP_APIC bool Local APIC support on uniprocessors if !PCI_MSI Tried to apply this to torvalds-master to test :( Should it ? Which branch are you on here ? Applying: x86: kconfig: remove X86_UP_IOAPIC error: patch failed: arch/x86/Kconfig:899 error: arch/x86/Kconfig: patch does not apply Patch failed at 0001 x86: kconfig: remove X86_UP_IOAPIC linux-next tag next-20150311 Luis -- 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 v1 2/2] x86: kconfig: remove X86_UP_APIC
On Thu, Mar 12, 2015 at 02:42:01AM -0600, Jan Beulich wrote: On 12.03.15 at 00:10, mcg...@do-not-panic.com wrote: config X86_LOCAL_APIC def_bool y - depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI + depends on X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI I.e. building a 32-bit kernel with APIC support but with !SMP, !PCI_MSI, and !X86_32_NON_STANDARD will now be impossible. These are the requirements for X86_UP_APIC though. Surely not what the patch description says. The only removal I see here is the option to opt-in or out of X86_UP_APIC when PCI_MSI is *not* enabled provided you meet the requirements. --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -5,6 +5,8 @@ config PCI_MSI bool Message Signaled Interrupts (MSI and MSI-X) depends on PCI select GENERIC_MSI_IRQ + select X86_LOCAL_APIC + select X86_IO_APIC I don't see the need for the latter - MSI specifically works without any IO-APIC interaction. Although it can some MSI platforms need it as Bryan originally had expressed in his original patch [0] that Intel CE, Intel MID and Intel Quark are all 32-bit uniprocessor systems with IO-APICs that also use PCI-MSI, so this is not a hard requirement but rather compromising on enabling it since the the X86_IOAPIC cost is only ~12 KiB at with no performance penalty. https://lkml.org/lkml/2015/1/22/718 And for the former you should decide which way you want it - PCI_MSI select X86_LOCAL_APIC (probably the right thing in x86, but surely wrong everwhere else, i.e. this at least needs a condition tagged onto it) selects are done *iff* the dependencies are met, otherwise we can't select it, that's all, so the *iff* is implicit. or X86_LOCAL_APIC depend on PCI_MSI; in no case should this be a forward _and_ reverse dependency. There is no reverse requirement here because of the select. The trick here is the select implies the depends the value you are selecting has. mcgrof@ergon ~/linux-next (git::master)$ export ARCH=alpha mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig mcgrof@ergon ~/linux-next (git::master)$ make menuconfig -- System setup --- [*] Message Signaled Interrupts (MSI and MSI-X) mcgrof@ergon ~/linux-next (git::master)$ grep -i APIC .config mcgrof@ergon ~/linux-next (git::master)$ echo $? 1 Luis -- 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 v1 1/2] x86: kconfig: remove X86_UP_IOAPIC
On Wed, Mar 11, 2015 at 10:36:41PM -0700, David Rientjes wrote: On Wed, 11 Mar 2015, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com X86_UP_IOAPIC is a way so that 32-bit UP systems can enable X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if you are on a 32-bit system but have X86_UP_APIC enabled. X86_UP_APIC will be enabled by force if you have PCI_MSI on 32-bit systems now, X86_UP_APIC will now only be user selectable if you didn't have PCI_MSI enabled and are also not on a X86_32_NON_STANDARD system. Bryan's original patch (refactored commit log in commit 38a1dfda) [0] describes that Intel CE, Intel MID and Intel Quark are all 32-bit uniprocessor systems with IO-APICs, the code change however only *re-enabled* UP_IOAPIC as an *option* when PCI_MSI was enabled, but given that: 1) enabling X86_IOAPIC is the real end goal here 2) enabling X86_IOAPIC only increases the kernel only by 12064 bytes (~12 KiB) 3) enabling X86_IOAPIC will in no way slow down your kernel Let's make a compromise for 32-bit systems and always enable X86_IOAPIC when X86_UP_IOAPIC is enabled as 32-bit systems are not in a state of flux and the price for the size is small with no performance impact. Using: export ARCH=i386 make allnoconfig -- Enabling PCI_MSI make localyesconfig With X86_IO_APIC: mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage 734608 arch/x86/boot/bzImage Without X86_IO_APIC: mcgrof@ergon ~/linux-next (git::master)$ du -b arch/x86/boot/bzImage 722544 arch/x86/boot/bzImage 1.6% increase. Indeed, but we are talking about x86-32 bit and the question these two patches bring up is -- is the gains of the cleanup from the removal of these two worth the compromise? I think it is, but if there is active interest in keeping 32-bit x86 builds tiny I understand if this is not desirable. [0] https://lkml.org/lkml/2015/1/22/718 Cc: David Rientjes rient...@google.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Bryan O'Donoghue pure.lo...@nexus-software.ie Cc: Thomas Gleixner t...@linutronix.de Cc: Andy Shevchenko andy.shevche...@gmail.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Ingo Molnar mi...@kernel.org Cc: Borislav Petkov b...@suse.de Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Juergen Gross jgr...@suse.com Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/Kconfig | 15 ++- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 110f6ae..b17a8ea 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -899,6 +899,7 @@ config X86_UP_APIC bool Local APIC support on uniprocessors if !PCI_MSI default PCI_MSI depends on X86_32 !SMP !X86_32_NON_STANDARD + select X86_IO_APIC ---help--- A local APIC (Advanced Programmable Interrupt Controller) is an integrated interrupt controller in the CPU. If you have a single-CPU @@ -909,18 +910,6 @@ config X86_UP_APIC performance counters), and the NMI watchdog which detects hard lockups. -config X86_UP_IOAPIC - bool IO-APIC support on uniprocessors - depends on X86_UP_APIC - ---help--- - An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an - SMP-capable replacement for PC-style interrupt controllers. Most - SMP systems and many recent uniprocessor systems have one. - - If you have a single-CPU system with an IO-APIC, you can say Y here - to use it. If you say Y here even though your machine doesn't have - an IO-APIC, then the kernel will still run with no slowdown at all. - config X86_LOCAL_APIC def_bool y depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI @@ -928,7 +917,7 @@ config X86_LOCAL_APIC config X86_IO_APIC def_bool y - depends on X86_LOCAL_APIC || X86_UP_IOAPIC + depends on X86_LOCAL_APIC select IRQ_DOMAIN config X86_REROUTE_FOR_BROKEN_BOOT_IRQS I think it would be best to remove the select so the depends for both config options won't diverge in the future. This should be equivalent, right? Do you mean remove the select IRQ_DOMAIN ? If so the select does not imply depends though, it simply will peg it on if its own dependencies are met. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -909,18 +909,6 @@ config X86_UP_APIC performance counters), and the NMI watchdog which detects hard lockups. -config X86_UP_IOAPIC - bool IO-APIC support on uniprocessors - depends on X86_UP_APIC - ---help--- - An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an - SMP-capable replacement for PC-style interrupt
[RFC v1 0/2] x86: kconfig: simplify APIC entries
From: Luis R. Rodriguez mcg...@suse.com There's quite a bit of Kconfig entries related to X86_LOCAL_APIC and X86_IO_APIC, and all for 32-bit purposes. Since 32-bit isn't in a magical state of flux we now *should* know when to enable or disable APIC stuff for these systems. Through history we've observed for instance PCI_MSI requires these under specific scenarios, just enable it for those learned scenarios and expect future requirements to also be explicit about the requirements on 32-bit. This lets us remove clutter (3 Kconfig entries) from x86 Kconfig simply for 32-bit build purposes. Luis R. Rodriguez (2): x86: kconfig: simplify enabling [IO]APIC for PCI_MSI x86: kconfig: remove UP [IO]APIC options Documentation/PCI/MSI-HOWTO.txt | 5 + arch/x86/Kconfig| 33 ++--- drivers/pci/Kconfig | 2 ++ 3 files changed, 5 insertions(+), 35 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- 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/
[RFC v1 1/2] x86: kconfig: simplify enabling [IO]APIC for PCI_MSI
From: Luis R. Rodriguez mcg...@suse.com Commit 38a1dfda by Bryan O'Donoghue fixed a build issue when PCI_MSI support is enabled on non-SMP X86_32 systems, this was done by introducing a new Kconfig entry, X86_UP_APIC_MSI, with the only purpose of selecting X86_UP_APIC under certain conditions. The real goal in the end though is to enable X86_LOCAL_APIC and X86_IO_APIC. We already have enough APIC related Kconfig entries and adding more only confuses things, we can remove X86_UP_APIC_MSI by just passing on to PCI_MSI what it needs. Cc: Bjorn Helgaas bhelg...@google.com Cc: Bryan O'Donoghue pure.lo...@nexus-software.ie Cc: Thomas Gleixner t...@linutronix.de Cc: Andy Shevchenko andy.shevche...@gmail.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Ingo Molnar mi...@kernel.org Cc: Borislav Petkov b...@suse.de Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Juergen Gross jgr...@suse.com Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- Documentation/PCI/MSI-HOWTO.txt | 5 + arch/x86/Kconfig| 6 +- drivers/pci/Kconfig | 2 ++ 3 files changed, 4 insertions(+), 9 deletions(-) diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index 0d920d5..7306d2c 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -71,10 +71,7 @@ will simply fail and the device will continue to use pin-based interrupts. 4.1 Include kernel support for MSIs To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI -option enabled. This option is only available on some architectures, -and it may depend on some other options also being set. For example, -on x86, you must also enable X86_UP_APIC or SMP in order to see the -CONFIG_PCI_MSI option. +option enabled. This option is only available on some architectures. 4.2 Using MSI diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d038475..0ecdeb1 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -902,10 +902,6 @@ config X86_UP_APIC performance counters), and the NMI watchdog which detects hard lockups. -config X86_UP_APIC_MSI - def_bool y - select X86_UP_APIC if X86_32 !SMP !X86_32_NON_STANDARD PCI_MSI - config X86_UP_IOAPIC bool IO-APIC support on uniprocessors depends on X86_UP_APIC @@ -924,7 +920,7 @@ config X86_LOCAL_APIC select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ config X86_IO_APIC - def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC + def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC || PCI_MSI depends on X86_LOCAL_APIC select IRQ_DOMAIN diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 7a8f1c5..01370c0 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -5,6 +5,8 @@ config PCI_MSI bool Message Signaled Interrupts (MSI and MSI-X) depends on PCI select GENERIC_MSI_IRQ + select X86_LOCAL_APIC if X86_32 !SMP !X86_32_NON_STANDARD + select X86_IO_APIC if X86_32 !SMP !X86_32_NON_STANDARD help This allows device drivers to enable MSI (Message Signaled Interrupts). Message Signaled Interrupts enable a device to -- 2.3.2.209.gd67f9d5.dirty -- 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/
[RFC v1 2/2] x86: kconfig: remove UP [IO]APIC options
From: Luis R. Rodriguez mcg...@suse.com These were here mostly to help as wrappers for PCI_MSI under certain UP 32-bit build scenarios, now that PCI_MSI properly selects what it needs and when it needs it these Kconfig options are now only enabling users reduce the size of 32-bit kernels optionally. Since 32-bit kernels are not in a huge state of flux and since there is no penalty for adding APIC support other than a bit of size moving forward we simply expect folks to enable APIC options on 32-bit systems when a system needs it, as with PCI_MSI. This lets us remove clutter from the x86 Kconfig file. Cc: Bjorn Helgaas bhelg...@google.com Cc: Bryan O'Donoghue pure.lo...@nexus-software.ie Cc: Thomas Gleixner t...@linutronix.de Cc: Andy Shevchenko andy.shevche...@gmail.com Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com Cc: Ingo Molnar mi...@kernel.org Cc: Borislav Petkov b...@suse.de Cc: H. Peter Anvin h...@zytor.com Cc: Jan Beulich jbeul...@suse.com Cc: Juergen Gross jgr...@suse.com Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- arch/x86/Kconfig | 29 ++--- 1 file changed, 2 insertions(+), 27 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0ecdeb1..bfd4d66 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -889,38 +889,13 @@ config UP_LATE_INIT def_bool y depends on !SMP X86_LOCAL_APIC -config X86_UP_APIC - bool Local APIC support on uniprocessors - depends on X86_32 !SMP !X86_32_NON_STANDARD - ---help--- - A local APIC (Advanced Programmable Interrupt Controller) is an - integrated interrupt controller in the CPU. If you have a single-CPU - system which has a processor with a local APIC, you can say Y here to - enable and use it. If you say Y here even though your machine doesn't - have a local APIC, then the kernel will still run with no slowdown at - all. The local APIC supports CPU-generated self-interrupts (timer, - performance counters), and the NMI watchdog which detects hard - lockups. - -config X86_UP_IOAPIC - bool IO-APIC support on uniprocessors - depends on X86_UP_APIC - ---help--- - An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an - SMP-capable replacement for PC-style interrupt controllers. Most - SMP systems and many recent uniprocessor systems have one. - - If you have a single-CPU system with an IO-APIC, you can say Y here - to use it. If you say Y here even though your machine doesn't have - an IO-APIC, then the kernel will still run with no slowdown at all. - config X86_LOCAL_APIC def_bool y - depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || PCI_MSI + depends on X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ config X86_IO_APIC - def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC || PCI_MSI + def_bool X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI depends on X86_LOCAL_APIC select IRQ_DOMAIN -- 2.3.2.209.gd67f9d5.dirty -- 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 v1 03/47] devres: add devm_ioremap_wc()
On Fri, Mar 20, 2015 at 04:49:51PM -0700, Andy Lutomirski wrote: On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com We have devm_ioremap_nocache() but no devm_ioremap_wc() so add that. This will be used later. Cc: Suresh Siddha suresh.b.sid...@intel.com Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com Cc: Ingo Molnar mi...@elte.hu Cc: Thomas Gleixner t...@linutronix.de Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com Looks good to me. Thanks, I'll peg a Reviewed-by. Luis -- 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: [Xen-devel] [PATCH v1 04/47] pci: add pci_ioremap_wc_bar()
On Wed, Mar 25, 2015 at 04:03:46PM -0400, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 20, 2015 at 04:17:54PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
s/advanate/advantage/
Amended.
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e)
Please mention the title of the patch too:
x86 PAT: fix performance drop for glx, use UC minus for ioremap(),
ioremap_nocache() and pci_mmap_page_range()
Added.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 81f06e8..6afd507 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -137,6 +137,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev,
int bar)
pci_resource_len(pdev, bar));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) IORESOURCE_MEM)) {
+ WARN_ON(1);
Would it be better to use dev_warn ? That way you can see which BDF it is?
Thought WARN will give a nice stack-trace that should easily point to the
driver so perhaps not.. Either way - up to you.
I'm sticking to the style and use as with pci_ioremap_bar(). Whatever we pick
we should make both use the same. More information is always better and
since we do have dev_warn(), it would be nice to use that however within
its use on both pci_ioremap_wc_bar() and pci_ioremap_bar() we have
a use of the pdev with pci_resource_flags() and I believe if pdev is NULL
we'd get a NULL dereference (dev_driver_string() is used), so it would
seem it might be best to stick with a simple WARN_ON(). Arjan, any
preference? Obviously if pdev is NULL your driver is dumb but as folks
develop drivers this should be expected.
Luis
--
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 v1 04/47] pci: add pci_ioremap_wc_bar()
On Fri, Mar 20, 2015 at 04:50:32PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e)
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 81f06e8..6afd507 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -137,6 +137,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev,
int bar)
pci_resource_len(pdev, bar));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO
resource
+*/
+ if (!(pci_resource_flags(pdev, bar) IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
if (WARN_ON(...))?
Sure, they are equivalent however this follows the same exact style as
pci_ioremap_bar() so if we change this one might as well change the style of
pci_ioremap_bar() as well. Let me know if there is any preference. I personally
don't mind the extra line as it shortens the check.
Luis
--
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: [Xen-devel] [PATCH] x86/xen: Initialize cr4 shadow for 64-bit PV(H) guests
On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel david.vra...@citrix.com wrote: On 23/02/15 16:01, Boris Ostrovsky wrote: Commit 1e02ce4cccdc (x86: Store a per-cpu shadow copy of CR4) introduced CR4 shadows. These shadows are initialized in early boot code. The commit missed initialization for 64-bit PV(H) guests that this patch adds. Applied to stable/for-linus-4.0, thanks. Boris, can you kick of a set of tests on this branch, please? Do we know worst case what should blow up without this commit ? Luis -- 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: [Xen-devel] kasan_map_early_shadow() on Xen
On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel david.vra...@citrix.com wrote:
On 03/03/15 09:40, Luis R. Rodriguez wrote:
Andrey,
I believe that on Xen we should disable kasan, would like confirmation
Why? This is the first of heard of this.
Andrey chimed in here confirming this.
from someone on xen-devel though. Here's the thing though -- if true
-- I'd like to do it *properly*, where *properly* means addressing a
bit of architecture. A simple Kconfig slap seems rather reactive. I'd
like to address a way to properly ensure we don't run into this and
other similar issues in the future. The CR4 shadow issue was another
recent example issue, also introduced via v4.0 [0]. We can't keep
doing this reactively.
Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be
selected on x86 when:
if X86_64 SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable
Why? Again, this is the first I've heard of this as well. FWIW, all
the Xen configs we use have SPARSEMEM_VMEMMAP enabled.
Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at
SUSE. Figured this was a generic issue. The SUSE kernels are based on
3.12 though, but anyway with it enabled I do get compile failures
because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen
set to 43 for some reason (can't find that justification), so it
doesn't use the default 46 that would be used otherwise. But another
reason seems to be the lack of forward porting yet PAT support for PV
domains -- commit 47591df50 upstream which requires us to still have
the union on the pte_t, and I suppose we need ca15f20f as well...
If there is nothing else I suppose this just requires fixing up at
SUSE's end for SPARSEMEM_VMEMMAP...
--- ./arch/x86/include/asm/pgtable_64_types.h 2015-03-02
13:35:49.885257763 -0800
+++ ./arch/x86/include/mach-xen/asm/pgtable_64_types.h 2015-03-02
13:36:25.554259348 -0800
@@ -15,7 +15,7 @@
typedef unsigned long pgdval_t;
typedef unsigned long pgprotval_t;
-typedef struct { pteval_t pte; } pte_t;
+typedef union { pteval_t pte; unsigned int pte_low; } pte_t;
#endif /* !__ASSEMBLY__ */
@@ -54,6 +54,7 @@
#define PGDIR_MASK (~(PGDIR_SIZE - 1))
/* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
+#define MAX_PHYSMEM_BITS 43
#define MAXMEM _AC(__AC(1, UL) MAX_PHYSMEM_BITS, UL)
#define VMALLOC_START_AC(0xc900, UL)
#define VMALLOC_END _AC(0xe8ff, UL)
Luis
--
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: [Xen-devel] [PATCH] x86/xen: Initialize cr4 shadow for 64-bit PV(H) guests
On Tue, Mar 03, 2015 at 09:27:34AM -0500, Boris Ostrovsky wrote: On 03/03/2015 12:35 AM, Luis R. Rodriguez wrote: On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel david.vra...@citrix.com wrote: On 23/02/15 16:01, Boris Ostrovsky wrote: Commit 1e02ce4cccdc (x86: Store a per-cpu shadow copy of CR4) introduced CR4 shadows. These shadows are initialized in early boot code. The commit missed initialization for 64-bit PV(H) guests that this patch adds. Applied to stable/for-linus-4.0, thanks. Boris, can you kick of a set of tests on this branch, please? Do we know worst case what should blow up without this commit ? PVH guest will crash. Oh wow that is serious. And this is a reactive measure to a change upstream, it might be hard but it'd be nice if we can have a proactive architecture to address this. Don't mind me though, I realize this seems hard, just thinking out loud right now. Did you find it through code inspection or a test? Luis -- 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/
[RFC v1 4/4] x86: mm: use early_param_on_off() for direct_gbpages
From: Luis R. Rodriguez mcg...@suse.com
The enabler / disabler is pretty simple, just use the
provided wrappers, this lets us easily relate the variable
to the associated Kconfig entry.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Toshi Kani toshi.k...@hp.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Xishi Qiu qiuxi...@huawei.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: David Vrabel david.vra...@citrix.com
Cc: Borislav Petkov b...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Dexuan Cui de...@microsoft.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/mm/init.c| 3 ++-
arch/x86/mm/init_64.c | 14 --
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 8d375ba..ce5db80 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -133,7 +133,8 @@ int after_bootmem;
static int page_size_mask;
-int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
+early_param_on_off(gbpages, nogbpages,
+ direct_gbpages, CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 30eb05a..3fba623 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -130,20 +130,6 @@ int kernel_ident_mapping_init(struct x86_mapping_info
*info, pgd_t *pgd_page,
return 0;
}
-static int __init parse_direct_gbpages_off(char *arg)
-{
- direct_gbpages = 0;
- return 0;
-}
-early_param(nogbpages, parse_direct_gbpages_off);
-
-static int __init parse_direct_gbpages_on(char *arg)
-{
- direct_gbpages = 1;
- return 0;
-}
-early_param(gbpages, parse_direct_gbpages_on);
-
/*
* NOTE: pagetable_init alloc all the fixmap pagetables contiguous on the
* physical space so we can cache the place of the first one and move
--
2.2.2
--
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: [Xen-devel] kasan_map_early_shadow() on Xen
On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote: If it is like that - then just using what had to be implemented for the stack protection as a template ought to pave most of the work? Probably. I think I could make this work. However, I won't be able to work on this until the end of the next week. While a solution is likely possible here I'd like for us to notice how two features have gone now under our nose for Xen on v4.0 which have issues. Proactive maintainer reviews would detect these issues but we can't bet on these, and testing is just as reactive and slow. I'm hinting we keep our eyes out for an architectural solution that would avoid these issues. Don't ask me what that is just yet... Luis -- 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/
[RFC v1 1/4] x86: mm: use IS_ENABLED() for direct_gbpages
From: Luis R. Rodriguez mcg...@suse.com
Replace #ifdef eyesore with IS_ENABLED() use.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Toshi Kani toshi.k...@hp.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Xishi Qiu qiuxi...@huawei.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: David Vrabel david.vra...@citrix.com
Cc: Borislav Petkov b...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Dexuan Cui de...@microsoft.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/mm/init.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 52417e7..b880d06 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -131,11 +131,7 @@ void __init early_alloc_pgt_buf(void)
int after_bootmem;
-int direct_gbpages
-#ifdef CONFIG_DIRECT_GBPAGES
- = 1
-#endif
-;
+int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
--
2.2.2
--
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/
[RFC v1 0/4] x86: simpify direct_gbpages setting, add early_param_on_off()
From: Luis R. Rodriguez mcg...@suse.com While reviewing DIRECT_GBPAGES I noticed some inconsistancies on when its cached enable variable is set and when in reality its full feature is enabled. There's also some code simplification possible by simply using Kconfig, so decided to take advantage of that and then generalize this a bit under a new early_param_on_off() which makes it easier to associate featureas with respective cached values and their own feature related Kconfig entries. In this case in order to use early_param_on_off() given that init.o is shared with both 32-bit and 64-bit and before the early parameters were only exposed on 64-bit it does mean we're exposing this kernel parameter to 32-bit as well now but its not possible to enable it on 32-bit as its real setting is guarded by ENABLE_DIRECT_GBPAGES. I was tempted to grep around for this sort of grammar use but couldn't easily find all uses with Coccinelle / grep due to the #ifder'y and the code being outside of routines. If the generalization is not desired we can drop the last two, but would ask that the first two patches to be considered and reviewed. Luis R. Rodriguez (4): x86: mm: use IS_ENABLED() for direct_gbpages x86: mm: simplify enabling direct_gbpages init.h: add early_param_on_off() x86: mm: use early_param_on_off() for direct_gbpages arch/x86/Kconfig | 18 +- arch/x86/mm/init.c | 24 +++- arch/x86/mm/init_64.c | 14 -- arch/x86/mm/pageattr.c | 2 -- include/linux/init.h | 15 +++ 5 files changed, 39 insertions(+), 34 deletions(-) -- 2.2.2 -- 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/
[RFC v1 2/4] x86: mm: simplify enabling direct_gbpages
From: Luis R. Rodriguez mcg...@suse.com
direct_gbpages can be force enabled as an early parameter
but not really have taken effect when DEBUG_PAGEALLOC
or KMEMCHECK is enabled. You can also enable direct_gbpages
right now if you have an x86_64 architecture but your CPU
doesn't really have support for this feature. In both cases
PG_LEVEL_1G won't actually be enabled but direct_gbpages is used
in other areas under the assumptions that PG_LEVEL_1G
was set. Fix this by putting together all requirements
which make this feature sensible to enable under, and only
enable both finally flipping on PG_LEVEL_1G and leaving
PG_LEVEL_1G set when this is true.
We only enable this feature then to be possible on sensible
builds defined by the new ENABLE_DIRECT_GBPAGES. If the
CPU has support for it you can either enable this by using
the DIRECT_GBPAGES option or using the early kernel parameter.
If a platform had support for this you can always force disable
it as well.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Toshi Kani toshi.k...@hp.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Xishi Qiu qiuxi...@huawei.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: David Vrabel david.vra...@citrix.com
Cc: Borislav Petkov b...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Dexuan Cui de...@microsoft.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/x86/Kconfig | 18 +-
arch/x86/mm/init.c | 17 +
arch/x86/mm/pageattr.c | 2 --
3 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fb8e8cd..f3fd260 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1300,14 +1300,22 @@ config ARCH_DMA_ADDR_T_64BIT
def_bool y
depends on X86_64 || HIGHMEM64G
+config ENABLE_DIRECT_GBPAGES
+ def_bool y
+ depends on X86_64 !DEBUG_PAGEALLOC !KMEMCHECK
+
config DIRECT_GBPAGES
bool Enable 1GB pages for kernel pagetables if EXPERT
default y
- depends on X86_64
- ---help---
- Allow the kernel linear mapping to use 1GB pages on CPUs that
- support it. This can improve the kernel's performance a tiny bit by
- reducing TLB pressure. If in doubt, say Y.
+ depends on ENABLE_DIRECT_GBPAGES
+ ---help---
+ Enable by default the kernel linear mapping to use 1GB pages on CPUs
+ that support it. This can improve the kernel's performance a tiny bit
+ by reducing TLB pressure. If in doubt, say Y. If you've disabled
+ option but your platform is capable of handling support for this
+ you can use the gbpages kernel parameter. Likewise if you've enabled
+ this but you'd like to force disable this option you can use the
+ nogbpages kernel parameter.
# Common NUMA Features
config NUMA
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index b880d06..8d375ba 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -131,16 +131,21 @@ void __init early_alloc_pgt_buf(void)
int after_bootmem;
+static int page_size_mask;
+
int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
-#ifdef CONFIG_X86_64
- if (direct_gbpages cpu_has_gbpages)
+ if (!IS_ENABLED(CONFIG_ENABLE_DIRECT_GBPAGES)) {
+ direct_gbpages = 0;
+ return;
+ }
+ if (direct_gbpages cpu_has_gbpages) {
printk(KERN_INFO Using GB pages for direct mapping\n);
- else
+ page_size_mask |= 1 PG_LEVEL_1G;
+ } else
direct_gbpages = 0;
-#endif
}
struct map_range {
@@ -149,8 +154,6 @@ struct map_range {
unsigned page_size_mask;
};
-static int page_size_mask;
-
static void __init probe_page_size_mask(void)
{
init_gbpages();
@@ -161,8 +164,6 @@ static void __init probe_page_size_mask(void)
* This will simplify cpa(), which otherwise needs to support splitting
* large pages into small in interrupt context, etc.
*/
- if (direct_gbpages)
- page_size_mask |= 1 PG_LEVEL_1G;
if (cpu_has_pse)
page_size_mask |= 1 PG_LEVEL_2M;
#endif
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 536ea2f..070b7c2 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -81,11 +81,9 @@ void arch_report_meminfo(struct seq_file *m)
seq_printf(m, DirectMap4M:%8lu kB\n,
direct_pages_count[PG_LEVEL_2M] 12);
#endif
-#ifdef CONFIG_X86_64
if (direct_gbpages
[RFC v1 3/4] init.h: add early_param_on_off()
From: Luis R. Rodriguez mcg...@suse.com
At times all you need is a kconfig variable to enable a feature,
by default but you may want to also enable / disable it through
a kernel parameter. In such cases the parameter routines to turn
the thing on / off are really simple. Just use a wrapper for
this, it lets us generalize the code and makes it easier to
associate parameters with related kernel configuration options.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Juergen Gross jgr...@suse.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Toshi Kani toshi.k...@hp.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Xishi Qiu qiuxi...@huawei.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: David Vrabel david.vra...@citrix.com
Cc: Borislav Petkov b...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Dexuan Cui de...@microsoft.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
include/linux/init.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/init.h b/include/linux/init.h
index 2df8e8d..bc11ff9 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -268,6 +268,21 @@ struct obs_kernel_param {
#define early_param(str, fn) \
__setup_param(str, fn, fn, 1)
+#define early_param_on_off(str_on, str_off, var, config)
\
+ int var = IS_ENABLED(config); \
+ static int __init parse_##var##_on(char *arg) \
+ { \
+ var = 1;\
+ return 0; \
+ } \
+ static int __init parse_##var##_off(char *arg) \
+ { \
+ var = 0;\
+ return 0; \
+ } \
+ __setup_param(str_on, parse_##var##_on, parse_##var##_on, 1); \
+ __setup_param(str_off, parse_##var##_off, parse_##var##_off, 1)
+
/* Relies on boot_command_line being set */
void __init parse_early_param(void);
void __init parse_early_options(char *cmdline);
--
2.2.2
--
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/
kasan_map_early_shadow() on Xen
Andrey, I believe that on Xen we should disable kasan, would like confirmation from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the future. The CR4 shadow issue was another recent example issue, also introduced via v4.0 [0]. We can't keep doing this reactively. Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be selected on x86 when: if X86_64 SPARSEMEM_VMEMMAP Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable distributions to be able to have a single binary kernels and let the rest be figured out, so we can't just disable SPARSEMEM_VMEMMAP for Xen alone, we want to build Xen.. or part of Xen and perhaps keep SPARSEMEM_VMEMMAP, and only later figure things out. How do we do this cleanly and avoid future reactive measures? If the answer is not upon us, I'd like to at least highlight the issue so that in case we do come up with something its no surprise PVOPs is falling short for that single binary pipe dream right now. [0] https://lkml.org/lkml/2015/2/23/328 Luis -- 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: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig
On Wed, Feb 25, 2015 at 12:49 PM, David Rientjes rient...@google.com wrote: Woohoo, so does this mean that Luis's series will finally be merged into a tree somewhere? It's been a lengthy wait to try to get this merged. David Rientjes (as I'm also Cc'ing David Vrabel), I am reworking Xen's kconfig stuff right now, so perhaps what is best is for this series to be folded under those changes and I'd submit them as the last series in the changes. That would avoid collateral changes as I revamp tons of Xen kconfig things. This would then go under David Vrabel's tree, but since it involves x86 stuff its unclear if its OK for that -- I think so? Let me know. Luis -- 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: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig
On Wed, Feb 25, 2015 at 1:19 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 25, 2015 at 01:11:04PM -0800, David Rientjes wrote: On Wed, 25 Feb 2015, Luis R. Rodriguez wrote: I am reworking Xen's kconfig stuff right now, so perhaps what is best is for this series to be folded under those changes and I'd submit them as the last series in the changes. That would avoid collateral changes as I revamp tons of Xen kconfig things. This would then go under David Vrabel's tree, but since it involves x86 stuff its unclear if its OK for that -- I think so? Let me know. Ok, sounds good, and I agree it would be better to hold off on doing this if there are going to be substantial changes to the config options later. I think once the x86 bits get an ack from one of the x86 guys that you should be good to go! Ingo (x86 guys) mentioned in one of his emails that he glosses over emails if they say 'xen'. Then this should be able to go through David Vrabel no, as he does care. Perhaps you need to change the title to be more catchy? If folks don't want to deal with Xen patches it should be fine, but we do need a route upstream, this seems to make sense to go through David Vrabel in the future no? Luis -- 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 v4 1/2] cfg80211: Add API to change the indoor regulatory setting
On Fri, Feb 20, 2015 at 7:02 AM, Jonathan Bither jonbit...@gmail.com wrote: On 02/19/2015 08:03 PM, valdis.kletni...@vt.edu wrote: On Fri, 20 Feb 2015 01:53:44 +0100, Luis R. Rodriguez said: Wider community: anyone aware of any *need* in the kernel to know whether one is indoor or not on a device running Linux other than wifi? Clearly it should be something that might be of interest to at least other RF devices, so that is at least one possibilty to consider already, but what else? I can think of a lot of reasons for the kernel to make indoor/outdoor status available to userspace, but am coming up empty why the kernel itself should care That made me try to think of the possible uses for such a variable but I imagine that they can all be handled by userspace as well. Powering down GPS chips for energy consumption. Applying filters to cameras for fluorescent lights. These days such devices are bundled with all these devices typically aiming towards single-chip, ie one devices with multiple functions and sharing as much as possible, as such it should be possible architecturally to share this. So far then it seems this can just live under its hood under cfg80211 then. Luis -- 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 v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote: On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Ideally on systems using PAT we can expect a swift transition away from MTRR. There can be a few exceptions to this, one is where device drivers are known to exist on PATs with errata, another situation is observed on old device drivers where devices had combined MMIO register access with whatever area they typically later wanted to end up using MTRR for on the same PCI BAR. This situation can still be addressed by splitting up ioremap'd PCI BAR into two ioremap'd calls, one for MMIO registers, and another for whatever is desirable for write-combining -- in order to accomplish this though quite a bit of driver restructuring is required. Device drivers which are known to require large amount of re-work in order to split ioremap'd areas can use __arch_phys_wc_add() to avoid regressions when PAT is enabled. For a good example driver where things are neatly split up on a PCI BAR refer the infiniband qib driver. For a good example of a driver where good amount of work is required refer to the infiniband ipath driver. This is *only* a transitive API -- and as such no new drivers are ever expected to use this. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? Yes, I cc'd you just now on one where I made changes on a driver which uses one PCI with mixed memtypes and uses MTRR to hole in WC. A transition to arch_phys_wc_add() is therefore not possible if PAT is enabled as it would regress those drivers by making the MTRR WC hole trick non functional. The changes are non trivial and so in this series I supplied changes on one driver only to show the effort required. The other drivers which required this were: Driver File fusion drivers/message/fusion/mptbase.c ivtvdrivers/media/pci/ivtv/ivtvfb.c ipath drivers/infiniband/hw/ipath/ipath_driver.c This series makes those drivers use __arch_phys_wc_add() more as a transitory phase in hopes we can address the proper split as with the atyfb illustrates. For ipath the changes required have a nice template with the qib driver as they share very similar driver structure, the qib driver *did* do the nice split. If so, can we ioremap + set_page_xyz instead? I'm not sure I see which call we'd use. Care to provide an example patch alternative for the atyfb as a case in point alternative to the work required to do the split? I'm still confused. Would it be insufficient to ioremap_nocache the whole thing and then call set_memory_wc on parts of it? (Sorry, set_page_xyz was a typo.) I think that would be a sexy alternative. In this driver's case the thing is a bit messy as it not only used the WC MTRR for a hole but it also then used a UC MTRR on top of it all, so since I already tried to address the split, and if we address the power of 2 woes, I think it'd be best to try to remove the UC MTRR and just avoid set_page_wc() in this driver's case, but for the other cases (fusion, ivtv, ipath) I think this makes sense. Thoughts? Luis -- 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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
As per mtrr_add_page() [0] the base and size are just supposed to be in units
of 4 KiB, although the practice is to use powers of 2 in *some* drivers this
is not standardized and by no means recorded as a requirement. Obviously
powers of 2 will work too and you'd end up neatly aligned as well. mtrr_add()
will use mtrr_check() to verify the the same requirement. Furthermore,
as per my commit log message:
---
The last thing we do must do to remain sane is ensure we
use the info-fix.smem_start and info-fix.smem_len for
the framebuffer MTRR as we know that is always well adjusted.
The *one* concern here would be if the MTRR is not in units
of 4K __but__ we already know that in the PCI case this cannot
happen, in the shared space setting the MTRR would be up to
0x7ff000 and assuming a 4K page:
; 0x7ff000 / 0x1000
2047
Also, internally when MTRR is used mtrr_add() will use mtrr_check()
and that should splat a warning when the MTRR base and size are
not compatible with what is expected for MTRR usage.
---
If any of this is too risky we can use the __arch_phys_wc_add() (or as
Andy suggested perhaps use set_page_* stuff, although I am still evaluating
this) but I did this change to show the effort required for a change when
the registers / framebuffer is on the same PCI BAR but at different offsets.
[0] scripts/kernel-doc -man -function mtrr_add_page
arch/x86/kernel/cpu/mtrr/main.c | nroff -man | less
Luis
--
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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
As per mtrr_add_page() [0] the base and size are just supposed to be in
units
of 4 KiB, although the practice is to use powers of 2 in *some* drivers this
is not standardized and by no means recorded as a requirement. Obviously
powers of 2 will work too and you'd end up neatly aligned as well.
mtrr_add()
will use mtrr_check() to verify the the same requirement. Furthermore,
as per my commit log message:
Whatever the code may or may not do, the x86 architecture uses
power-of-two MTRR sizes. So I'm confused.
There should be no confusion, I simply did not know that *was* the
requirement for x86, if that is the case we should add a check for that
and perhaps generalize a helper that does the power of two helper changes,
the cleanest I found was the vesafb driver solution.
Thoughts?
Luis
--
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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 20, 2015 at 04:52:18PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr_aper = 0 !par-aux_start) {
- /* Make a hole for mmio. */
- par-mtrr_reg = mtrr_add(par-res_start + 0x80 -
-GUI_RESERVE, GUI_RESERVE,
-MTRR_TYPE_UNCACHABLE, 1);
- if (par-mtrr_reg 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
- }
}
#endif
@@ -2776,10 +2765,6 @@ aty_init_exit:
par-pll_ops-set_pll(info, par-saved_pll);
#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
if (par-mtrr_aper = 0) {
mtrr_del(par-mtrr_aper, 0, 0);
par-mtrr_aper = -1;
@@ -3466,7 +3451,7 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
}
info-fix.mmio_start = raddr;
- par-ati_regbase = ioremap(info-fix.mmio_start, 0x1000);
+ par-ati_regbase = ioremap_nocache(info-fix.mmio_start, 0x1000);
Double-check me, but I think that ioremap_nocache + WC MTRR = WC.
Precicely, in this case the WC hole was obtained by using MTRR WC. This
patch removes that WC hole trick and now we can be explciit about
only wanting ioremap_nocache() on the registers, that is WC is not
desired here and is not used. The patch does not highlight the fact
that there was left in place another ioremap() call for the framebuffer:
info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len);
That is the one that later after this patch we use ioremap_wc() for.
This patch just removes the hole solution. That's all.
Luis
--
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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 27, 2015 at 10:37:04AM +0200, Ville Syrjälä wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
Still waiting for an answer...
Sorry was in the desert for a bit, I'm back now.
Luis
--
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 v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Ideally on systems using PAT we can expect a swift transition away from MTRR. There can be a few exceptions to this, one is where device drivers are known to exist on PATs with errata, another situation is observed on old device drivers where devices had combined MMIO register access with whatever area they typically later wanted to end up using MTRR for on the same PCI BAR. This situation can still be addressed by splitting up ioremap'd PCI BAR into two ioremap'd calls, one for MMIO registers, and another for whatever is desirable for write-combining -- in order to accomplish this though quite a bit of driver restructuring is required. Device drivers which are known to require large amount of re-work in order to split ioremap'd areas can use __arch_phys_wc_add() to avoid regressions when PAT is enabled. For a good example driver where things are neatly split up on a PCI BAR refer the infiniband qib driver. For a good example of a driver where good amount of work is required refer to the infiniband ipath driver. This is *only* a transitive API -- and as such no new drivers are ever expected to use this. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? Yes, I cc'd you just now on one where I made changes on a driver which uses one PCI with mixed memtypes and uses MTRR to hole in WC. A transition to arch_phys_wc_add() is therefore not possible if PAT is enabled as it would regress those drivers by making the MTRR WC hole trick non functional. The changes are non trivial and so in this series I supplied changes on one driver only to show the effort required. The other drivers which required this were: Driver File fusion drivers/message/fusion/mptbase.c ivtvdrivers/media/pci/ivtv/ivtvfb.c ipath drivers/infiniband/hw/ipath/ipath_driver.c This series makes those drivers use __arch_phys_wc_add() more as a transitory phase in hopes we can address the proper split as with the atyfb illustrates. For ipath the changes required have a nice template with the qib driver as they share very similar driver structure, the qib driver *did* do the nice split. If so, can we ioremap + set_page_xyz instead? I'm not sure I see which call we'd use. Care to provide an example patch alternative for the atyfb as a case in point alternative to the work required to do the split? Luis -- 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 v1 21/47] ethernet: myri10ge: use arch_phys_wc_add()
On Sat, Mar 21, 2015 at 04:08:00PM +0900, Hyong-Youb Kim wrote:
On Fri, Mar 20, 2015 at 04:18:11PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
[...]
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
[...]
@@ -1984,7 +1979,6 @@ myri10ge_get_ethtool_stats(struct net_device *netdev,
data[i] = ((u64 *)link_stats)[i];
data[i++] = (unsigned int)mgp-tx_boundary;
- data[i++] = (unsigned int)mgp-wc_enabled;
data[i++] = (unsigned int)mgp-pdev-irq;
data[i++] = (unsigned int)mgp-msi_enabled;
data[i++] = (unsigned int)mgp-msix_enabled;
You would have to delete WC from myri10ge_gstrings_main_stats too.
Something like below. Thanks.
@@ -1905,7 +1905,7 @@ static const char
myri10ge_gstrings_main_stats[][ETH_GSTRING_LEN] = {
tx_aborted_errors, tx_carrier_errors, tx_fifo_errors,
tx_heartbeat_errors, tx_window_errors,
/* device-specific stats */
- tx_boundary, WC, irq, MSI, MSIX,
+ tx_boundary, irq, MSI, MSIX,
read_dma_bw_MBs, write_dma_bw_MBs, read_write_dma_bw_MBs,
serial_number, watchdog_resets,
#ifdef CONFIG_MYRI10GE_DCA
OK great thanks. Amended.
Luis
--
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 v1 05/47] pci: add pci_iomap_wc() variants
On Wed, Mar 25, 2015 at 04:07:43PM -0400, Konrad Rzeszutek Wilk wrote: On Fri, Mar 20, 2015 at 04:17:55PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com This allows drivers to take advantage of write-combining when possible. Ideally we'd have pci_read_bases() just peg an IORESOURCE_WC flag for us but where exactly video devices memory lie varies *largely* and at times things are mixed with MMIO registers, sometimes we can address the changes in drivers, other times the change requires intrusive changes. Although there is also arch_phys_wc_add() that makes use of architecture specific write-combinging alternatives (MTRR on combinging? Amended. diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c index bcce5f1..30b65ae 100644 --- a/lib/pci_iomap.c +++ b/lib/pci_iomap.c @@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev, EXPORT_SYMBOL(pci_iomap_range); /** + * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR + * @dev: PCI device that owns the BAR + * @bar: BAR number + * @offset: map memory at the given offset in BAR + * @maxlen: max length of the memory to map + * + * Using this function you will get a __iomem address to your device BAR. + * You can access it using ioread*() and iowrite*(). These functions hide + * the details if this is a MMIO or PIO address space and will just do what + * you expect from them in the correct way. When possible write combining + * is used. + * + * @maxlen specifies the maximum length to map. If you want to get access to + * the complete BAR from offset to the end, pass %0 here. s/%0/0 ? Or is that some special syntax? This copies the syntax of pci_iomap_range() which also uses %0, and as per Documentation/kernel-doc-nano-HOWTO.txt % is used for constants. See: scripts/kernel-doc -man -function pci_iomap_range lib/pci_iomap.c | nroff -man | less Luis -- 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 v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote: On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote: On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Ideally on systems using PAT we can expect a swift transition away from MTRR. There can be a few exceptions to this, one is where device drivers are known to exist on PATs with errata, another situation is observed on old device drivers where devices had combined MMIO register access with whatever area they typically later wanted to end up using MTRR for on the same PCI BAR. This situation can still be addressed by splitting up ioremap'd PCI BAR into two ioremap'd calls, one for MMIO registers, and another for whatever is desirable for write-combining -- in order to accomplish this though quite a bit of driver restructuring is required. Device drivers which are known to require large amount of re-work in order to split ioremap'd areas can use __arch_phys_wc_add() to avoid regressions when PAT is enabled. For a good example driver where things are neatly split up on a PCI BAR refer the infiniband qib driver. For a good example of a driver where good amount of work is required refer to the infiniband ipath driver. This is *only* a transitive API -- and as such no new drivers are ever expected to use this. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? Yes, I cc'd you just now on one where I made changes on a driver which uses one PCI with mixed memtypes and uses MTRR to hole in WC. A transition to arch_phys_wc_add() is therefore not possible if PAT is enabled as it would regress those drivers by making the MTRR WC hole trick non functional. The changes are non trivial and so in this series I supplied changes on one driver only to show the effort required. The other drivers which required this were: Driver File fusion drivers/message/fusion/mptbase.c ivtvdrivers/media/pci/ivtv/ivtvfb.c ipath drivers/infiniband/hw/ipath/ipath_driver.c This series makes those drivers use __arch_phys_wc_add() more as a transitory phase in hopes we can address the proper split as with the atyfb illustrates. For ipath the changes required have a nice template with the qib driver as they share very similar driver structure, the qib driver *did* do the nice split. If so, can we ioremap + set_page_xyz instead? I'm not sure I see which call we'd use. Care to provide an example patch alternative for the atyfb as a case in point alternative to the work required to do the split? I'm still confused. Would it be insufficient to ioremap_nocache the whole thing and then call set_memory_wc on parts of it? (Sorry, set_page_xyz was a typo.) I think that would be a sexy alternative. In this driver's case the thing is a bit messy as it not only used the WC MTRR for a hole but it also then used a UC MTRR on top of it all, so since I already tried to address the split, and if we address the power of 2 woes, I think it'd be best to try to remove the UC MTRR and just avoid set_page_wc() in this driver's case, but for the other cases (fusion, ivtv, ipath) I think this makes sense. Thoughts? Once that WC MTRR is in place, I think you really need UC and not UC- if you want to override it. Otherwise I agree with all of this. Do you mean that the UC MTRR work around that was in place might not have really been effective? Not quite sure what you mean. I don't think I follow. Luis -- 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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 27, 2015 at 02:21:34PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 1:12 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 20, 2015 at 04:52:18PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
- if (par-mtrr_aper = 0 !par-aux_start) {
- /* Make a hole for mmio. */
- par-mtrr_reg = mtrr_add(par-res_start +
0x80 -
-GUI_RESERVE,
GUI_RESERVE,
-MTRR_TYPE_UNCACHABLE,
1);
- if (par-mtrr_reg 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
- }
}
#endif
@@ -2776,10 +2765,6 @@ aty_init_exit:
par-pll_ops-set_pll(info, par-saved_pll);
#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
if (par-mtrr_aper = 0) {
mtrr_del(par-mtrr_aper, 0, 0);
par-mtrr_aper = -1;
@@ -3466,7 +3451,7 @@ static int atyfb_setup_generic(struct pci_dev
*pdev, struct fb_info *info,
}
info-fix.mmio_start = raddr;
- par-ati_regbase = ioremap(info-fix.mmio_start, 0x1000);
+ par-ati_regbase = ioremap_nocache(info-fix.mmio_start, 0x1000);
Double-check me, but I think that ioremap_nocache + WC MTRR = WC.
Precicely, in this case the WC hole was obtained by using MTRR WC. This
patch removes that WC hole trick and now we can be explciit about
only wanting ioremap_nocache() on the registers, that is WC is not
desired here and is not used. The patch does not highlight the fact
that there was left in place another ioremap() call for the framebuffer:
info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len);
That is the one that later after this patch we use ioremap_wc() for.
This patch just removes the hole solution. That's all.
I don't understand.
If I read it right, there's a 2^n byte BAR. You're requesting WC for
the whole think using arch_phys_wc_add.
I believe there is a misunderstanding of order of changes.
Let's split when we use mtrr_add() Vs arch_phys_wc_add() to avoid
confusion as in this patch we don't yet use arch_phys_wc_add(). That
is done in the next patch.
The commit log describes best the state of affairs prior to this
patch:
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap() the full framebuffer
including the MMIO space *and* ___then___ use an MTRR with
MTRR_TYPE_WRCOMB on the full PCI BAR... and finally hole
in an MTRR_TYPE_UNCACHABLE MTRR only for MMIO.
Then this patch drops the MTRR_TYPE_UNCACHABLE rewrite thing
and instead corrects the ioremap() call for the framebuffer
to only be called for the framebuffer alone. For the MMIO
area we adjust to use then ioremap_nocache(). The MTRR left
is now only *for the framebuffer* and it should not be touching
the MMIO area. So the MMIO area has its own ioremap_nocache()
area alone, the framebuffer is left with an ioremap() followed
by an mtrr_add() call.
The next patch replaces the mtrr_add() with arch_phys_wc_add()
and then also uses ioremap_wc().
On a PAT system that has no effect and all is well.
Yeah we're not doing arch_phys_wc_add() on the entire PCI BAR.
That was dumb, this fixes that, and on this patch mtrr_add()
is still used.
On a non-PAT system, it adds an MTRR. That
means that you need to override the MTRR somehow for the mmio regs,
and UC- won't do the trick.
We don't need to solve that problem here as the MTRR should only
be for the framebuffer.
Luis
--
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
Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()
On Fri, Mar 27, 2015 at 04:10:03PM -0700, Andy Lutomirski wrote: On Fri, Mar 27, 2015 at 4:04 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote: On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote: On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote: On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Ideally on systems using PAT we can expect a swift transition away from MTRR. There can be a few exceptions to this, one is where device drivers are known to exist on PATs with errata, another situation is observed on old device drivers where devices had combined MMIO register access with whatever area they typically later wanted to end up using MTRR for on the same PCI BAR. This situation can still be addressed by splitting up ioremap'd PCI BAR into two ioremap'd calls, one for MMIO registers, and another for whatever is desirable for write-combining -- in order to accomplish this though quite a bit of driver restructuring is required. Device drivers which are known to require large amount of re-work in order to split ioremap'd areas can use __arch_phys_wc_add() to avoid regressions when PAT is enabled. For a good example driver where things are neatly split up on a PCI BAR refer the infiniband qib driver. For a good example of a driver where good amount of work is required refer to the infiniband ipath driver. This is *only* a transitive API -- and as such no new drivers are ever expected to use this. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? Yes, I cc'd you just now on one where I made changes on a driver which uses one PCI with mixed memtypes and uses MTRR to hole in WC. A transition to arch_phys_wc_add() is therefore not possible if PAT is enabled as it would regress those drivers by making the MTRR WC hole trick non functional. The changes are non trivial and so in this series I supplied changes on one driver only to show the effort required. The other drivers which required this were: Driver File fusion drivers/message/fusion/mptbase.c ivtvdrivers/media/pci/ivtv/ivtvfb.c ipath drivers/infiniband/hw/ipath/ipath_driver.c This series makes those drivers use __arch_phys_wc_add() more as a transitory phase in hopes we can address the proper split as with the atyfb illustrates. For ipath the changes required have a nice template with the qib driver as they share very similar driver structure, the qib driver *did* do the nice split. If so, can we ioremap + set_page_xyz instead? I'm not sure I see which call we'd use. Care to provide an example patch alternative for the atyfb as a case in point alternative to the work required to do the split? I'm still confused. Would it be insufficient to ioremap_nocache the whole thing and then call set_memory_wc on parts of it? (Sorry, set_page_xyz was a typo.) I think that would be a sexy alternative. In this driver's case the thing is a bit messy as it not only used the WC MTRR for a hole but it also then used a UC MTRR on top of it all, so since I already tried to address the split, and if we address the power of 2 woes, I think it'd be best to try to remove the UC MTRR and just avoid set_page_wc() in this driver's case, but for the other cases (fusion, ivtv, ipath) I think this makes sense. Thoughts? Once that WC MTRR is in place, I think you really need UC and not UC- if you want to override it. Otherwise I agree with all of this. Do you mean that the UC MTRR work around that was in place might not have really been effective? Not quite sure what you mean. I don't think I follow. I mean that the UC MTRR that overrides the WC MTRR was probably fine (I hope smaller MTRRs override larger MTRRs). But we should just ditch UC MTRRs entirely, Agreed, this series does that, and this patch addresses the last UC MTRR ;) and setting UC in the page tables would work on all CPUs *if we supported that*. We'd need to add a couple trivial helpers to do that. OK please check my latest reply and if you do not mind clarify what you mean there as I am not sure if we're on the same page (no pun) here. I don't quite follow this last
Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
On Wed, Mar 25, 2015 at 03:59:41PM -0400, Konrad Rzeszutek Wilk wrote: On Fri, Mar 20, 2015 at 04:17:52PM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com It is possible to enable CONFIG_MTRR and up with it disabled at run time and yet CONFIG_X86_PAT continues to kick through fully functionally. This can happen s/fully/full/ ? I'll rephrase this to: --- It is possible to enable CONFIG_MTRR and up with it disabled at run time and yet CONFIG_X86_PAT continues to kick through with all functionally enabled. This can happen for instance on Xen where MTRR is not supported but PAT is, this can happen now on Linux as of commit 47591df50 by Juergen introduced as of v3.19. --- Which BTW I had also mentioned on the cover letter that this is a good time to address if we want to make PAT then a first class citizen, to detangle it from depending on MTRR. If so I can do that later. Technically we should assume the proper CPU bits would be set to disable MTRR but we can't always rely on this. At least on the Xen Hypervisor for instance only X86_FEATURE_MTRR was disabled as of Xen 4.4 through Xen commit 586ab6a [0], but not X86_FEATURE_K6_MTRR, X86_FEATURE_CENTAUR_MCR, or X86_FEATURE_CYRIX_ARR for instance. Oh, could you send an patch for that to Xen please? Done. x86 mtrr code relies on quite a bit of checks for mtrr_if being set to check to see if MTRR did get set up, instead of using that lets provide a generic setter which when set we know MTRR is enabled. This s/we know MTRR is enabled/will let us know that MTRR is enabled/ Amended. Luis -- 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 v1 05/47] pci: add pci_iomap_wc() variants
On Mon, Mar 23, 2015 at 12:20:47PM -0500, Bjorn Helgaas wrote:
Hi Luis,
This seems OK to me,
Great.
but I'm curious about a few things.
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us
We do set IORESOURCE_PREFETCH. Do you mean something different?
I did not think we had a WC IORESOURCE flag. Are you saying that we can use
IORESOURCE_PREFETCH for that purpose? If so then great. As I read a PCI BAR
can have PCI_BASE_ADDRESS_MEM_PREFETCH and when that's the case we peg
IORESOURCE_PREFETCH. That seems to be what I want indeed. Questions below.
but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO registers, sometimes we can address
the changes in drivers, other times the change requires
intrusive changes.
What does a video device address have to do with this? I do see that
if a BAR maps only a frame buffer, the device might be able to mark it
prefetchable, while if the BAR mapped both a frame buffer and some
registers, it might not be able to make it prefetchable. But that
doesn't seem like it depends on the *address*.
I meant the offsets for each of those, either registers or framebuffer,
and that typically they are mixed (primarily on older devices), so indeed your
summary of the problem is what I meant. Let's remember that we are trying to
take advantage of PAT here when available and avoid MTRR in that case, do we
know that the same PCI BARs that have always historically used MTRRs had
IORESOURCE_PREFETCH set, is that a fair assumption ? I realize they are
different things -- but its precisely why I ask.
pci_iomap_range() already makes a cacheable mapping if
IORESOURCE_CACHEABLE; I'm guessing that you would like it to
automatically use WC if the BAR if IORESOURCE_PREFETCH, e.g.,
if (flags IORESOURCE_CACHEABLE)
return ioremap(start, len);
if (flags IORESOURCE_PREFETCH)
return ioremap_wc(start, len);
return ioremap_nocache(start, len);
Indeed, that's exactly what I think we should strive towards.
Is there a reason not to do that?
This depends on the exact defintion of IORESOURCE_PREFETCH and
PCI_BASE_ADDRESS_MEM_PREFETCH and how they are used all over and
accross *all devices*. This didn't look promising for starters:
include/uapi/linux/pci_regs.h:#define PCI_BASE_ADDRESS_MEM_PREFETCH0x08
/* prefetchable? */
PCI_BASE_ADDRESS_MEM_PREFETCH seems to be BAR specific, so a few questions:
1) Can we rest assured for instance that if we check for
PCI_BASE_ADDRESS_MEM_PREFETCH and if set that it will *only* be set on a full
PCI BAR if the full PCI BAR does want WC? If not this can regress
functionality. That seems risky. It however would not be risky if we used
another API that did look for IORESOURCE_PREFETCH and if so use ioremap_wc() --
that way only drivers we know that do use the full PCI bar would use this API.
There's a bit of a problem with this though:
2) Do we know that if a *full PCI BAR* is used for WC that
PCI_BASE_ADDRESS_MEM_PREFETCH *was* definitely set for the PCI BAR? If so then
the API usage would be restricted only to devices that we know *do* adhere to
this. That reduces the possible uses for older drivers and can create
regressions if used loosely without verification... but..
3) If from now on we get folks to commit to uset PCI_BASE_ADDRESS_MEM_PREFETCH
for full PCI BARs that do want WC perhaps newer devices / drivers will use
this very consistently ? Can we bank on that and is it worth it ?
4) If a PCI BAR *does not* have PCI_BASE_ADDRESS_MEM_PREFETCH do we know it
must not never want WC ?
If we don't have certainty on any of the above I'm afraid we can't do much
right now but perhaps we can push towards better use of
PCI_BASE_ADDRESS_MEM_PREFETCH
and hope folks will only use this for the full PCI BAR only if WC is desired.
Thoughts?
Although there is also arch_phys_wc_add() that makes use of
architecture specific write-combinging alternatives (MTRR on
x86 when a system does not have PAT) we void polluting
pci_iomap() space with it and force drivers and subsystems
that want to use it to be explicit.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (de33c442e)
...
+void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
+int bar,
+unsigned long offset,
+unsigned long maxlen)
+{
+ resource_size_t start = pci_resource_start(dev, bar);
+ resource_size_t
Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote:
On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote:
:
@@ -734,6 +742,7 @@ void __init mtrr_bp_init(void)
}
if (mtrr_if) {
+ mtrr_enabled = true;
set_num_var_ranges();
init_table();
if (use_intel()) {
get_mtrr_state();
After setting mtrr_enabled to true, get_mtrr_state() reads
MSR_MTRRdefType and sets 'mtrr_state.enabled', which also indicates if
MTRRs are enabled or not on the system. So, potentially, we could have
a case that mtrr_enabled is set to true, but mtrr_state.enabled is set
to disabled when MTRRs are disabled by BIOS.
Thanks for the review, in this case then we should update mtrr_enabled to false.
ps.
I recently cleaned up this part of the MTRR code in the patch below,
which is currently available in the -mm -next trees.
https://lkml.org/lkml/2015/3/24/1063
Great I will rebase and work with that and try to address this
consideration you have raised.
Luis
--
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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
As per mtrr_add_page() [0] the base and size are just supposed to be
in units
of 4 KiB, although the practice is to use powers of 2 in *some*
drivers this
is not standardized and by no means recorded as a requirement.
Obviously
powers of 2 will work too and you'd end up neatly aligned as well.
mtrr_add()
will use mtrr_check() to verify the the same requirement. Furthermore,
as per my commit log message:
Whatever the code may or may not do, the x86 architecture uses
power-of-two MTRR sizes. So I'm confused.
There should be no confusion, I simply did not know that *was* the
requirement for x86, if that is the case we should add a check for that
and perhaps generalize a helper that does the power of two helper changes,
the cleanest I found was the vesafb driver solution.
Thoughts?
The vesafb solution is bad since you'll only end up covering only
the first 4MB of the framebuffer instead of the almost 8MB you want.
Which in practice will mean throwing away half the VRAM since you really
don't want the massive performance hit from accessing it as UC. And that
would mean giving up decent display resolutions as well :(
And the other option of trying to cover the remainder with multiple ever
smaller MTRRs doesn't work either since you'll run out of MTRRs very
quickly.
This is precisely why I used the hole method in atyfb in the first
place.
I don't really like the idea of any new mtrr code not supporting that
use case, especially as these things tend to be present in older machines
where PAT isn't an option.
According to the Intel SDM, volume 3, section 11.5.2.1, table 11-6,
non-PAT CPUs that have a WC MTRR, PCD = 1, and PWT = 1 (aka UC) have
an effective memory type of UC. Hence my suggestion to add
ioremap_x86_uc and/or set_memory_x86_uc to punch a UC hole in an
otherwise WC MTRR-covered region.
OK I think I get it now.
And I take it this would hopefully only be used for non-PAT systems?
Would there be a use case for PAT systems? I wonder if we can wrap
this under some APIs to make it clean and hide this dirty thing
behind the scenes, it seems a fragile and error prone and my hope
would be that we won't need more specialization in this area for
PAT systems.
ioremap_nocache is UC- (even on non-PAT unless I misunderstood how
this stuff works), so ioremap_nocache by itself isn't good enough.
Thanks for the clarification.
Luis
--
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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Fri, Mar 27, 2015 at 11:56:55PM +0200, Ville Syrjälä wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
As per mtrr_add_page() [0] the base and size are just supposed to be in
units
of 4 KiB, although the practice is to use powers of 2 in *some* drivers
this
is not standardized and by no means recorded as a requirement. Obviously
powers of 2 will work too and you'd end up neatly aligned as well.
mtrr_add()
will use mtrr_check() to verify the the same requirement. Furthermore,
as per my commit log message:
Whatever the code may or may not do, the x86 architecture uses
power-of-two MTRR sizes. So I'm confused.
There should be no confusion, I simply did not know that *was* the
requirement for x86, if that is the case we should add a check for that
and perhaps generalize a helper that does the power of two helper changes,
the cleanest I found was the vesafb driver solution.
Thoughts?
The vesafb solution is bad since you'll only end up covering only
the first 4MB of the framebuffer instead of the almost 8MB you want.
OK so the power of 2 requirement implicates us *having* to use a large
MTRR that includes the MMIo region in the shared PCI case?
Andy, Ville, are we 100% certain about this power of two requirement?
Is that for the base and size or just the size?
Luis
--
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: [Xen-devel] [PATCH v2 2/2] x86, arm, platform, xen, kconfig: add xen defconfig helper
On Tue, Jan 13, 2015 at 11:13 AM, Julien Grall julien.gr...@linaro.org wrote: Stefano had some comments on this patch. See: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01531.html I see now sorry about that, will address and respin. Luis -- 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: [Xen-devel] [PATCH v2 2/2] x86/xen: allow privcmd hypercalls to be preempted
On Thu, Dec 18, 2014 at 02:23:14PM -0500, Konrad Rzeszutek Wilk wrote: index 000..b5a3e98 --- /dev/null +++ b/drivers/xen/preempt.c @@ -0,0 +1,17 @@ +/* + * Preemptible hypercalls + * + * Copyright (C) 2014 Citrix Systems RD ltd. + * + * This source code is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + */ + +#include xen/xen-ops.h + +#ifndef CONFIG_PREEMPT +DEFINE_PER_CPU(bool, xen_in_preemptible_hcall); +EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall); +#endif Please also add this in the patch: diff --git a/drivers/xen/preempt.c b/drivers/xen/preempt.c index b5a3e98..5d773dc 100644 --- a/drivers/xen/preempt.c +++ b/drivers/xen/preempt.c @@ -13,5 +13,5 @@ #ifndef CONFIG_PREEMPT DEFINE_PER_CPU(bool, xen_in_preemptible_hcall); -EXPORT_SYMBOL_GPL(xen_in_preemptible_hcall); +EXPORT_PER_CPU_SYMBOL_GPL(xen_in_preemptible_hcall); #endif Ammended, although I think we want another approach now based on the recommendations by Andy Lutomirski. Luis -- 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 0/2] x86/arm64: add xenconfig
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com wrote: On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote: On Fri, 23 Jan 2015, Luis R. Rodriguez wrote: On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com This v3 addresses Stefano's feedback from the v2 series, namely moving PCI stuff to x86 as its all x86 specific and also just removing the CONFIG_TCG_XEN=m from the general config. To be clear the changes from the v2 series are below. Luis R. Rodriguez (2): x86, platform, xen, kconfig: clarify kvmconfig is for kvm x86, arm, platform, xen, kconfig: add xen defconfig helper arch/x86/configs/xen.config | 10 ++ kernel/configs/xen.config | 26 ++ scripts/kconfig/Makefile| 7 ++- 3 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 arch/x86/configs/xen.config create mode 100644 kernel/configs/xen.config Who could these changes go through? I would be OK with taking it in the Xen tree, but I would feel more comfortable doing that if you had an ack from Yann Morin (CC'ed). *Poke* Hey Yann, wondering if you had any feedback. Thanks. Luis -- 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 v5 2/2] x86/xen: allow privcmd hypercalls to be preempted on 64-bit
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote: On 27/01/15 08:35, Jan Beulich wrote: On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote: Even if David told you this would be acceptable, I have to question an abstract model of fixing issues on only 64-bit kernels - this may be acceptable for distro purposes, but seems hardly the right approach for upstream. If 32-bit ones are to become deliberately broken, the XEN config option should become dependent on !X86_32. I'd rather have something omitted (keeping the current behaviour) than something that has not been tested at all. Obviously it would be preferable to to fix both 32-bit and 64-bit x86 (and ARM as well) but I'm not going to block an important bug fix for the majority use case (64-bit x86). Hey folks, what is the status of these patches? Any more feedback? Luis -- 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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez
mcg...@suse.com wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info
*info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start,
par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
As per mtrr_add_page() [0] the base and size are just supposed to
be in units
of 4 KiB, although the practice is to use powers of 2 in *some*
drivers this
is not standardized and by no means recorded as a requirement.
Obviously
powers of 2 will work too and you'd end up neatly aligned as well.
mtrr_add()
will use mtrr_check() to verify the the same requirement.
Furthermore,
as per my commit log message:
Whatever the code may or may not do, the x86 architecture uses
power-of-two MTRR sizes. So I'm confused.
There should be no confusion, I simply did not know that *was* the
requirement for x86, if that is the case we should add a check for that
and perhaps generalize a helper that does the power of two helper
changes,
the cleanest I found was the vesafb driver solution.
Thoughts?
The vesafb solution is bad since you'll only end up covering only
the first 4MB of the framebuffer instead of the almost 8MB you want.
Which in practice will mean throwing away half the VRAM since you really
don't want the massive performance hit from accessing it as UC. And that
would mean giving up decent display resolutions as well :(
And the other option of trying to cover the remainder with multiple ever
smaller MTRRs doesn't work either since you'll run out of MTRRs very
quickly.
This is precisely why I used the hole method in atyfb in the first
place.
I don't really like the idea of any new mtrr code not supporting that
use case, especially as these things tend to be present in older
machines
where PAT isn't an option.
According to the Intel SDM, volume 3, section 11.5.2.1, table 11-6,
non-PAT CPUs that have a WC MTRR, PCD = 1, and PWT = 1 (aka UC) have
an effective memory type of UC.
This is true but non-PAT systems that use just ioremap() will default to
_PAGE_CACHE_MODE_UC_MINUS, not _PAGE_CACHE_MODE_UC, and
_PAGE_CACHE_MODE_UC_MINUS
on Linux has PCD = 1, PWT = 0. The list comes from:
uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
[_PAGE_CACHE_MODE_WB ] = 0 | 0,
[_PAGE_CACHE_MODE_WC ] = _PAGE_PWT | 0,
[_PAGE_CACHE_MODE_UC_MINUS] = 0 | _PAGE_PCD,
[_PAGE_CACHE_MODE_UC ] = _PAGE_PWT | _PAGE_PCD,
[_PAGE_CACHE_MODE_WT ] = 0 | _PAGE_PCD,
[_PAGE_CACHE_MODE_WP ] = 0 | _PAGE_PCD,
};
This can better be read here:
PAT
|PCD
||PWT
|||
000 WB _PAGE_CACHE_MODE_WB
001 WC _PAGE_CACHE_MODE_WC
010 UC- _PAGE_CACHE_MODE_UC_MINUS
011 UC _PAGE_CACHE_MODE_UC
On x86 ioremap() defaults to ioremap_nocache() and right now that uses
_PAGE_CACHE_MODE_UC_MINUS not _PAGE_CACHE_MODE_UC. We have two cases
to consider for non-PAT systems then:
a) Right now as ioremap() and ioremap_nocache() default to
_PAGE_CACHE_MODE_UC_MINUS
on x86. In this case using a WC MTRR seems to use PWT=0, PCD=1, and
table table 11-6 on non-PAT systems seems to place this situation as
implementation defined and not encouraged.
a) when commit de33c442e x86 PAT: fix performance drop for glx, use
UC minus
Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas bhelg...@google.com wrote: On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez mcg...@suse.com wrote: I'll rephrase this to: --- It is possible to enable CONFIG_MTRR and up with it disabled at run time and yet CONFIG_X86_PAT continues to kick through with all functionally enabled. This can happen for instance on Xen where MTRR is not supported but PAT is, this can happen now on Linux as of commit 47591df50 by Juergen introduced as of v3.19. I still can't parse this. What does up with it disabled at run time mean? It means that technically even if your CPU/BIOS/system did support MTRR if you use a kernel with MTRR support enabled you might end up with a situation where under one situation MTRR might be enabled and at another run time scenario with the same exact kernel and system you will end up with MTRR disabled. Such is the case for example when booting with Xen, which disables the CPU bits on the hypervisor code. If you boot the same system without Xen you'll get MTRR. And ... continues to kick through? Probably some idiomatic usage I'm just too old to understand :) That means for example that in both the above circumstances even if MTRR went disabled at run time with Xen, the kernel went through with getting PAT enabled. Please use the conventional citation format: 47591df50512 (xen: Support Xen pv-domains using PAT) A one-character typo in a SHA1 makes it completely useless, so it's nice to have the summary line both for readability and a bit of redundancy. Sure, fixed. Luis -- 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 v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Wed, Apr 01, 2015 at 05:04:08PM -0700, Andy Lutomirski wrote:
On Wed, Apr 1, 2015 at 4:52 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez
mcg...@suse.com wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez
wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info
*info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start,
par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
As per mtrr_add_page() [0] the base and size are just supposed
to be in units
of 4 KiB, although the practice is to use powers of 2 in *some*
drivers this
is not standardized and by no means recorded as a requirement.
Obviously
powers of 2 will work too and you'd end up neatly aligned as
well. mtrr_add()
will use mtrr_check() to verify the the same requirement.
Furthermore,
as per my commit log message:
Whatever the code may or may not do, the x86 architecture uses
power-of-two MTRR sizes. So I'm confused.
There should be no confusion, I simply did not know that *was* the
requirement for x86, if that is the case we should add a check for
that
and perhaps generalize a helper that does the power of two helper
changes,
the cleanest I found was the vesafb driver solution.
Thoughts?
The vesafb solution is bad since you'll only end up covering only
the first 4MB of the framebuffer instead of the almost 8MB you want.
Which in practice will mean throwing away half the VRAM since you
really
don't want the massive performance hit from accessing it as UC. And
that
would mean giving up decent display resolutions as well :(
And the other option of trying to cover the remainder with multiple
ever
smaller MTRRs doesn't work either since you'll run out of MTRRs very
quickly.
This is precisely why I used the hole method in atyfb in the first
place.
I don't really like the idea of any new mtrr code not supporting that
use case, especially as these things tend to be present in older
machines
where PAT isn't an option.
According to the Intel SDM, volume 3, section 11.5.2.1, table 11-6,
non-PAT CPUs that have a WC MTRR, PCD = 1, and PWT = 1 (aka UC) have
an effective memory type of UC.
This is true but non-PAT systems that use just ioremap() will default to
_PAGE_CACHE_MODE_UC_MINUS, not _PAGE_CACHE_MODE_UC, and
_PAGE_CACHE_MODE_UC_MINUS
on Linux has PCD = 1, PWT = 0. The list comes from:
uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
[_PAGE_CACHE_MODE_WB ] = 0 | 0,
[_PAGE_CACHE_MODE_WC ] = _PAGE_PWT | 0,
[_PAGE_CACHE_MODE_UC_MINUS] = 0 | _PAGE_PCD,
[_PAGE_CACHE_MODE_UC ] = _PAGE_PWT | _PAGE_PCD,
[_PAGE_CACHE_MODE_WT ] = 0 | _PAGE_PCD,
[_PAGE_CACHE_MODE_WP ] = 0 | _PAGE_PCD,
};
This can better be read here:
PAT
|PCD
||PWT
|||
000 WB _PAGE_CACHE_MODE_WB
001 WC _PAGE_CACHE_MODE_WC
010 UC- _PAGE_CACHE_MODE_UC_MINUS
011 UC _PAGE_CACHE_MODE_UC
On x86 ioremap() defaults to ioremap_nocache() and right now that uses
_PAGE_CACHE_MODE_UC_MINUS not _PAGE_CACHE_MODE_UC. We have two cases
to consider for non-PAT systems then:
a) Right now as ioremap() and ioremap_nocache() default to
_PAGE_CACHE_MODE_UC_MINUS
on x86. In this case using a WC MTRR seems to use PWT=0, PCD=1, and
table table 11-6 on non-PAT systems seems to place this situation as
implementation
Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
On Thu, Apr 2, 2015 at 3:09 PM, Bjorn Helgaas bhelg...@google.com wrote: On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez mcg...@suse.com wrote: --- It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT and end up with a system with MTRR functionality disabled PAT functionality enabled. This is missing a conjunction or something in MTRR functionality disabled PAT functionality. and PAT functionality -- fixed. Thanks. Luis -- 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 v1 02/47] x86: mtrr: generalize run time disabling of MTRR
On Sat, Mar 28, 2015 at 12:56:30AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote:
On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote:
:
@@ -734,6 +742,7 @@ void __init mtrr_bp_init(void)
}
if (mtrr_if) {
+ mtrr_enabled = true;
set_num_var_ranges();
init_table();
if (use_intel()) {
get_mtrr_state();
After setting mtrr_enabled to true, get_mtrr_state() reads
MSR_MTRRdefType and sets 'mtrr_state.enabled', which also indicates if
MTRRs are enabled or not on the system. So, potentially, we could have
a case that mtrr_enabled is set to true, but mtrr_state.enabled is set
to disabled when MTRRs are disabled by BIOS.
Thanks for the review, in this case then we should update mtrr_enabled to
false.
ps.
I recently cleaned up this part of the MTRR code in the patch below,
which is currently available in the -mm -next trees.
https://lkml.org/lkml/2015/3/24/1063
Great I will rebase and work with that and try to address this
consideration you have raised.
OK I'll mesh in this change as well in my next respin:
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index a83f27a..ecf7cb9 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -438,7 +438,7 @@ static void __init print_mtrr_state(void)
}
/* Grab all of the MTRR state for this CPU into *state */
-void __init get_mtrr_state(void)
+bool __init get_mtrr_state(void)
{
struct mtrr_var_range *vrs;
unsigned long flags;
@@ -482,6 +482,8 @@ void __init get_mtrr_state(void)
post_set();
local_irq_restore(flags);
+
+ return !!mtrr_state.enabled;
}
/* Some BIOS's are messed up and don't set all MTRRs the same! */
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index ea5f363..f96195e 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -734,22 +742,25 @@ void __init mtrr_bp_init(void)
}
if (mtrr_if) {
+ mtrr_enabled = true;
set_num_var_ranges();
init_table();
if (use_intel()) {
- get_mtrr_state();
+ /* BIOS may override */
+ mtrr_enabled = get_mtrr_state();
if (mtrr_cleanup(phys_addr)) {
changed_by_mtrr_cleanup = 1;
@@ -745,11 +755,14 @@ void __init mtrr_bp_init(void)
}
}
}
+
+ if (!mtrr_enabled)
+ pr_info(mtrr: system does not support MTRR\n);
}
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.h b/arch/x86/kernel/cpu/mtrr/mtrr.h
index df5e41f..951884d 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -51,7 +51,7 @@ void set_mtrr_prepare_save(struct set_mtrr_context *ctxt);
void fill_mtrr_var_range(unsigned int index,
u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi);
-void get_mtrr_state(void);
+bool get_mtrr_state(void);
extern void set_mtrr_ops(const struct mtrr_ops *ops);
--
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 v1 06/47] mtrr: add __arch_phys_wc_add()
On Thu, Apr 02, 2015 at 03:21:22PM -0500, Bjorn Helgaas wrote: On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com Ideally on systems using PAT we can expect a swift transition away from MTRR. There can be a few exceptions to this, one is where device drivers are known to exist on PATs with errata, This probably makes sense to someone steeped in MTRR and PAT, but not otherwise. One exception is where drivers are known to exist on PATs with errata? The drivers exist, independent of PAT/MTRR/errata. Do you mean there are drivers that can't be converted from MTRR to PAT because some PATs are broken? Well there is that but it seems we have motivation to address the PAT broken systems so this would be one of the lower priority reasons to consider adding this API. The more important reason is below. I don't really know anything about MTRR or PAT; I'm just trying to figure out how to parse this paragraph. Sure. another situation is observed on old device drivers where devices had combined MMIO register access with whatever area they typically later wanted to end up using MTRR for on the same PCI BAR. This situation can still be addressed by splitting up ioremap'd PCI BAR into two ioremap'd calls, one for MMIO registers, and another for whatever is desirable for write-combining -- in order to accomplish this though quite a bit of driver restructuring is required. Device drivers which are known to require large amount of re-work in order to split ioremap'd areas can use __arch_phys_wc_add() to avoid regressions when PAT is enabled. For a good example driver where things are neatly split up on a PCI BAR refer the infiniband qib driver. For a good example of a driver where good amount of work is required refer to the infiniband ipath driver. This is *only* a transitive API -- and as such no new drivers are ever expected to use this. transient? Do you mean you intend to remove this API in the near future? That's correct, the problem is that in order to use PAT cleanly we'd need to change these drivers to not overlap ioremap'd areas otherwise things can get quite complex, and changing the way we do the ioremap() calls on a driver might require a bit of work. The atyfb driver changes I did are an example of the types of changes that are expected. In the most complex worst cases there are MTRR hole tricks used, and as can be observed with the atyfb driver changes there are a series of things to consider when this is done specially in light of eventually making strong UC the default instead of UC-. I might be able to work around not adding this API by reviewing the users I had in this series again and seeing if something similar to what I will do on atyfb can be done in the meantime by using ioremap_uc(). Its not clear to me yet. Luis -- 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/
