From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:20:57
From: "Luis R. Rodriguez" <redacted>
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: i810: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()
video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
Documentation/driver-model/devres.txt | 1 +
arch/x86/include/asm/io.h | 6 ++
arch/x86/include/asm/mtrr.h | 7 +-
arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
arch/x86/kernel/cpu/mtrr/generic.c | 7 +-
arch/x86/kernel/cpu/mtrr/if.c | 3 +
arch/x86/kernel/cpu/mtrr/main.c | 73 +++++++++++++------
drivers/gpu/drm/drm_ioctl.c | 14 +---
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 +++++--------
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 31 ++------
drivers/media/pci/ivtv/ivtvfb.c | 51 ++++----------
drivers/message/fusion/mptbase.c | 19 ++---
drivers/message/fusion/mptbase.h | 2 +-
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 36 +++-------
drivers/pci/pci.c | 14 ++++
drivers/staging/sm750fb/sm750.c | 34 ++-------
drivers/staging/sm750fb/sm750.h | 3 -
drivers/staging/sm750fb/sm750_hw.c | 3 +-
drivers/staging/xgifb/XGI_main_26.c | 27 ++-----
drivers/video/fbdev/arkfb.c | 36 ++--------
drivers/video/fbdev/atmel_lcdfb.c | 3 +-
drivers/video/fbdev/aty/aty128fb.c | 36 ++--------
drivers/video/fbdev/aty/atyfb.h | 5 +-
drivers/video/fbdev/aty/atyfb_base.c | 90 ++++++++----------------
drivers/video/fbdev/aty/radeon_base.c | 29 ++------
drivers/video/fbdev/aty/radeonfb.h | 2 +-
drivers/video/fbdev/gbefb.c | 18 +++--
drivers/video/fbdev/geode/gxfb_core.c | 3 +-
drivers/video/fbdev/gxt4500.c | 2 +-
drivers/video/fbdev/i740fb.c | 35 ++-------
drivers/video/fbdev/i810/i810.h | 3 +-
drivers/video/fbdev/i810/i810_main.c | 11 +--
drivers/video/fbdev/i810/i810_main.h | 26 -------
drivers/video/fbdev/intelfb/intelfb.h | 4 +-
drivers/video/fbdev/intelfb/intelfbdrv.c | 38 ++--------
drivers/video/fbdev/kyro/fbdev.c | 33 +++------
drivers/video/fbdev/matrox/matroxfb_base.c | 36 ++++------
drivers/video/fbdev/matrox/matroxfb_base.h | 27 +------
drivers/video/fbdev/neofb.c | 26 ++-----
drivers/video/fbdev/nvidia/nv_type.h | 7 +-
drivers/video/fbdev/nvidia/nvidia.c | 37 ++--------
drivers/video/fbdev/pm2fb.c | 31 ++------
drivers/video/fbdev/pm3fb.c | 30 ++------
drivers/video/fbdev/riva/fbdev.c | 39 ++--------
drivers/video/fbdev/riva/rivafb.h | 4 +-
drivers/video/fbdev/s3fb.c | 35 ++-------
drivers/video/fbdev/savage/savagefb.h | 4 +-
drivers/video/fbdev/savage/savagefb_driver.c | 17 +----
drivers/video/fbdev/sis/sis.h | 2 +-
drivers/video/fbdev/sis/sis_main.c | 27 ++-----
drivers/video/fbdev/tdfxfb.c | 41 ++---------
drivers/video/fbdev/vesafb.c | 77 +++++++-------------
drivers/video/fbdev/vt8623fb.c | 31 ++------
include/asm-generic/pci_iomap.h | 14 ++++
include/linux/io.h | 12 ++++
include/linux/pci.h | 1 +
include/video/kyro.h | 4 +-
include/video/neomagic.h | 5 +-
include/video/tdfx.h | 2 +-
lib/devres.c | 29 ++++++++
lib/pci_iomap.c | 61 ++++++++++++++++
63 files changed, 463 insertions(+), 901 deletions(-)
--
2.3.2.209.gd67f9d5.dirty
@@ -50,6 +51,7 @@ extern int mtrr_trim_uncached_memory(unsigned long end_pfn);externintamd_special_default_mtrr(void);externintphys_wc_to_mtrr_index(inthandle);# else+staticconstintmtrr_enabled;staticinlineu8mtrr_type_lookup(u64addr,u64end){/*
@@ -880,7 +880,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)*Makesureweonlytrimuncachablememoryonmachinesthat*supporttheIntelMTRRarchitecture:*/-if(!is_cpu(INTEL)||disable_mtrr_trim)+if(!is_cpu(INTEL)||disable_mtrr_trim||!mtrr_enabled)return0;rdmsr(MSR_MTRRdefType,def,dummy);
@@ -116,7 +116,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)u8prev_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)return0xFF;if(!mtrr_state.enabled)
@@ -84,6 +85,9 @@ static int have_wrcomb(void){structpci_dev*dev;+if(!mtrr_enabled)+return0;+dev=pci_get_class(PCI_CLASS_BRIDGE_HOST<<8,NULL);if(dev!=NULL){/*
@@ -286,7 +290,7 @@ int mtrr_add_page(unsigned long base, unsigned long size,inti,replace,error;mtrr_typeltype;-if(!mtrr_if)+if(!mtrr_enabled)return-ENXIO;error=mtrr_if->validate_add_page(base,size,type);
@@ -388,6 +392,8 @@ int mtrr_add_page(unsigned long base, unsigned long size,staticintmtrr_check(unsignedlongbase,unsignedlongsize){+if(!mtrr_enabled)+return-ENODEV;if((base&(PAGE_SIZE-1))||(size&(PAGE_SIZE-1))){pr_warning("mtrr: size and base must be multiples of 4 kiB\n");pr_debug("mtrr: size: 0x%lx base: 0x%lx\n",size,base);
@@ -463,8 +469,8 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)unsignedlonglbase,lsize;interror=-EINVAL;-if(!mtrr_if)-return-ENXIO;+if(!mtrr_enabled)+return-ENODEV;max=num_var_ranges;/* No CPU hotplug when we change MTRR entries */
@@ -523,6 +529,8 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)*/intmtrr_del(intreg,unsignedlongbase,unsignedlongsize){+if(!mtrr_enabled)+return-ENODEV;if(mtrr_check(base,size))return-EINVAL;returnmtrr_del_page(reg,base>>PAGE_SHIFT,size>>PAGE_SHIFT);
@@ -545,7 +553,7 @@ int arch_phys_wc_add(unsigned long base, unsigned long size){intret;-if(pat_enabled)+if(pat_enabled||!mtrr_enabled)return0;/* Success! (We don't need to do anything.) */ret=mtrr_add(base,size,MTRR_TYPE_WRCOMB,true);
@@ -744,12 +753,13 @@ void __init mtrr_bp_init(void)mtrr_if->set_all();}}-}+}else+pr_info("mtrr: system does not support MTRR\n");}voidmtrr_ap_init(void){-if(!use_intel()||mtrr_aps_delayed_init)+if(!use_intel()||mtrr_aps_delayed_init||!mtrr_enabled)return;/**Ideallyweshouldholdmtrr_mutexheretoavoidmtrrentries
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:29:45
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/pci/pci.c | 14 ++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
@@ -15,9 +15,13 @@ struct pci_dev;#ifdef CONFIG_PCI/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */externvoid__iomem*pci_iomap(structpci_dev*dev,intbar,unsignedlongmax);+externvoid__iomem*pci_iomap_wc(structpci_dev*dev,intbar,unsignedlongmax);externvoid__iomem*pci_iomap_range(structpci_dev*dev,intbar,unsignedlongoffset,unsignedlongmaxlen);+externvoid__iomem*pci_iomap_wc_range(structpci_dev*dev,intbar,+unsignedlongoffset,+unsignedlongmaxlen);/* Create a virtual mapping cookie for a port on a given PCI device.*Donotcallthisdirectly,itexiststomakeiteasierforarchitectures*tooverride*/
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned lonreturnNULL;}+staticinlinevoid__iomem*pci_iomap_wc(structpci_dev*dev,intbar,unsignedlongmax)+{+returnNULL;+}staticinlinevoid__iomem*pci_iomap_range(structpci_dev*dev,intbar,unsignedlongoffset,unsignedlongmaxlen){returnNULL;}+staticinlinevoid__iomem*pci_iomap_wc_range(structpci_dev*dev,intbar,+unsignedlongoffset,+unsignedlongmaxlen)+{+returnNULL;+}#endif#endif /* __ASM_GENERIC_IO_H */
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:34:13
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
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(-)
@@ -538,23 +538,24 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)EXPORT_SYMBOL(mtrr_del);/**-*arch_phys_wc_add-addaWCMTRRandhandleerrorsifPATisunavailable+*__arch_phys_wc_add-addaWCMTRRevenifPATisavailable*@base:Physicalbaseaddress*@size:Sizeofregion*-*IfPATisavailable,thisdoesnothing.IfPATisunavailable,it-*attemptstoaddaWCMTRRcoveringsizebytesstartingatbaseand-*logsanerrorifthisfails.+*WetypicallydonotwanttouseMTRRifPATisavailablebutthere+*aresomedriverswhichrequiresignificantworktogetthistowork+*properly.Thiscallshouldonlybeusedbythosedriverswhereitis+*clearthathardworkisrequiredtomodifythemtousearch_phys_wc_add()**Driversmuststorethereturnvaluetopasstomtrr_del_wc_if_needed,*butdriversshouldnottrytointerpretthatreturnvalue.*/-intarch_phys_wc_add(unsignedlongbase,unsignedlongsize)+int__arch_phys_wc_add(unsignedlongbase,unsignedlongsize){intret;-if(pat_enabled||!mtrr_enabled)-return0;/* Success! (We don't need to do anything.) */+if(!mtrr_enabled)+return0;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)}returnret+MTRR_TO_PHYS_WC_OFFSET;}+EXPORT_SYMBOL_GPL(__arch_phys_wc_add);++/**+*arch_phys_wc_add-addaWCMTRRandhandleerrorsifPATisunavailable+*@base:Physicalbaseaddress+*@size:Sizeofregion+*+*IfPATisavailable,thisdoesnothing.IfPATisunavailable,it+*attemptstoaddaWCMTRRcoveringsizebytesstartingatbaseand+*logsanerrorifthisfails.+*+*Driversmuststorethereturnvaluetopasstomtrr_del_wc_if_needed,+*butdriversshouldnottrytointerpretthatreturnvalue.+*/+intarch_phys_wc_add(unsignedlongbase,unsignedlongsize)+{+if(pat_enabled||!mtrr_enabled)+return0;/* Success! (We don't need to do anything.) */++return__arch_phys_wc_add(base,size);+}EXPORT_SYMBOL(arch_phys_wc_add);/*
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:36:24
From: "Luis R. Rodriguez" <redacted>
The size of the framebuffer to be used needs to
be fudged to account for the different type of
devices that are out there. This captures what
is required to do well, we'll resuse this later.
This has no functional changes.
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/atyfb_base.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:38:36
From: "Luis R. Rodriguez" <redacted>
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 0x800000.
atyfb_setup_generic() is *only* used on PCI probe.
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/atyfb_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:40:47
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 28 ++++++----------------------
2 files changed, 6 insertions(+), 23 deletions(-)
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)#ifdef CONFIG_MTRRpar->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+0x800000--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
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:43:01
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/atyfb.h | 4 +---
drivers/video/fbdev/aty/atyfb_base.c | 41 +++++++++---------------------------
2 files changed, 11 insertions(+), 34 deletions(-)
@@ -3840,10 +3823,8 @@ static int __init atyfb_setup(char *options)while((this_opt=strsep(&options,","))!=NULL){if(!strncmp(this_opt,"noaccel",7)){noaccel=1;-#ifdef CONFIG_MTRR}elseif(!strncmp(this_opt,"nomtrr",6)){nomtrr=1;-#endif}elseif(!strncmp(this_opt,"vram:",5))vram=simple_strtoul(this_opt+5,NULL,0);elseif(!strncmp(this_opt,"pll:",4))
@@ -4013,7 +3994,5 @@ module_param(comp_sync, int, 0);MODULE_PARM_DESC(comp_sync,"Set composite sync signal to low (0) or high (1)");module_param(mode,charp,0);MODULE_PARM_DESC(mode,"Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");-#ifdef CONFIG_MTRRmodule_param(nomtrr,bool,0);MODULE_PARM_DESC(nomtrr,"bool: disable use of MTRR registers");-#endif
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:45:12
From: "Luis R. Rodriguez" <redacted>
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/infiniband/hw/qib/qib_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -116,21 +116,9 @@ int qib_enable_wc(struct qib_devdata *dd)}if(!ret){-intcookie;--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=(unsignedlong)pioaddr;-dd->wc_len=(unsignedlong)piolen;-}+dd->wc_cookie=arch_phys_wc_add(pioaddr,piolen);+if(dd->wc_cookie<0)+ret=-EINVAL;}returnret;
@@ -142,18 +130,7 @@ int qib_enable_wc(struct qib_devdata *dd)*/voidqib_disable_wc(structqib_devdata*dd){-if(dd->wc_cookie){-intr;--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);}/**
From: Andy Lutomirski <luto@amacapital.net> Date: 2015-03-20 23:49:11
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
From: "Luis R. Rodriguez" <redacted>
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? If so, can we ioremap +
set_page_xyz instead?
--Andy
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:49:36
From: "Luis R. Rodriguez" <redacted>
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Andy Lutomirski <luto@amacapital.net> Date: 2015-03-20 23:50:16
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
From: "Luis R. Rodriguez" <redacted>
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
From: Andy Lutomirski <luto@amacapital.net> Date: 2015-03-20 23:50:59
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
quoted hunk
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/pci/pci.c | 14 ++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
@@ -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);
@@ -463,9 +463,7 @@ struct ipath_devdata {/* offset in HT config space of slave/primary interface block */u8ipath_ht_slave_off;/* for write combining settings */-unsignedlongipath_wc_cookie;-unsignedlongipath_wc_base;-unsignedlongipath_wc_len;+intwc_cookie;/* ref count for each pkey */atomic_tipath_pkeyrefs[4];/* shadow copy of struct page *'s for exp tid pages */
@@ -122,27 +121,26 @@ int ipath_enable_wc(struct ipath_devdata *dd)}if(!ret){-intcookie;ipath_cdbg(VERBOSE,"Setting mtrr for chip to WC ""(addr %llx, len=0x%llx)\n",(unsignedlonglong)pioaddr,(unsignedlonglong)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=(unsignedlong)pioaddr;-dd->ipath_wc_len=(unsignedlong)piolen;-}+dd->wc_cookie=__arch_phys_wc_add(pioaddr,piolen);+if(dd->wc_cookie<=0){+/*+*IfMTRRisnotavailableonanarchitecture+*orifitcouldnotbeenabledatruntime+*folkswhocareshouldworktowardsthe+*ioremap_wc()split.+*/+if(!dd->wc_cookie)+ipath_dev_err(dd,"System does not support MTRR\n");+else{+ipath_dev_err(dd,"Seting mtrr failed on PIO buffers\n");+ret=-EINVAL;+}+}else+ipath_cdbg(VERBOSE,"Set mtrr for chip to WC\n");}returnret;
@@ -154,16 +152,5 @@ int ipath_enable_wc(struct ipath_devdata *dd)*/voidipath_disable_wc(structipath_devdata*dd){-if(dd->ipath_wc_cookie){-intr;-ipath_cdbg(VERBOSE,"undoing WCCOMB on pio buffers\n");-r=mtrr_del(dd->ipath_wc_cookie,dd->ipath_wc_base,-dd->ipath_wc_len);-if(r<0)-dev_info(&dd->pcidev->dev,-"mtrr_del(%lx, %lx, %lx) failed: %d\n",-dd->ipath_wc_cookie,dd->ipath_wc_base,-dd->ipath_wc_len,r);-dd->ipath_wc_cookie=0;/* even on failure */-}+arch_phys_wc_del(dd->wc_cookie);}
From: Andy Lutomirski <luto@amacapital.net> Date: 2015-03-20 23:52:45
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
quoted hunk
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 28 ++++++----------------------
2 files changed, 6 insertions(+), 23 deletions(-)
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)#ifdef CONFIG_MTRRpar->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+0x800000--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
Double-check me, but I think that ioremap_nocache + WC MTRR = WC. I
think we might need ioremap_nocache_me_harder (or maybe ioremap_x86_uc
if you prefer that bikeshed color) for this.
@@ -155,12 +151,11 @@ struct osd_info {/* Buffer size */u32video_buffer_size;-#ifdef CONFIG_MTRR/* video_base rounded down as required by hardware MTRRs */unsignedlongfb_start_aligned_physaddr;/* video_base rounded up as required by hardware MTRRs */unsignedlongfb_end_aligned_physaddr;-#endif+intwc_cookie;/* Store the buffer offset */intset_osd_coords_x;
@@ -1099,6 +1094,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)staticintivtvfb_init_io(structivtv*itv){structosd_info*oi=itv->osd_info;+/* Find the largest power of two that maps the whole buffer */+intsize_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 */-intsize_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);
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:56:13
From: "Luis R. Rodriguez" <redacted>
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 <luto@amacapital.net>
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Nagalakshmi Nandigama <redacted>
Cc: Praveen Krishnamoorthy <redacted>
Cc: Sreekanth Reddy <redacted>
Cc: Abhijit Mahajan <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Tomi Valkeinen <redacted>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: MPT-FusionLinux.pdl@avagotech.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/message/fusion/mptbase.c | 19 ++++---------------
drivers/message/fusion/mptbase.h | 2 +-
2 files changed, 5 insertions(+), 16 deletions(-)
@@ -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&0xFFFFFFFF);-#if defined(CONFIG_MTRR) && 0+#if 0/**EnableWriteCombiningMTRRforIOC'smemoryregion.*(atleastasmuchaswecan;"size and base must be*multiplesof4kiB"*/-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);#endiffor(i=0;i<ioc->req_depth;i++){
@@ -671,7 +671,7 @@ typedef struct _MPT_ADAPTERu8*HostPageBuffer;/* SAS - host page buffer support */u32HostPageBuffer_sz;dma_addr_tHostPageBuffer_dma;-intmtrr_reg;+intwc_cookie;structpci_dev*pcidev;/* struct pci_dev pointer */intbars;/* bitmask of BAR's that must be configured */intmsi_enable;
From: Luis R. Rodriguez <hidden> Date: 2015-03-20 23:58:24
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/vesafb.c | 62 ++++++++++++--------------------------------
1 file changed, 16 insertions(+), 46 deletions(-)
@@ -404,60 +404,30 @@ static int vesafb_probe(struct platform_device *dev)*regionalready(FIXME)*/request_region(0x3c0,32,"vesafb");+if(mtrr=3){#ifdef CONFIG_MTRR-if(mtrr){unsignedinttemp_size=size_total;-unsignedinttype=0;+intrc;-switch(mtrr){-case1:-type=MTRR_TYPE_UNCACHABLE;-break;-case2:-type=MTRR_TYPE_WRBACK;-break;-case3:-type=MTRR_TYPE_WRCOMB;-break;-case4:-type=MTRR_TYPE_WRTHROUGH;-break;-default:-type=0;-break;-}--if(type){-intrc;--/* 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){-case1:/* uncachable */-info->screen_base=ioremap_nocache(vesafb_fix.smem_start,vesafb_fix.smem_len);-break;-case2:/* write-back */-info->screen_base=ioremap_cache(vesafb_fix.smem_start,vesafb_fix.smem_len);-break;-case3:/* write-combining */info->screen_base=ioremap_wc(vesafb_fix.smem_start,vesafb_fix.smem_len);-break;-case4:/* write-through */-default:+}else{+#ifdef CONFIG_MTRR+if(mtrr&&mtrr!=3)+WARN_ONCE(1,"Only MTRR_TYPE_WRCOMB (3) make sense\n");+#endifinfo->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",
@@ -228,6 +241,7 @@ static int vesafb_setup(char *options)staticintvesafb_probe(structplatform_device*dev){structfb_info*info;+structvesafb_par*par;inti,err;unsignedintsize_vmode;unsignedintsize_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_MTRRunsignedinttemp_size=size_total;-intrc;/* 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);#endifinfo->screen_base=ioremap_wc(vesafb_fix.smem_start,vesafb_fix.smem_len);}else{
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:02:49
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/vesafb.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
@@ -419,7 +412,6 @@ static int vesafb_probe(struct platform_device *dev)request_region(0x3c0,32,"vesafb");if(mtrr=3){-#ifdef CONFIG_MTRRunsignedinttemp_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_MTRRif(mtrr&&mtrr!=3)WARN_ONCE(1,"Only MTRR_TYPE_WRCOMB (3) make sense\n");-#endifinfo->screen_base=ioremap(vesafb_fix.smem_start,vesafb_fix.smem_len);}
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:05:00
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
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(-)
@@ -86,10 +85,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long end_pfn)staticinlinevoidmtrr_centaur_report_mcr(intmcr,u32lo,u32hi){}-staticinlineintphys_wc_to_mtrr_index(inthandle)-{-return-1;-}#define mtrr_ap_init() do {} while (0)#define mtrr_bp_init() do {} while (0)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:07:13
From: "Luis R. Rodriguez" <redacted>
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Hyong-Youb Kim <redacted>
Cc: netdev@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 36 ++++++------------------
1 file changed, 8 insertions(+), 28 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:09:24
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
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(-)
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*,struct pci_dev*);/* common var for all device */staticintg_hwcursor=1;staticintg_noaccel=0;-#ifdef CONFIG_MTRRstaticintg_nomtrr=0;-#endifstaticconstchar*g_fbmode[]={NULL,NULL};staticconstchar*g_def_fbmode="800x600-16@60";staticchar*g_settings=NULL;
@@ -1297,10 +1273,8 @@ static int __init lynxfb_setup(char * options)/* options that mean for any lynx chips are configured here */if(!strncmp(opt,"noaccel",strlen("noaccel")))g_noaccel=1;-#ifdef CONFIG_MTRRelseif(!strncmp(opt,"nomtrr",strlen("nomtrr")))g_nomtrr=1;-#endifelseif(!strncmp(opt,"dual",strlen("dual")))g_dualview=1;else
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:11:37
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/staging/xgifb/XGI_main_26.c | 27 ++++++---------------------
1 file changed, 6 insertions(+), 21 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:13:48
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/arkfb.c | 36 +++++-------------------------------
1 file changed, 5 insertions(+), 31 deletions(-)
@@ -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-structarkfb_info{intmclk_freq;-intmtrr_reg;+intwc_cookie;structdac_info*dac;structvgastatestate;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {staticchar*mode_option="640x480-8@60";-#ifdef CONFIG_MTRR-staticintmtrr=1;-#endif-MODULE_AUTHOR("(c) 2007 Ondrej Zajicek <santiago@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-staticintthreshold=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);return0;/* Error handling */
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:16:01
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/radeon_base.c | 29 ++++++-----------------------
drivers/video/fbdev/aty/radeonfb.h | 2 +-
2 files changed, 7 insertions(+), 24 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:20:25
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/gbefb.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
@@ -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*thishashighchancetofailonlowmemorymachines*/-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=(unsignedlong)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)return0;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)dma_free_coherent(NULL,gbe_mem_size,gbe_mem,gbe_mem_phys);out_tiles_free:
@@ -1265,10 +1256,7 @@ 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+arch_phys_wc_del(info->wc_cookie);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),
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:22:38
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/intelfb/intelfb.h | 4 +---
drivers/video/fbdev/intelfb/intelfbdrv.c | 38 ++++----------------------------
2 files changed, 5 insertions(+), 37 deletions(-)
@@ -285,9 +285,7 @@ struct intelfb_info {/* use a gart reserved fb mem */u8fbmem_gart;-/* mtrr support */-intmtrr_reg;-u32has_mtrr;+intwc_cookie;/* heap data */structintelfb_heap_dataaperture;
@@ -411,33 +407,6 @@ module_init(intelfb_init);module_exit(intelfb_exit);/***************************************************************-*mtrrsupportfunctions*-***************************************************************/--#ifdef CONFIG_MTRR-staticinlinevoidset_mtrr(structintelfb_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;-}-staticinlinevoidunset_mtrr(structintelfb_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 */--/****************************************************************driverinit/cleanup****************************************************************/
@@ -675,7 +644,7 @@ static int intelfb_pci_register(struct pci_dev *pdev,/* Allocate memories (which aren't stolen) *//* Map the fb and MMIO regions *//* ioremap only up to the end of used aperture */-dinfo->aperture.virtual=(u8__iomem*)ioremap_nocache+dinfo->aperture.virtual=(u8__iomem*)ioremap_wc(dinfo->aperture.physical,((offset+dinfo->fb.offset)<<12)+dinfo->fb.size);if(!dinfo->aperture.virtual){
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:24:49
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/matrox/matroxfb_base.c | 36 +++++++++++-------------------
drivers/video/fbdev/matrox/matroxfb_base.h | 27 +---------------------
2 files changed, 14 insertions(+), 49 deletions(-)
@@ -2515,10 +2507,8 @@ module_param(noinit, int, 0);MODULE_PARM_DESC(noinit,"Disables W/SG/SD-RAM and bus interface initialization (0 or 1=do not initialize) (default=0)");module_param(memtype,int,0);MODULE_PARM_DESC(memtype,"Memory type for G200/G400 (see Documentation/fb/matroxfb.txt for explanation) (default=3 for G200, 0 for G400)");-#ifdef CONFIG_MTRRmodule_param(mtrr,int,0);MODULE_PARM_DESC(mtrr,"This speeds up video memory accesses (0=disabled or 1) (default=1)");-#endifmodule_param(sgram,int,0);MODULE_PARM_DESC(sgram,"Indicates that G100/G200/G400 has SGRAM memory (0=SDRAM, 1=SGRAM) (default=0)");module_param(inv24,int,0);
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:27:01
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/neofb.c | 26 +++++++-------------------
include/video/neomagic.h | 5 +----
2 files changed, 8 insertions(+), 23 deletions(-)
@@ -1710,6 +1705,7 @@ static int neo_map_video(struct fb_info *info, struct pci_dev *dev,intvideo_len){//unsigned long addr;+structneofb_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-((structneofb_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);
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:29:14
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/s3fb.c | 35 ++++++-----------------------------
1 file changed, 6 insertions(+), 29 deletions(-)
@@ -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_MTRRmodule_param(mtrr,int,0444);MODULE_PARM_DESC(mtrr,"Enable write-combining with MTRR (1=enable, 0=disable, default=1)");-#endifmodule_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);return0;
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:31:26
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/nvidia/nv_type.h | 7 +------
drivers/video/fbdev/nvidia/nvidia.c | 37 ++++++------------------------------
2 files changed, 7 insertions(+), 37 deletions(-)
@@ -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_ERRPFX"unable to setup MTRR\n");-}else{-par->mtrr.vram_valid=1;-/* let there be speed */-printk(KERN_INFOPFX"MTRR set to ON\n");-}-}-#endif /* CONFIG_MTRR */+if(!nomtrr)+par->wc_cookie=arch_phys_wc_add(nvidiafb_fix.smem_start,+par->RamAmountKBytes*1024);info->fbops=&nvidia_fb_ops;info->fix=nvidiafb_fix;
@@ -1505,10 +1484,8 @@ static int nvidiafb_setup(char *options)vram=simple_strtoul(this_opt+5,NULL,0);}elseif(!strncmp(this_opt,"backlight:",10)){backlight=simple_strtoul(this_opt+10,NULL,0);-#ifdef CONFIG_MTRR}elseif(!strncmp(this_opt,"nomtrr",6)){nomtrr=true;-#endif}elseif(!strncmp(this_opt,"fpdither:",9)){fpdither=simple_strtol(this_opt+9,NULL,0);}elseif(!strncmp(this_opt,"bpp:",4)){
@@ -1596,11 +1573,9 @@ MODULE_PARM_DESC(bpp, "pixel width in bits""(default=8)");module_param(reverse_i2c,int,0);MODULE_PARM_DESC(reverse_i2c,"reverse port assignment of the i2c bus");-#ifdef CONFIG_MTRRmodule_param(nomtrr,bool,false);MODULE_PARM_DESC(nomtrr,"Disables MTRR support (0 or 1=disabled) ""(default=0)");-#endifMODULE_AUTHOR("Antonino Daplas");MODULE_DESCRIPTION("Framebuffer driver for nVidia graphics chipset");
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:33:38
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/savage/savagefb.h | 4 +---
drivers/video/fbdev/savage/savagefb_driver.c | 17 +++--------------
2 files changed, 4 insertions(+), 17 deletions(-)
@@ -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);
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:35:50
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/sis/sis.h | 2 +-
drivers/video/fbdev/sis/sis_main.c | 27 ++++++---------------------
2 files changed, 7 insertions(+), 22 deletions(-)
@@ -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)gotoerror_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");
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:38:03
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/aty/aty128fb.c | 36 ++++++------------------------------
1 file changed, 6 insertions(+), 30 deletions(-)
@@ -456,9 +449,7 @@ struct aty128fb_par {u32vram_size;/* onboard video ram */intchip_gen;conststructaty128_meminfo*mem;/* onboard mem info */-#ifdef CONFIG_MTRR-struct{intvram;intvram_valid;}mtrr;-#endif+intwc_cookie;intblitter_may_be_busy;intfifo_slots;/* free slots in FIFO (64 max) */
@@ -1725,12 +1716,10 @@ static int aty128fb_setup(char *options)#endifcontinue;}-#ifdef CONFIG_MTRRif(!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)&0x03FFFFFF;/* 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)gotoerr_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))gotoerr_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");-}-#endif /* CONFIG_MTRR */+if(mtrr)+par->wc_cookie=arch_phys_wc_add(info->fix.smem_start,+par->vram_size);return0;err_out:
@@ -2625,8 +2604,5 @@ MODULE_DESCRIPTION("FBDev driver for ATI Rage128 / Pro cards");MODULE_LICENSE("GPL");module_param(mode_option,charp,0);MODULE_PARM_DESC(mode_option,"Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");-#ifdef CONFIG_MTRRmodule_param_named(nomtrr,mtrr,invbool,0);MODULE_PARM_DESC(nomtrr,"bool: Disable MTRR support (0 or 1=disabled) (default=0)");-#endif-
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:40:14
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
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(-)
@@ -60,32 +60,6 @@ static inline void flush_cache(void)#define flush_cache() do { } while(0)#endif -#ifdef CONFIG_MTRR--#include<asm/mtrr.h>--staticinlinevoidset_mtrr(structi810fb_par*par)-{-par->mtrr_reg=mtrr_add((u32)par->aperture.physical,-par->aperture.size,MTRR_TYPE_WRCOMB,1);-if(par->mtrr_reg<0){-printk(KERN_ERR"set_mtrr: unable to set MTRR\n");-return;-}-par->dev_flags|=HAS_MTRR;-}-staticinlinevoidunset_mtrr(structi810fb_par*par)-{-if(par->dev_flags&HAS_MTRR)-mtrr_del(par->mtrr_reg,(u32)par->aperture.physical,-par->aperture.size);-}-#else-#define set_mtrr(x) printk("set_mtrr: MTRR is disabled in the kernel\n")--#define unset_mtrr(x) do { } while (0)-#endif /* CONFIG_MTRR */-#ifdef CONFIG_FB_I810_GTF#define IS_DVT (0)#else
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:42:26
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/i740fb.c | 35 ++++++-----------------------------
1 file changed, 6 insertions(+), 29 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:44:38
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/kyro/fbdev.c | 33 +++++++++++----------------------
include/video/kyro.h | 4 +---
2 files changed, 12 insertions(+), 25 deletions(-)
@@ -35,9 +35,7 @@ struct kyrofb_info {/* Useful to hold depth here for Linux */u8PIXDEPTH;-#ifdef CONFIG_MTRR-intmtrr_handle;-#endif+intwc_cookie;};externintkyro_dev_init(void);
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:46:50
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/pm2fb.c | 31 +++++--------------------------
1 file changed, 5 insertions(+), 26 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:49:02
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/pm3fb.c | 30 ++++++------------------------
1 file changed, 6 insertions(+), 24 deletions(-)
@@ -76,7 +69,7 @@ struct pm3_par {u32video;/* video flags before blanking */u32base;/* screen base in 128 bits unit */u32palette[16];-intmtrr_handle;+intwc_cookie;};/*
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:51:14
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/riva/fbdev.c | 39 +++++++--------------------------------
drivers/video/fbdev/riva/rivafb.h | 4 +---
2 files changed, 8 insertions(+), 35 deletions(-)
@@ -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_ERRPFX"cannot ioremap FB base\n");ret=-EIO;gotoerr_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_ERRPFX"unable to setup MTRR\n");-}else{-default_par->mtrr.vram_valid=1;-/* let there be speed */-printk(KERN_INFOPFX"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;
@@ -2153,10 +2132,8 @@ static int rivafb_setup(char *options)flatpanel=1;}elseif(!strncmp(this_opt,"backlight:",10)){backlight=simple_strtoul(this_opt+10,NULL,0);-#ifdef CONFIG_MTRR}elseif(!strncmp(this_opt,"nomtrr",6)){nomtrr=1;-#endif}elseif(!strncmp(this_opt,"strictmode",10)){strictmode=1;}elseif(!strncmp(this_opt,"noaccel",7)){
@@ -2212,10 +2189,8 @@ module_param(flatpanel, int, 0);MODULE_PARM_DESC(flatpanel,"Enables experimental flat panel support for some chipsets. (0 or 1=enabled) (default=0)");module_param(forceCRTC,int,0);MODULE_PARM_DESC(forceCRTC,"Forces usage of a particular CRTC in case autodetection fails. (0 or 1) (default=autodetect)");-#ifdef CONFIG_MTRRmodule_param(nomtrr,bool,0);MODULE_PARM_DESC(nomtrr,"Disables MTRR support (0 or 1=disabled) (default=0)");-#endifmodule_param(strictmode,bool,0);MODULE_PARM_DESC(strictmode,"Only use video modes from EDID");
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:53:26
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/tdfxfb.c | 41 ++++++-----------------------------------
include/video/tdfx.h | 2 +-
2 files changed, 7 insertions(+), 36 deletions(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:55:38
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/vt8623fb.c | 31 ++++++-------------------------
1 file changed, 6 insertions(+), 25 deletions(-)
@@ -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_MTRRmodule_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,+info->fix.smem_len);return0;
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 00:57:50
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/atmel_lcdfb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 01:00:04
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/geode/gxfb_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 01:02:15
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Luis R. Rodriguez <hidden> Date: 2015-03-21 01:04:28
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
arch/x86/kernel/cpu/mtrr/main.c | 2 --
1 file changed, 2 deletions(-)
@@ -446,7 +446,6 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type,returnmtrr_add_page(base>>PAGE_SHIFT,size>>PAGE_SHIFT,type,increment);}-EXPORT_SYMBOL(mtrr_add);/***mtrr_del_page-deleteamemorytyperegion
@@ -535,7 +534,6 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)return-EINVAL;returnmtrr_del_page(reg,base>>PAGE_SHIFT,size>>PAGE_SHIFT);}-EXPORT_SYMBOL(mtrr_del);/***__arch_phys_wc_add-addaWCMTRRevenifPATisavailable
From: Andy Lutomirski <luto@amacapital.net> Date: 2015-03-21 01:09:03
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
From: "Luis R. Rodriguez" <redacted>
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)
From: Hyong-Youb Kim <hidden> Date: 2015-03-21 07:23:00
On Fri, Mar 20, 2015 at 04:18:11PM -0700, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez" <redacted>
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Luis,
This seems OK to me, but I'm curious about a few things.
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
From: "Luis R. Rodriguez" <redacted>
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?
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*.
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);
Is there a reason not to do that?
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 len = pci_resource_len(dev, bar);
+ unsigned long flags = pci_resource_flags(dev, bar);
+
+ if (len <= offset || !start)
+ return NULL;
+ len -= offset;
+ start += offset;
+ if (maxlen && len > maxlen)
+ len = maxlen;
+ if (flags & IORESOURCE_IO)
+ return __pci_ioport_map(dev, start, len);
+ if (flags & IORESOURCE_MEM)
Should we log a note in dmesg if the BAR is *not* IORESOURCE_PREFETCH?
I know the driver might know it's safe even if the device didn't mark
the BAR as prefetchable, but it does seem like an easy way for a
driver to shoot itself in the foot.
From: Luis R. Rodriguez <hidden> Date: 2015-03-25 19:51:04
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
[off-list ref] wrote:
quoted
From: "Luis R. Rodriguez" <redacted>
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
From: Konrad Rzeszutek Wilk <hidden> Date: 2015-03-25 20:03:02
On Fri, Mar 20, 2015 at 04:17:52PM -0700, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez" <redacted>
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/ ?
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.
s/3.19/4.0/
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?
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/
quoted hunk
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 <luto@amacapital.net>
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: venkatesh.pallipadi@intel.com
Cc: Stefan Bader <redacted>
Cc: konrad.wilk@oracle.com
Cc: ville.syrjala@linux.intel.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: toshi.kani@hp.com
Cc: bhelgaas@google.com
Cc: Roger Pau Monné <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: Luis R. Rodriguez <redacted>
---
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(-)
@@ -50,6 +51,7 @@ extern int mtrr_trim_uncached_memory(unsigned long end_pfn);externintamd_special_default_mtrr(void);externintphys_wc_to_mtrr_index(inthandle);# else+staticconstintmtrr_enabled;staticinlineu8mtrr_type_lookup(u64addr,u64end){/*
@@ -880,7 +880,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)*Makesureweonlytrimuncachablememoryonmachinesthat*supporttheIntelMTRRarchitecture:*/-if(!is_cpu(INTEL)||disable_mtrr_trim)+if(!is_cpu(INTEL)||disable_mtrr_trim||!mtrr_enabled)return0;rdmsr(MSR_MTRRdefType,def,dummy);
@@ -116,7 +116,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)u8prev_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)return0xFF;if(!mtrr_state.enabled)
@@ -84,6 +85,9 @@ static int have_wrcomb(void){structpci_dev*dev;+if(!mtrr_enabled)+return0;+dev=pci_get_class(PCI_CLASS_BRIDGE_HOST<<8,NULL);if(dev!=NULL){/*
@@ -286,7 +290,7 @@ int mtrr_add_page(unsigned long base, unsigned long size,inti,replace,error;mtrr_typeltype;-if(!mtrr_if)+if(!mtrr_enabled)return-ENXIO;error=mtrr_if->validate_add_page(base,size,type);
@@ -388,6 +392,8 @@ int mtrr_add_page(unsigned long base, unsigned long size,staticintmtrr_check(unsignedlongbase,unsignedlongsize){+if(!mtrr_enabled)+return-ENODEV;if((base&(PAGE_SIZE-1))||(size&(PAGE_SIZE-1))){pr_warning("mtrr: size and base must be multiples of 4 kiB\n");pr_debug("mtrr: size: 0x%lx base: 0x%lx\n",size,base);
@@ -463,8 +469,8 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)unsignedlonglbase,lsize;interror=-EINVAL;-if(!mtrr_if)-return-ENXIO;+if(!mtrr_enabled)+return-ENODEV;max=num_var_ranges;/* No CPU hotplug when we change MTRR entries */
@@ -523,6 +529,8 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)*/intmtrr_del(intreg,unsignedlongbase,unsignedlongsize){+if(!mtrr_enabled)+return-ENODEV;if(mtrr_check(base,size))return-EINVAL;returnmtrr_del_page(reg,base>>PAGE_SHIFT,size>>PAGE_SHIFT);
@@ -545,7 +553,7 @@ int arch_phys_wc_add(unsigned long base, unsigned long size){intret;-if(pat_enabled)+if(pat_enabled||!mtrr_enabled)return0;/* Success! (We don't need to do anything.) */ret=mtrr_add(base,size,MTRR_TYPE_WRCOMB,true);
@@ -744,12 +753,13 @@ void __init mtrr_bp_init(void)mtrr_if->set_all();}}-}+}else+pr_info("mtrr: system does not support MTRR\n");
'pr_warn' ?
quoted hunk
}
void mtrr_ap_init(void)
{
- if (!use_intel() || mtrr_aps_delayed_init)
+ if (!use_intel() || mtrr_aps_delayed_init || !mtrr_enabled)
return;
/*
* Ideally we should hold mtrr_mutex here to avoid mtrr entries
@@ -774,6 +784,9 @@ void mtrr_save_state(void) { int first_cpu;+ if (!mtrr_enabled)+ return;+ get_online_cpus(); first_cpu = cpumask_first(cpu_online_mask); smp_call_function_single(first_cpu, mtrr_save_fixed_ranges, NULL, 1);
@@ -782,7 +795,7 @@ void mtrr_save_state(void) void set_mtrr_aps_delayed_init(void) {- if (!use_intel())+ if (!use_intel() || !mtrr_enabled) return; mtrr_aps_delayed_init = true;
@@ -810,7 +823,7 @@ void mtrr_aps_init(void) void mtrr_bp_restore(void) {- if (!use_intel())+ if (!use_intel() || !mtrr_enabled) return; mtrr_if->set_all();
@@ -818,7 +831,7 @@ void mtrr_bp_restore(void) static int __init mtrr_init_finialize(void) {- if (!mtrr_if)+ if (!mtrr_enabled) return 0; if (use_intel()) {
From: Konrad Rzeszutek Wilk <hidden> Date: 2015-03-25 20:04:33
On Fri, Mar 20, 2015 at 04:17:54PM -0700, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez" <redacted>
This lets drivers take advanate of PAT when available. This
s/advanate/advantage/
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()"
quoted hunk
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/pci/pci.c | 14 ++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
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.
From: Luis R. Rodriguez <hidden> Date: 2015-03-25 20:06:41
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
[off-list ref] wrote:
quoted
From: "Luis R. Rodriguez" <redacted>
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 <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/pci/pci.c | 14 ++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
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
From: Konrad Rzeszutek Wilk <hidden> Date: 2015-03-25 20:11:07
On Fri, Mar 20, 2015 at 04:17:55PM -0700, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez" <redacted>
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?
quoted hunk
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 <luto@amacapital.net>
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: venkatesh.pallipadi@intel.com
Cc: Stefan Bader <redacted>
Cc: konrad.wilk@oracle.com
Cc: ville.syrjala@linux.intel.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: toshi.kani@hp.com
Cc: Roger Pau Monné <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: Luis R. Rodriguez <redacted>
---
include/asm-generic/pci_iomap.h | 14 ++++++++++
lib/pci_iomap.c | 61 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+)
@@ -15,9 +15,13 @@ struct pci_dev;#ifdef CONFIG_PCI/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */externvoid__iomem*pci_iomap(structpci_dev*dev,intbar,unsignedlongmax);+externvoid__iomem*pci_iomap_wc(structpci_dev*dev,intbar,unsignedlongmax);externvoid__iomem*pci_iomap_range(structpci_dev*dev,intbar,unsignedlongoffset,unsignedlongmaxlen);+externvoid__iomem*pci_iomap_wc_range(structpci_dev*dev,intbar,+unsignedlongoffset,+unsignedlongmaxlen);/* Create a virtual mapping cookie for a port on a given PCI device.*Donotcallthisdirectly,itexiststomakeiteasierforarchitectures*tooverride*/
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned lonreturnNULL;}+staticinlinevoid__iomem*pci_iomap_wc(structpci_dev*dev,intbar,unsignedlongmax)+{+returnNULL;+}staticinlinevoid__iomem*pci_iomap_range(structpci_dev*dev,intbar,unsignedlongoffset,unsignedlongmaxlen){returnNULL;}+staticinlinevoid__iomem*pci_iomap_wc_range(structpci_dev*dev,intbar,+unsignedlongoffset,+unsignedlongmaxlen)+{+returnNULL;+}#endif#endif /* __ASM_GENERIC_IO_H */
+ * */
+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 len = pci_resource_len(dev, bar);
+ unsigned long flags = pci_resource_flags(dev, bar);
+
+ if (len <= offset || !start)
+ return NULL;
+ len -= offset;
+ start += offset;
+ if (maxlen && len > maxlen)
+ len = maxlen;
+ if (flags & IORESOURCE_IO)
+ return __pci_ioport_map(dev, start, len);
+ if (flags & IORESOURCE_MEM)
+ return ioremap_wc(start, len);
+ /* What? */
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(pci_iomap_wc_range);
+
+/**
* pci_iomap - create a virtual mapping cookie for a PCI BAR
* @dev: PCI device that owns the BAR
* @bar: BAR number
@@ -70,4 +110,25 @@ void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen) return pci_iomap_range(dev, bar, 0, maxlen); } EXPORT_SYMBOL(pci_iomap);++/**+ * pci_iomap_wc - create a virtual WC mapping cookie for a PCI BAR+ * @dev: PCI device that owns the BAR+ * @bar: BAR number+ * @maxlen: 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 without checking for its length first, pass %0 here.+ * */+void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long maxlen)+{+ return pci_iomap_wc_range(dev, bar, 0, maxlen);+}+EXPORT_SYMBOL_GPL(pci_iomap_wc); #endif /* CONFIG_PCI */
From: Luis R. Rodriguez <hidden> Date: 2015-03-25 20:39:24
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:
quoted
From: "Luis R. Rodriguez" <redacted>
This lets drivers take advanate of PAT when available. This
s/advanate/advantage/
Amended.
quoted
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.
quoted
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <redacted>
---
drivers/pci/pci.c | 14 ++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
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
From: Luis R. Rodriguez <hidden> Date: 2015-03-26 03:01:10
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
[off-list ref] wrote:
quoted
From: "Luis R. Rodriguez" <redacted>
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.
quoted
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_PREFETCH 0x08 /* 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?
quoted
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)
...
quoted
+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 len = pci_resource_len(dev, bar);
+ unsigned long flags = pci_resource_flags(dev, bar);
+
+ if (len <= offset || !start)
+ return NULL;
+ len -= offset;
+ start += offset;
+ if (maxlen && len > maxlen)
+ len = maxlen;
+ if (flags & IORESOURCE_IO)
+ return __pci_ioport_map(dev, start, len);
+ if (flags & IORESOURCE_MEM)
Should we log a note in dmesg if the BAR is *not* IORESOURCE_PREFETCH?
I know the driver might know it's safe even if the device didn't mark
the BAR as prefetchable, but it does seem like an easy way for a
driver to shoot itself in the foot.
You tell me. I would fear this may not be consistent and we'd end up
having bug reports open for something that has historically been a
non-issue. The above questions can help us gauge the risk of this.
Luis
On 03/25/2015 08:59 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 20, 2015 at 04:17:52PM -0700, Luis R. Rodriguez wrote:
quoted
From: "Luis R. Rodriguez" <redacted>
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/ ?
quoted
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.
s/3.19/4.0/
No, 3.19 is correct.
Juergen
quoted
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?
quoted
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/
quoted
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 <luto@amacapital.net>
Cc: Suresh Siddha <redacted>
Cc: Venkatesh Pallipadi <redacted>
Cc: Ingo Molnar <redacted>
Cc: Thomas Gleixner <redacted>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <redacted>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <redacted>
Cc: Tomi Valkeinen <redacted>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: venkatesh.pallipadi@intel.com
Cc: Stefan Bader <redacted>
Cc: konrad.wilk@oracle.com
Cc: ville.syrjala@linux.intel.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: toshi.kani@hp.com
Cc: bhelgaas@google.com
Cc: Roger Pau Monné <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: Luis R. Rodriguez <redacted>
---
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(-)
@@ -50,6 +51,7 @@ extern int mtrr_trim_uncached_memory(unsigned long end_pfn);externintamd_special_default_mtrr(void);externintphys_wc_to_mtrr_index(inthandle);# else+staticconstintmtrr_enabled;staticinlineu8mtrr_type_lookup(u64addr,u64end){/*
@@ -880,7 +880,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)*Makesureweonlytrimuncachablememoryonmachinesthat*supporttheIntelMTRRarchitecture:*/-if(!is_cpu(INTEL)||disable_mtrr_trim)+if(!is_cpu(INTEL)||disable_mtrr_trim||!mtrr_enabled)return0;rdmsr(MSR_MTRRdefType,def,dummy);
@@ -116,7 +116,8 @@ static u8 __mtrr_type_lookup(u64 start, u64 end, u64 *partial_end, int *repeat)u8prev_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)return0xFF;if(!mtrr_state.enabled)
@@ -84,6 +85,9 @@ static int have_wrcomb(void){structpci_dev*dev;+if(!mtrr_enabled)+return0;+dev=pci_get_class(PCI_CLASS_BRIDGE_HOST<<8,NULL);if(dev!=NULL){/*
@@ -286,7 +290,7 @@ int mtrr_add_page(unsigned long base, unsigned long size,inti,replace,error;mtrr_typeltype;-if(!mtrr_if)+if(!mtrr_enabled)return-ENXIO;error=mtrr_if->validate_add_page(base,size,type);
@@ -388,6 +392,8 @@ int mtrr_add_page(unsigned long base, unsigned long size,staticintmtrr_check(unsignedlongbase,unsignedlongsize){+if(!mtrr_enabled)+return-ENODEV;if((base&(PAGE_SIZE-1))||(size&(PAGE_SIZE-1))){pr_warning("mtrr: size and base must be multiples of 4 kiB\n");pr_debug("mtrr: size: 0x%lx base: 0x%lx\n",size,base);
@@ -463,8 +469,8 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)unsignedlonglbase,lsize;interror=-EINVAL;-if(!mtrr_if)-return-ENXIO;+if(!mtrr_enabled)+return-ENODEV;max=num_var_ranges;/* No CPU hotplug when we change MTRR entries */
@@ -523,6 +529,8 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)*/intmtrr_del(intreg,unsignedlongbase,unsignedlongsize){+if(!mtrr_enabled)+return-ENODEV;if(mtrr_check(base,size))return-EINVAL;returnmtrr_del_page(reg,base>>PAGE_SHIFT,size>>PAGE_SHIFT);
@@ -545,7 +553,7 @@ int arch_phys_wc_add(unsigned long base, unsigned long size){intret;-if(pat_enabled)+if(pat_enabled||!mtrr_enabled)return0;/* Success! (We don't need to do anything.) */ret=mtrr_add(base,size,MTRR_TYPE_WRCOMB,true);
@@ -744,12 +753,13 @@ void __init mtrr_bp_init(void)mtrr_if->set_all();}}-}+}else+pr_info("mtrr: system does not support MTRR\n");
'pr_warn' ?
quoted
}
void mtrr_ap_init(void)
{
- if (!use_intel() || mtrr_aps_delayed_init)
+ if (!use_intel() || mtrr_aps_delayed_init || !mtrr_enabled)
return;
/*
* Ideally we should hold mtrr_mutex here to avoid mtrr entries
@@ -774,6 +784,9 @@ void mtrr_save_state(void) { int first_cpu;+ if (!mtrr_enabled)+ return;+ get_online_cpus(); first_cpu = cpumask_first(cpu_online_mask); smp_call_function_single(first_cpu, mtrr_save_fixed_ranges, NULL, 1);
@@ -782,7 +795,7 @@ void mtrr_save_state(void) void set_mtrr_aps_delayed_init(void) {- if (!use_intel())+ if (!use_intel() || !mtrr_enabled) return; mtrr_aps_delayed_init = true;
@@ -810,7 +823,7 @@ void mtrr_aps_init(void) void mtrr_bp_restore(void) {- if (!use_intel())+ if (!use_intel() || !mtrr_enabled) return; mtrr_if->set_all();
@@ -818,7 +831,7 @@ void mtrr_bp_restore(void) static int __init mtrr_init_finialize(void) {- if (!mtrr_if)+ if (!mtrr_enabled) return 0; if (use_intel()) {--
From: Luis R. Rodriguez <hidden> Date: 2015-03-26 23:36:03
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:
quoted
From: "Luis R. Rodriguez" <redacted>
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.
quoted
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.
quoted
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/
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Luis R. Rodriguez <hidden> Date: 2015-03-27 18:40:34
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:
quoted
From: "Luis R. Rodriguez" <redacted>
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
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
On Mon, 2015-03-23 at 12:20 -0500, Bjorn Helgaas wrote:
:
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);
Is this supposed to be ioremap_cache()? ioremap() is the same as
ioremap_nocache() at least on x86 per arch/x86/include/asm/io.h.
if (flags & IORESOURCE_PREFETCH)
return ioremap_wc(start, len);
return ioremap_nocache(start, len);
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)#ifdef CONFIG_MTRRpar->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
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)#ifdef CONFIG_MTRRpar->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.
--Andy
---
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
From: Luis R. Rodriguez <hidden> Date: 2015-03-27 19:53:58
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
[off-list ref] wrote:
quoted
From: "Luis R. Rodriguez" <redacted>
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
ivtv drivers/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
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)#ifdef CONFIG_MTRRpar->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
From: Andy Lutomirski <luto@amacapital.net> Date: 2015-03-27 19:58:30
On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez [off-list ref] wrote:
On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote:
quoted
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
[off-list ref] wrote:
quoted
From: "Luis R. Rodriguez" <redacted>
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
ivtv drivers/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.
quoted
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.)
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)#ifdef CONFIG_MTRRpar->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+0x800000--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
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