From: "Luis R. Rodriguez" <[email protected]>
This series addresses one commend fix on the table for mtrr_add()
effect on the PAT case when UC- is used. Other than that it is
the same as v4.
Luis R. Rodriguez (6):
x86: add ioremap_uc() - force strong UC, PCD=1, PWT=1
x86: document WC MTRR effects on PAT / non-PAT pages
video: fbdev: atyfb: move framebuffer length fudging to helper
video: fbdev: atyfb: clarify ioremap() base and length used
video: fbdev: atyfb: replace MTRR UC hole with strong UC
video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
Documentation/x86/mtrr.txt | 18 +++++--
Documentation/x86/pat.txt | 40 ++++++++++++++-
arch/x86/include/asm/io.h | 1 +
arch/x86/kernel/cpu/mtrr/main.c | 3 ++
arch/x86/mm/ioremap.c | 36 ++++++++++++-
arch/x86/mm/pageattr.c | 3 ++
drivers/video/fbdev/aty/atyfb.h | 5 +-
drivers/video/fbdev/aty/atyfb_base.c | 98 ++++++++++++++----------------------
include/asm-generic/io.h | 8 +++
9 files changed, 143 insertions(+), 69 deletions(-)
--
2.3.2.209.gd67f9d5.dirty
From: "Luis R. Rodriguez" <[email protected]>
ioremap_nocache() currently uses UC- by default.
Our goal is to eventually make UC the default.
Linux maps UC- to PCD=1, PWT=0 page attributes on
non-PAT systems. Linux maps UC to PCD=1, PWT=1
page attributes on non-PAT systems. On non-PAT
and PAT systems a WC MTRR has different effects on
pages with either of these attributes. In order to
help with a smooth transition its best to enable
use of UC (PCD,1, PWT=1) on a region as that ensures
a WC MTRR will have no effect on a region, this
however requires us to have an way to declare a
region as UC and we currently do not have a way
to do this.
WC MTRR on non-PAT system with PCD=1, PWT=0 (UC-) yields WC.
WC MTRR on non-PAT system with PCD=1, PWT=1 (UC) yields UC.
WC MTRR on PAT system with PCD=1, PWT=0 (UC-) yields WC.
WC MTRR on PAT system with PCD=1, PWT=1 (UC) yields UC.
A flip of the default ioremap_nocache() behaviour
from UC- to UC can therefore regress a memory
region from effective memory type WC to UC if MTRRs
are used. Use of MTRRs should be phased out and in
the best case only arch_phys_wc_add() use will remain,
even if this happens arch_phys_wc_add() will have an
effect on non-PAT systems and changes to default
ioremap_nocache() behaviour could regress drivers.
Now, ideally we'd use ioremap_nocache() on the regions
in which we'd need uncachable memory types and avoid
any MTRRs on those regions. There are however some
restrictions on MTRRs use, such as the requirement of
having the base and size of variable sized MTRRs
to be powers of two, which could mean having to use
a WC MTRR over a large area which includes a region
in which write-combining effects are undesirable.
Add ioremap_uc() to help with the both phasing out of
MTRR use and also provide a way to blacklist small
WC undesirable regions in devices with mixed regions
which are size-implicated to use large WC MTRRs. Use
of ioremap_uc() helps phase out MTRR use by avoiding
regressions with an eventual flip of default behaviour
or ioremap_nocache() from UC- to UC.
Drivers working with WC MTRRs can use the below table
to review and consider the use of ioremap*() and similar
helpers to ensure appropriate behaviour long term even
if default ioremap_nocache() behaviour changes from UC-
to UC.
Although ioremap_uc() is being added we leave set_memory_uc()
to use UC- as only initial memory type setup is required
to be able to accomodate existing device drivers and phase
out MTRR use. It should also be clarified that set_memory_uc()
cannot be used with IO memory, even though its use will
not return any errors, it really has no effect.
----------------------------------------------------------------------
MTRR Non-PAT PAT Linux ioremap value Effective memory type
----------------------------------------------------------------------
Non-PAT | PAT
PAT
|PCD
||PWT
|||
WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
----------------------------------------------------------------------
Cc: Toshi Kani <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Mike Travis <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
arch/x86/include/asm/io.h | 1 +
arch/x86/mm/ioremap.c | 36 +++++++++++++++++++++++++++++++++++-
arch/x86/mm/pageattr.c | 3 +++
include/asm-generic/io.h | 8 ++++++++
4 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 34a5b93..4afc05f 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -177,6 +177,7 @@ static inline unsigned int isa_virt_to_bus(volatile void *address)
* look at pci_iomap().
*/
extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long size);
+extern void __iomem *ioremap_uc(resource_size_t offset, unsigned long size);
extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);
extern void __iomem *ioremap_prot(resource_size_t offset, unsigned long size,
unsigned long prot_val);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 70e7444..a493bb8 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -237,7 +237,8 @@ void __iomem *ioremap_nocache(resource_size_t phys_addr, unsigned long size)
* pat_enabled ? _PAGE_CACHE_MODE_UC : _PAGE_CACHE_MODE_UC_MINUS;
*
* Till we fix all X drivers to use ioremap_wc(), we will use
- * UC MINUS.
+ * UC MINUS. Drivers that are certain they need or can already
+ * be converted over to strong UC can use ioremap_uc().
*/
enum page_cache_mode pcm = _PAGE_CACHE_MODE_UC_MINUS;
@@ -247,6 +248,39 @@ void __iomem *ioremap_nocache(resource_size_t phys_addr, unsigned long size)
EXPORT_SYMBOL(ioremap_nocache);
/**
+ * ioremap_uc - map bus memory into CPU space as strongly uncachable
+ * @phys_addr: bus address of the memory
+ * @size: size of the resource to map
+ *
+ * ioremap_uc performs a platform specific sequence of operations to
+ * make bus memory CPU accessible via the readb/readw/readl/writeb/
+ * writew/writel functions and the other mmio helpers. The returned
+ * address is not guaranteed to be usable directly as a virtual
+ * address.
+ *
+ * This version of ioremap ensures that the memory is marked with a strong
+ * preference as completely uncachable on the CPU when possible. For non-PAT
+ * systems this ends up setting page-attribute flags PCD=1, PWT=1. For PAT
+ * systems this will set the PAT entry for the pages as strong UC. This call
+ * will honor existing caching rules from things like the PCI bus. Note that
+ * there are other caches and buffers on many busses. In particular driver
+ * authors should read up on PCI writes.
+ *
+ * It's useful if some control registers are in such an area and
+ * write combining or read caching is not desirable:
+ *
+ * Must be freed with iounmap.
+ */
+void __iomem *ioremap_uc(resource_size_t phys_addr, unsigned long size)
+{
+ enum page_cache_mode pcm = _PAGE_CACHE_MODE_UC;
+
+ return __ioremap_caller(phys_addr, size, pcm,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL_GPL(ioremap_uc);
+
+/**
* ioremap_wc - map memory into CPU space write combined
* @phys_addr: bus address of the memory
* @size: size of the resource to map
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 89af288..49660c0 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1468,6 +1468,9 @@ int _set_memory_uc(unsigned long addr, int numpages)
{
/*
* for now UC MINUS. see comments in ioremap_nocache()
+ * If you really need strong UC use ioremap_uc(), but note
+ * that you cannot override IO areas with set_memory_*() as
+ * these helpers cannot work with IO memory.
*/
return change_page_attr_set(&addr, numpages,
cachemode2pgprot(_PAGE_CACHE_MODE_UC_MINUS),
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 9db0423..90ccba7 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -769,6 +769,14 @@ static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
}
#endif
+#ifndef ioremap_uc
+#define ioremap_uc ioremap_uc
+static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
+{
+ return ioremap_nocache(offset, size);
+}
+#endif
+
#ifndef ioremap_wc
#define ioremap_wc ioremap_wc
static inline void __iomem *ioremap_wc(phys_addr_t offset, size_t size)
--
2.3.2.209.gd67f9d5.dirty
From: "Luis R. Rodriguez" <[email protected]>
As part of the effort to phase out MTRR use document
write-combining MTRR effects on pages with different
non-PAT page attributes flags and different PAT entry
values. Extend arch_phys_wc_add() documentation to
clarify power of two sizes / boundary requirements as
we phase out mtrr_add() use.
Lastly hint towards ioremap_uc() for corner cases on
device drivers working with devices with mixed regions
where MTRR size requirements would otherwise not
enable write-combining effective memory types.
Cc: Toshi Kani <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
Documentation/x86/mtrr.txt | 18 +++++++++++++++---
Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
arch/x86/kernel/cpu/mtrr/main.c | 3 +++
3 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
index cc071dc..a111a6c 100644
--- a/Documentation/x86/mtrr.txt
+++ b/Documentation/x86/mtrr.txt
@@ -1,7 +1,19 @@
MTRR (Memory Type Range Register) control
-3 Jun 1999
-Richard Gooch
-<[email protected]>
+
+Richard Gooch <[email protected]> - 3 Jun 1999
+Luis R. Rodriguez <[email protected]> - April 9, 2015
+
+===============================================================================
+Phasing MTRR use
+
+MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
+of effective MTRR that is expected to be supported will be for write-combining.
+As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
+MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
+
+For details refer to Documentation/x86/pat.txt.
+
+===============================================================================
On Intel P6 family processors (Pentium Pro, Pentium II and later)
the Memory Type Range Registers (MTRRs) may be used to control
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index cf08c9f..7e183e3 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -34,6 +34,8 @@ ioremap | -- | UC- | UC- |
| | | |
ioremap_cache | -- | WB | WB |
| | | |
+ioremap_uc | -- | UC | UC |
+ | | | |
ioremap_nocache | -- | UC- | UC- |
| | | |
ioremap_wc | -- | -- | WC |
@@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
as step 0 above and also track the usage of those pages and use set_memory_wb()
before the page is freed to free pool.
-
+MTRR effects on PAT / non-PAT systems
+-------------------------------------
+
+The following table provides the effects of using write-combining MTRRs when
+using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
+mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
+be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
+is made should already have be ioremap'd with write-combining page attributes
+or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
+Devices which combine areas of IO memory desired to remain uncachable with
+areas where write-combining is desirable and are restricted by the size
+requirements of MTRRs should consider splitting up their IO memory space
+cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
+encompassing both regions. Such use is nevertheless heavily discouraged as
+the effective memory type is considered implementation defined. This strategy
+should only be used as last resort on devices with size-contrained regions
+where otherwise MTRR write-combining would not be effective.
+
+Note that you cannot use set_memory_wc() to override / whitelist IO remapped
+memory space mapped with ioremap*() calls, set_memory_wc() can only be used
+on RAM.
+
+----------------------------------------------------------------------
+MTRR Non-PAT PAT Linux ioremap value Effective memory type
+----------------------------------------------------------------------
+ Non-PAT | PAT
+ PAT
+ |PCD
+ ||PWT
+ |||
+WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
+WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
+WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
+WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
+----------------------------------------------------------------------
+
+(*) denotes implementation defined and is discouraged
Notes:
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index ea5f363..12abdbe 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
* attempts to add a WC MTRR covering size bytes starting at base and
* logs an error if this fails.
*
+ * The caller should expect to need to provide a power of two size on an
+ * equivalent power of two boundary.
+ *
* Drivers must store the return value to pass to mtrr_del_wc_if_needed,
* but drivers should not try to interpret that return value.
*/
--
2.3.2.209.gd67f9d5.dirty
From: "Luis R. Rodriguez" <[email protected]>
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: Toshi Kani <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Mathias Krause <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/video/fbdev/aty/atyfb_base.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index 8789e48..16936bb 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -427,6 +427,20 @@ static struct {
#endif /* CONFIG_FB_ATY_CT */
};
+/*
+ * Last page of 8 MB (4 MB on ISA) aperture is MMIO,
+ * unless the auxiliary register aperture is used.
+ */
+static void aty_fudge_framebuffer_len(struct fb_info *info)
+{
+ struct atyfb_par *par = (struct atyfb_par *) info->par;
+
+ if (!par->aux_start &&
+ (info->fix.smem_len == 0x800000 ||
+ (par->bus_type == ISA && info->fix.smem_len == 0x400000)))
+ info->fix.smem_len -= GUI_RESERVE;
+}
+
static int correct_chipset(struct atyfb_par *par)
{
u8 rev;
@@ -2603,14 +2617,7 @@ static int aty_init(struct fb_info *info)
if (par->pll_ops->resume_pll)
par->pll_ops->resume_pll(info, &par->pll);
- /*
- * Last page of 8 MB (4 MB on ISA) aperture is MMIO,
- * unless the auxiliary register aperture is used.
- */
- if (!par->aux_start &&
- (info->fix.smem_len == 0x800000 ||
- (par->bus_type == ISA && info->fix.smem_len == 0x400000)))
- info->fix.smem_len -= GUI_RESERVE;
+ aty_fudge_framebuffer_len(info);
/*
* Disable register access through the linear aperture
--
2.3.2.209.gd67f9d5.dirty
From: "Luis R. Rodriguez" <[email protected]>
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: Toshi Kani <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Mathias Krause <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/video/fbdev/aty/atyfb_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index 16936bb..8025624 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3489,7 +3489,9 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info,
/* Map in frame buffer */
info->fix.smem_start = addr;
- info->screen_base = ioremap(addr, 0x800000);
+ info->fix.smem_len = 0x800000;
+
+ info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
if (info->screen_base == NULL) {
ret = -ENOMEM;
goto atyfb_setup_generic_fail;
--
2.3.2.209.gd67f9d5.dirty
From: "Luis R. Rodriguez" <[email protected]>
Replace a WC MTRR call followed by a UC MTRR "hole" call
with a single WC MTRR call and use strong UC to protect
the MMIO region and account for the device's architecture
and MTRR size requirements.
The atyfb driver relies on two overlapping MTRRs. It
does this to account for the fact that on some devices
it has the MMIO region bundled together with the framebuffer
on the same PCI BAR and the hardware requirement on
MTRRs on both base and size to be powers of two. In the
atyfb driver's case in the worst case the PCI BAR is
of 16 MiB while the MMIO region is on the last 4 KiB of
the same PCI BAR. If we use just one MTRR for WC we can
only end up with an 8 MiB or 16 MiB framebuffer. Using a
16 MiB WC framebuffer area is unacceptable since we need
the MMIO region to not be write-combined. An 8 MiB WC
framebuffer option does not let use quite a bit of framebuffer
space, it would reduce the resolution capability of the device
considerably. An alternative is to use many MTRRs but on
some systems that could mean not having not enough MTRRs
to cover the framebuffer. The current driver solution is
to issue a 16 MiB WC MTRR followed by a 4 KiB UC MTRR on
the last 4 KiB. Its worth mentioning and documenting that
the current ioremap*() strategy as well: the first ioremap()
is used only for the MMIO region, a second ioremap() call
is used for the framebuffer *and* the MMIO region, the MMIO
region then ends up mmap'd twice. Two ioremap() calls are
used since in some situations the framebuffer actually ends
up on a separate auxiliary PCI BAR, but this is not always
true, in the worst case the PCI BAR is shared for both
MMIO and the framebuffer. By allowing overlapping ioremap()
calls the driver enables two types of devices with one
simple ioremap() strategy.
For non PAT systems:
As per Intel SDM "11.5.2.1 Selecting Memory Types for Pentium
Pro and Pentium II Processors" [0] the effect of a WC MTRR for
a region with page attribute settings set to PCD=1, PWT=1
(Linux _PAGE_CACHE_MODE_UC) will render the effective memory
type to UC. A WC MTRR for a region with page attribute settings
set to PCD=1, PWT=0 (Linux _PAGE_CACHE_MODE_UC_MINUS) will render
the effective memory type to WC *but* yet this is considered
implementation defined -- that is, "system designers are
encouraged to avoid these implementation-defined combinations".
A WC MTRR for a region with page attribute settings set to
PCD=0, PWT=1 (Linux _PAGE_CACHE_MODE_WC) will render the
effective memory type to WC *but* this is also implementation
defined. Such is the case for non-PAT systems.
For PAT systems:
As per Intel SDM "11.5.2.2 Selecting Memory Types for Pentium
III and More Recent Processor Families" the ffect of a WC MTRR
for a region with a PAT entry value of UC will be UC. The effect
of a WC MTRR on a region with a PAT entry UC- will be WC. The
effect of a WC MTRR on a regoin with PAT entry WC is WC.
This can all be summarized in the following table:
----------------------------------------------------------------------
MTRR Non-PAT PAT Linux ioremap value Effective memory type
----------------------------------------------------------------------
Non-PAT | PAT
PAT
|PCD
||PWT
|||
WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
----------------------------------------------------------------------
(*) denotes implementation defined
By default Linux today defaults both and ioremap_nocache()
to use _PAGE_CACHE_MODE_UC_MINUS. On x86 ioremap() aliases
ioremap_nocache(). The preferred value for Linux by may soon
change however, the goal is to use _PAGE_CACHE_MODE_UC by
default in the future.
We can use ioremap_uc() to set PCD=1, PWT=1 on non-PAT systems
and use a PAT value of UC for PAT systems. This will ensure the
same settings are in place regardless of what Linux decides to
use by default later and to not regress our MTRR strategy since
the effective memory type will differ depending on the value used.
Using a WC MTRR on such an area will be nullified. This technique
can be used to protect the MMIO region in this driver's case and
address the restrictions of the device's architecture as well as
restrictions set upon us by powers of 2 when using MTRRs.
This allows us to replace the two MTRR calls with a single
16 MiB WC MTRR and use page-attribute settings for non-PAT
and PAT entry values for PAT systems to ensure the
appropriate effective memory type won't have a write-combined
effect on the MMIO region on both non-PAT and PAT systems.
The framebuffer area will be sure to get the write-combined
effective memory type by white-listing it with ioremap_wc().
We ensure the desired effective memory types are set by:
0) Using one ioremap_uc() for the MMIO region alone.
This will set the page attribute settings for the MMIO
region to PCD=1, PWT=1 for non-PAT systems while using a
strong UC value on PAT systems.
1) Fixing the framebuffer ioremap'd area to exclude the
MMIO region and using ioremap_wc() instead to whitelist
the area we want for write-combining.
On both cases an implementation defined (as per above table)
effective memory type of WC is used for the framebuffer for
non-PAT systems.
[0] https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
Cc: Toshi Kani <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Mathias Krause <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 36 ++++++++++++++----------------------
2 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 1f39a62..89ec439 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -184,7 +184,6 @@ struct atyfb_par {
spinlock_t int_lock;
#ifdef CONFIG_MTRR
int mtrr_aper;
- int mtrr_reg;
#endif
u32 mem_cntl;
struct crtc saved_crtc;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..546f5af 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,13 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par->mtrr_aper = -1;
- par->mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
+ /*
+ * Only the ioremap_wc()'d area will get WC here
+ * since ioremap_uc() was used on the entire PCI BAR.
+ */
par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
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
@@ -2776,10 +2768,6 @@ aty_init_exit:
par->pll_ops->set_pll(info, &par->saved_pll);
#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
if (par->mtrr_aper >= 0) {
mtrr_del(par->mtrr_aper, 0, 0);
par->mtrr_aper = -1;
@@ -3466,7 +3454,11 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info,
}
info->fix.mmio_start = raddr;
- par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000);
+ /*
+ * By using strong UC we force the MTRR to never have an
+ * effect on the MMIO region on both non-PAT and PAT systems.
+ */
+ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000);
if (par->ati_regbase == NULL)
return -ENOMEM;
@@ -3491,7 +3483,10 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info,
info->fix.smem_start = addr;
info->fix.smem_len = 0x800000;
- info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
+ aty_fudge_framebuffer_len(info);
+
+ info->screen_base = ioremap_wc(info->fix.smem_start,
+ info->fix.smem_len);
if (info->screen_base == NULL) {
ret = -ENOMEM;
goto atyfb_setup_generic_fail;
@@ -3563,6 +3558,7 @@ static int atyfb_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
par = info->par;
+ par->bus_type = PCI;
info->fix = atyfb_fix;
info->device = &pdev->dev;
par->pci_id = pdev->device;
@@ -3732,10 +3728,6 @@ static void atyfb_remove(struct fb_info *info)
#endif
#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
if (par->mtrr_aper >= 0) {
mtrr_del(par->mtrr_aper, 0, 0);
par->mtrr_aper = -1;
--
2.3.2.209.gd67f9d5.dirty
From: "Luis R. Rodriguez" <[email protected]>
This driver uses strong UC for the MMIO region, and ioremap_wc()
for the framebuffer to whitelist for the WC MTRR what can changed
to WC. On PAT systems we don't need the MTRR call so just use
arch_phys_wc_add() there, this lets us remove all those ifdefs.
Lets also be consistent and use ioremap_wc() for ATARI as well.
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() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
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: Toshi Kani <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Mathias Krause <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/video/fbdev/aty/atyfb.h | 4 +---
drivers/video/fbdev/aty/atyfb_base.c | 37 +++++++-----------------------------
2 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 89ec439..63c4842 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -182,9 +182,7 @@ struct atyfb_par {
unsigned long irq_flags;
unsigned int irq;
spinlock_t int_lock;
-#ifdef CONFIG_MTRR
- int mtrr_aper;
-#endif
+ int wc_cookie;
u32 mem_cntl;
struct crtc saved_crtc;
union aty_pll saved_pll;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index 546f5af..b75c974 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -98,9 +98,6 @@
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/backlight.h>
#endif
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
/*
* Debug flags.
@@ -303,9 +300,6 @@ static struct fb_ops atyfb_ops = {
};
static bool noaccel;
-#ifdef CONFIG_MTRR
-static bool nomtrr;
-#endif
static int vram;
static int pll;
static int mclk;
@@ -2628,17 +2622,13 @@ static int aty_init(struct fb_info *info)
aty_st_le32(BUS_CNTL, aty_ld_le32(BUS_CNTL, par) |
BUS_APER_REG_DIS, par);
-#ifdef CONFIG_MTRR
- par->mtrr_aper = -1;
- if (!nomtrr) {
+ if (!nomtrr)
/*
* Only the ioremap_wc()'d area will get WC here
* since ioremap_uc() was used on the entire PCI BAR.
*/
- par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
- MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ par->wc_cookie = arch_phys_wc_add(par->res_start,
+ par->res_size);
info->fbops = &atyfb_ops;
info->pseudo_palette = par->pseudo_palette;
@@ -2766,13 +2756,8 @@ aty_init_exit:
/* restore video mode */
aty_set_crtc(par, &par->saved_crtc);
par->pll_ops->set_pll(info, &par->saved_pll);
+ arch_phys_wc_del(par->wc_cookie);
-#ifdef CONFIG_MTRR
- if (par->mtrr_aper >= 0) {
- mtrr_del(par->mtrr_aper, 0, 0);
- par->mtrr_aper = -1;
- }
-#endif
return ret;
}
@@ -3660,7 +3645,8 @@ static int __init atyfb_atari_probe(void)
* Map the video memory (physical address given)
* to somewhere in the kernel address space.
*/
- info->screen_base = ioremap(phys_vmembase[m64_num], phys_size[m64_num]);
+ info->screen_base = ioremap_wc(phys_vmembase[m64_num],
+ phys_size[m64_num]);
info->fix.smem_start = (unsigned long)info->screen_base; /* Fake! */
par->ati_regbase = ioremap(phys_guiregbase[m64_num], 0x10000) +
0xFC00ul;
@@ -3726,13 +3712,8 @@ static void atyfb_remove(struct fb_info *info)
if (M64_HAS(MOBIL_BUS))
aty_bl_exit(info->bl_dev);
#endif
+ arch_phys_wc_del(par->wc_cookie);
-#ifdef CONFIG_MTRR
- if (par->mtrr_aper >= 0) {
- mtrr_del(par->mtrr_aper, 0, 0);
- par->mtrr_aper = -1;
- }
-#endif
#ifndef __sparc__
if (par->ati_regbase)
iounmap(par->ati_regbase);
@@ -3848,10 +3829,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
} else if (!strncmp(this_opt, "nomtrr", 6)) {
nomtrr = 1;
-#endif
} else if (!strncmp(this_opt, "vram:", 5))
vram = simple_strtoul(this_opt + 5, NULL, 0);
else if (!strncmp(this_opt, "pll:", 4))
@@ -4021,7 +4000,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_MTRR
module_param(nomtrr, bool, 0);
MODULE_PARM_DESC(nomtrr, "bool: disable use of MTRR registers");
-#endif
--
2.3.2.209.gd67f9d5.dirty
On Wed, Apr 29, 2015 at 02:44:06PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> ioremap_nocache() currently uses UC- by default.
> Our goal is to eventually make UC the default.
> Linux maps UC- to PCD=1, PWT=0 page attributes on
> non-PAT systems. Linux maps UC to PCD=1, PWT=1
> page attributes on non-PAT systems. On non-PAT
> and PAT systems a WC MTRR has different effects on
> pages with either of these attributes. In order to
> help with a smooth transition its best to enable
> use of UC (PCD,1, PWT=1) on a region as that ensures
> a WC MTRR will have no effect on a region, this
> however requires us to have an way to declare a
> region as UC and we currently do not have a way
> to do this.
>
> WC MTRR on non-PAT system with PCD=1, PWT=0 (UC-) yields WC.
> WC MTRR on non-PAT system with PCD=1, PWT=1 (UC) yields UC.
>
> WC MTRR on PAT system with PCD=1, PWT=0 (UC-) yields WC.
> WC MTRR on PAT system with PCD=1, PWT=1 (UC) yields UC.
>
> A flip of the default ioremap_nocache() behaviour
> from UC- to UC can therefore regress a memory
> region from effective memory type WC to UC if MTRRs
> are used. Use of MTRRs should be phased out and in
> the best case only arch_phys_wc_add() use will remain,
> even if this happens arch_phys_wc_add() will have an
> effect on non-PAT systems and changes to default
> ioremap_nocache() behaviour could regress drivers.
>
> Now, ideally we'd use ioremap_nocache() on the regions
> in which we'd need uncachable memory types and avoid
> any MTRRs on those regions. There are however some
> restrictions on MTRRs use, such as the requirement of
> having the base and size of variable sized MTRRs
> to be powers of two, which could mean having to use
> a WC MTRR over a large area which includes a region
> in which write-combining effects are undesirable.
>
> Add ioremap_uc() to help with the both phasing out of
> MTRR use and also provide a way to blacklist small
> WC undesirable regions in devices with mixed regions
> which are size-implicated to use large WC MTRRs. Use
> of ioremap_uc() helps phase out MTRR use by avoiding
> regressions with an eventual flip of default behaviour
> or ioremap_nocache() from UC- to UC.
>
> Drivers working with WC MTRRs can use the below table
> to review and consider the use of ioremap*() and similar
> helpers to ensure appropriate behaviour long term even
> if default ioremap_nocache() behaviour changes from UC-
> to UC.
>
> Although ioremap_uc() is being added we leave set_memory_uc()
> to use UC- as only initial memory type setup is required
> to be able to accomodate existing device drivers and phase
> out MTRR use. It should also be clarified that set_memory_uc()
> cannot be used with IO memory, even though its use will
> not return any errors, it really has no effect.
>
> ----------------------------------------------------------------------
> MTRR Non-PAT PAT Linux ioremap value Effective memory type
> ----------------------------------------------------------------------
> Non-PAT | PAT
> PAT
> |PCD
> ||PWT
> |||
> WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> ----------------------------------------------------------------------
>
> Cc: Toshi Kani <[email protected]>
> Cc: Andy Lutomirski <[email protected]>
> Cc: Bjorn Helgaas <[email protected]>
> Cc: Suresh Siddha <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Juergen Gross <[email protected]>
> Cc: Daniel Vetter <[email protected]>
> Cc: Dave Airlie <[email protected]>
> Cc: Antonino Daplas <[email protected]>
> Cc: Jean-Christophe Plagniol-Villard <[email protected]>
> Cc: Tomi Valkeinen <[email protected]>
> Cc: Ville Syrjälä <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Thierry Reding <[email protected]>
> Cc: Mike Travis <[email protected]>
> Cc: Mel Gorman <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Davidlohr Bueso <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
> arch/x86/include/asm/io.h | 1 +
> arch/x86/mm/ioremap.c | 36 +++++++++++++++++++++++++++++++++++-
> arch/x86/mm/pageattr.c | 3 +++
> include/asm-generic/io.h | 8 ++++++++
> 4 files changed, 47 insertions(+), 1 deletion(-)
Looks ok to me. Applied, thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
On 04/29/15 14:44, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> ---
> Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> 3 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index cf08c9f..7e183e3 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> as step 0 above and also track the usage of those pages and use set_memory_wb()
> before the page is freed to free pool.
>
> -
> +MTRR effects on PAT / non-PAT systems
> +-------------------------------------
> +
> +The following table provides the effects of using write-combining MTRRs when
> +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
> +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> +is made should already have be ioremap'd with write-combining page attributes
> +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> +Devices which combine areas of IO memory desired to remain uncachable with
I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds
14 hits vs. 6 hits for uncachable. No big deal.
> +areas where write-combining is desirable and are restricted by the size
> +requirements of MTRRs should consider splitting up their IO memory space
> +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> +encompassing both regions. Such use is nevertheless heavily discouraged as
> +the effective memory type is considered implementation defined. This strategy
> +should only be used as last resort on devices with size-contrained regions
size-constrained
> +where otherwise MTRR write-combining would not be effective.
> +
> +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> +on RAM.
> +
> +----------------------------------------------------------------------
> +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> +----------------------------------------------------------------------
> + Non-PAT | PAT
> + PAT
> + |PCD
> + ||PWT
> + |||
> +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> +----------------------------------------------------------------------
> +
> +(*) denotes implementation defined and is discouraged
>
> Notes:
>
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index ea5f363..12abdbe 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> * attempts to add a WC MTRR covering size bytes starting at base and
> * logs an error if this fails.
> *
> + * The caller should expect to need to provide a power of two size on an
* The called should provide a power of two size on an equivalent
* power of two boundary.
> + * equivalent power of two boundary.
> + *
> * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
> * but drivers should not try to interpret that return value.
> */
>
--
~Randy
On Wed, Apr 29, 2015 at 02:44:07PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> As part of the effort to phase out MTRR use document
> write-combining MTRR effects on pages with different
> non-PAT page attributes flags and different PAT entry
> values. Extend arch_phys_wc_add() documentation to
> clarify power of two sizes / boundary requirements as
> we phase out mtrr_add() use.
>
> Lastly hint towards ioremap_uc() for corner cases on
> device drivers working with devices with mixed regions
> where MTRR size requirements would otherwise not
> enable write-combining effective memory types.
>
> Cc: Toshi Kani <[email protected]>
> Cc: Jonathan Corbet <[email protected]>
> Cc: Dave Hansen <[email protected]>
> Cc: Andy Lutomirski <[email protected]>
> Cc: Suresh Siddha <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Juergen Gross <[email protected]>
> Cc: Daniel Vetter <[email protected]>
> Cc: Dave Airlie <[email protected]>
> Cc: Antonino Daplas <[email protected]>
> Cc: Jean-Christophe Plagniol-Villard <[email protected]>
> Cc: Tomi Valkeinen <[email protected]>
> Cc: Ville Syrjälä <[email protected]>
> Cc: Mel Gorman <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Davidlohr Bueso <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> ---
> Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> 3 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
> index cc071dc..a111a6c 100644
> --- a/Documentation/x86/mtrr.txt
> +++ b/Documentation/x86/mtrr.txt
> @@ -1,7 +1,19 @@
> MTRR (Memory Type Range Register) control
> -3 Jun 1999
> -Richard Gooch
> -<[email protected]>
> +
> +Richard Gooch <[email protected]> - 3 Jun 1999
> +Luis R. Rodriguez <[email protected]> - April 9, 2015
> +
> +===============================================================================
> +Phasing MTRR use
"Phasing out...".
> +
> +MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
> +of effective MTRR that is expected to be supported will be for write-combining.
> +As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
> +MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
> +
> +For details refer to Documentation/x86/pat.txt.
> +
> +===============================================================================
>
> On Intel P6 family processors (Pentium Pro, Pentium II and later)
> the Memory Type Range Registers (MTRRs) may be used to control
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index cf08c9f..7e183e3 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -34,6 +34,8 @@ ioremap | -- | UC- | UC- |
> | | | |
> ioremap_cache | -- | WB | WB |
> | | | |
> +ioremap_uc | -- | UC | UC |
> + | | | |
> ioremap_nocache | -- | UC- | UC- |
> | | | |
> ioremap_wc | -- | -- | WC |
> @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> as step 0 above and also track the usage of those pages and use set_memory_wb()
> before the page is freed to free pool.
>
> -
> +MTRR effects on PAT / non-PAT systems
> +-------------------------------------
> +
> +The following table provides the effects of using write-combining MTRRs when
> +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
out
> +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> +is made should already have be ioremap'd with write-combining page attributes
, have been ioremapped with WC attributes...
> +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> +Devices which combine areas of IO memory desired to remain uncachable with
> +areas where write-combining is desirable and are restricted by the size
> +requirements of MTRRs should consider splitting up their IO memory space
> +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> +encompassing both regions. Such use is nevertheless heavily discouraged as
> +the effective memory type is considered implementation defined. This strategy
> +should only be used as last resort on devices with size-contrained regions
> +where otherwise MTRR write-combining would not be effective.
> +
> +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> +on RAM.
> +
> +----------------------------------------------------------------------
> +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> +----------------------------------------------------------------------
> + Non-PAT | PAT
> + PAT
> + |PCD
> + ||PWT
> + |||
> +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> +----------------------------------------------------------------------
> +
> +(*) denotes implementation defined and is discouraged
>
> Notes:
>
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index ea5f363..12abdbe 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> * attempts to add a WC MTRR covering size bytes starting at base and
> * logs an error if this fails.
> *
> + * The caller should expect to need to provide a power of two size on an
> + * equivalent power of two boundary.
> + *
> * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
> * but drivers should not try to interpret that return value.
> */
> --
> 2.3.2.209.gd67f9d5.dirty
>
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
On Thu, Apr 30, 2015 at 03:01:12PM -0700, Randy Dunlap wrote:
> On 04/29/15 14:44, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <[email protected]>
> > diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> > index cf08c9f..7e183e3 100644
> > --- a/Documentation/x86/pat.txt
> > +++ b/Documentation/x86/pat.txt
> > @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> > as step 0 above and also track the usage of those pages and use set_memory_wb()
> > before the page is freed to free pool.
> >
> > -
> > +MTRR effects on PAT / non-PAT systems
> > +-------------------------------------
> > +
> > +The following table provides the effects of using write-combining MTRRs when
> > +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> > +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
> > +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> > +is made should already have be ioremap'd with write-combining page attributes
> > +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> > +Devices which combine areas of IO memory desired to remain uncachable with
>
> I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds
> 14 hits vs. 6 hits for uncachable. No big deal.
>
> > +areas where write-combining is desirable and are restricted by the size
> > +requirements of MTRRs should consider splitting up their IO memory space
> > +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> > +encompassing both regions. Such use is nevertheless heavily discouraged as
> > +the effective memory type is considered implementation defined. This strategy
> > +should only be used as last resort on devices with size-contrained regions
>
> size-constrained
>
> > +where otherwise MTRR write-combining would not be effective.
> > +
> > +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> > +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> > +on RAM.
> > +
> > +----------------------------------------------------------------------
> > +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> > +----------------------------------------------------------------------
> > + Non-PAT | PAT
> > + PAT
> > + |PCD
> > + ||PWT
> > + |||
> > +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> > +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> > +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> > +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> > +----------------------------------------------------------------------
> > +
> > +(*) denotes implementation defined and is discouraged
> >
> > Notes:
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> > index ea5f363..12abdbe 100644
> > --- a/arch/x86/kernel/cpu/mtrr/main.c
> > +++ b/arch/x86/kernel/cpu/mtrr/main.c
> > @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> > * attempts to add a WC MTRR covering size bytes starting at base and
> > * logs an error if this fails.
> > *
> > + * The caller should expect to need to provide a power of two size on an
>
> * The called should provide a power of two size on an equivalent
> * power of two boundary.
>
Thanks since Boris took this already I'll let him amend unless he wishes for
me to send a new version.
Luis
On Tue, May 05, 2015 at 02:45:06AM +0200, Luis R. Rodriguez wrote:
> Thanks since Boris took this already I'll let him amend unless he wishes for
> me to send a new version.
Haven't. I'm waiting for v2.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
On Thu, Apr 30, 2015 at 03:01:12PM -0700, Randy Dunlap wrote:
> On 04/29/15 14:44, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <[email protected]>
> >
>
> > ---
> > Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> > Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> > arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> > 3 files changed, 57 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> > index cf08c9f..7e183e3 100644
> > --- a/Documentation/x86/pat.txt
> > +++ b/Documentation/x86/pat.txt
> > @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> > as step 0 above and also track the usage of those pages and use set_memory_wb()
> > before the page is freed to free pool.
> >
> > -
> > +MTRR effects on PAT / non-PAT systems
> > +-------------------------------------
> > +
> > +The following table provides the effects of using write-combining MTRRs when
> > +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> > +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
> > +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> > +is made should already have be ioremap'd with write-combining page attributes
> > +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> > +Devices which combine areas of IO memory desired to remain uncachable with
>
> I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds
> 14 hits vs. 6 hits for uncachable. No big deal.
Fixed.
> > +areas where write-combining is desirable and are restricted by the size
> > +requirements of MTRRs should consider splitting up their IO memory space
> > +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> > +encompassing both regions. Such use is nevertheless heavily discouraged as
> > +the effective memory type is considered implementation defined. This strategy
> > +should only be used as last resort on devices with size-contrained regions
>
> size-constrained
Fixed.
> > +where otherwise MTRR write-combining would not be effective.
> > +
> > +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> > +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> > +on RAM.
> > +
> > +----------------------------------------------------------------------
> > +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> > +----------------------------------------------------------------------
> > + Non-PAT | PAT
> > + PAT
> > + |PCD
> > + ||PWT
> > + |||
> > +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> > +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> > +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> > +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> > +----------------------------------------------------------------------
> > +
> > +(*) denotes implementation defined and is discouraged
> >
> > Notes:
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> > index ea5f363..12abdbe 100644
> > --- a/arch/x86/kernel/cpu/mtrr/main.c
> > +++ b/arch/x86/kernel/cpu/mtrr/main.c
> > @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> > * attempts to add a WC MTRR covering size bytes starting at base and
> > * logs an error if this fails.
> > *
> > + * The caller should expect to need to provide a power of two size on an
>
> * The called should provide a power of two size on an equivalent
> * power of two boundary.
Fixed.
Luis
On Mon, May 04, 2015 at 02:23:03PM +0200, Borislav Petkov wrote:
> On Wed, Apr 29, 2015 at 02:44:07PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <[email protected]>
> >
> > As part of the effort to phase out MTRR use document
> > write-combining MTRR effects on pages with different
> > non-PAT page attributes flags and different PAT entry
> > values. Extend arch_phys_wc_add() documentation to
> > clarify power of two sizes / boundary requirements as
> > we phase out mtrr_add() use.
> >
> > Lastly hint towards ioremap_uc() for corner cases on
> > device drivers working with devices with mixed regions
> > where MTRR size requirements would otherwise not
> > enable write-combining effective memory types.
> >
> > Cc: Toshi Kani <[email protected]>
> > Cc: Jonathan Corbet <[email protected]>
> > Cc: Dave Hansen <[email protected]>
> > Cc: Andy Lutomirski <[email protected]>
> > Cc: Suresh Siddha <[email protected]>
> > Cc: Ingo Molnar <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: Juergen Gross <[email protected]>
> > Cc: Daniel Vetter <[email protected]>
> > Cc: Dave Airlie <[email protected]>
> > Cc: Antonino Daplas <[email protected]>
> > Cc: Jean-Christophe Plagniol-Villard <[email protected]>
> > Cc: Tomi Valkeinen <[email protected]>
> > Cc: Ville Syrj?l? <[email protected]>
> > Cc: Mel Gorman <[email protected]>
> > Cc: Vlastimil Babka <[email protected]>
> > Cc: Borislav Petkov <[email protected]>
> > Cc: Davidlohr Bueso <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Signed-off-by: Luis R. Rodriguez <[email protected]>
> > ---
> > Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> > Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> > arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> > 3 files changed, 57 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
> > index cc071dc..a111a6c 100644
> > --- a/Documentation/x86/mtrr.txt
> > +++ b/Documentation/x86/mtrr.txt
> > @@ -1,7 +1,19 @@
> > MTRR (Memory Type Range Register) control
> > -3 Jun 1999
> > -Richard Gooch
> > -<[email protected]>
> > +
> > +Richard Gooch <[email protected]> - 3 Jun 1999
> > +Luis R. Rodriguez <[email protected]> - April 9, 2015
> > +
> > +===============================================================================
> > +Phasing MTRR use
>
> "Phasing out...".
Fixed all, will send another version.
Luis
On Tue, May 05, 2015 at 09:22:14AM +0200, Borislav Petkov wrote:
> On Tue, May 05, 2015 at 02:45:06AM +0200, Luis R. Rodriguez wrote:
> > Thanks since Boris took this already I'll let him amend unless he wishes for
> > me to send a new version.
>
> Haven't. I'm waiting for v2.
OK thanks, it'll be a v5 actually. I am only resending the documentation patch.
Ville, are you OK with the other atyfb patches that follow up on top of this?
If so since they depend on ioremap_uc() should it go through Boris as he's
taking that in?
Luis
On Tue, May 05, 2015 at 09:46:34AM +0200, Luis R. Rodriguez wrote:
> If so since they depend on ioremap_uc() should it go through Boris as he's
> taking that in?
Let's slow down a bit first, ok? First let's have all the x86 changes
ready, in and tested. Drivers can convert to them in a following step.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
Tomi,
the new required ioremap_uc() which was added in the initial patch set here is
now merged on linux-next but I just noticed a small issue with this atyfb
specific patch, I'll fix that and respin and send to you as v5.
Luis
On Wed, May 20, 2015 at 12:53 PM, Luis R. Rodriguez <[email protected]> wrote:
> Tomi,
>
> the new required ioremap_uc() which was added in the initial patch set here is
> now merged on linux-next but I just noticed a small issue with this atyfb
> specific patch, I'll fix that and respin and send to you as v5.
Actually since this series depends on ioremap_uc() and since I need to
respin the last patch in this series for atyfb provided I get an
Acked-by from you for the fbdev changes do you mind if this goes
through the x86 tree as that already has the ioremap_uc() required
call? Otherwise we will have one kernel release with that call
available but not used, and we'll have to wait for 2 releases before
these changes get merged.
Thoughts?
Luis
On Wed, Apr 29, 2015 at 2:44 PM, Luis R. Rodriguez
<[email protected]> wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> This series addresses one commend fix on the table for mtrr_add()
> effect on the PAT case when UC- is used. Other than that it is
> the same as v4.
>
> Luis R. Rodriguez (6):
> x86: add ioremap_uc() - force strong UC, PCD=1, PWT=1
> x86: document WC MTRR effects on PAT / non-PAT pages
> video: fbdev: atyfb: move framebuffer length fudging to helper
> video: fbdev: atyfb: clarify ioremap() base and length used
> video: fbdev: atyfb: replace MTRR UC hole with strong UC
> video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
Ville,
the x86 patches are in and on their way to the next version of Linux.
Can I trouble you for your review of the atyfb driver changes?
Luis
On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez <[email protected]> wrote:
> Ville,
>
> the x86 patches are in and on their way to the next version of Linux.
> Can I trouble you for your review of the atyfb driver changes?
Hey Ville, just a friendly *poke*.
Luis
On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez <[email protected]> wrote:
>> Ville,
>>
>> the x86 patches are in and on their way to the next version of Linux.
>> Can I trouble you for your review of the atyfb driver changes?
>
> Hey Ville, just a friendly *poke*.
Hey, Ville, trying your Intel address, just in case. Full context of
the entire series, in case it helps as this happens to be the more
complex of the changes in the entire series:
http://lkml.kernel.org/r/CAB=NE6UgtdSoBsA=8+ueYRAZHDnWUSmQAoHhAaefqudBrSY7Zw@mail.gmail.com
Luis
On Tue, Jun 16, 2015 at 12:31 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez <[email protected]> wrote:
>> On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez <[email protected]> wrote:
>>> Ville,
>>>
>>> the x86 patches are in and on their way to the next version of Linux.
>>> Can I trouble you for your review of the atyfb driver changes?
>>
>> Hey Ville, just a friendly *poke*.
>
> Hey, Ville, trying your Intel address, just in case. Full context of
> the entire series, in case it helps as this happens to be the more
> complex of the changes in the entire series:
>
> http://lkml.kernel.org/r/CAB=NE6UgtdSoBsA=8+ueYRAZHDnWUSmQAoHhAaefqudBrSY7Zw@mail.gmail.com
Tomi, Dave, Andy,
Its' been one month now since posting the last unmodified version
(other than commit log) of this series [0] and no word or follow up
from Ville. The merge window is closing in and other than the PCI
changes this would be the last pending series. Can I trouble one of
you for your review ? I will note that this series depends on the
ioremap_uc() which went in through Ingo's tree and visible on
linux-next.
[0] http://lkml.kernel.org/r/[email protected]
Luis
On Fri, Jun 19, 2015 at 3:22 PM, Luis R. Rodriguez <[email protected]> wrote:
> Tomi, Dave, Andy,
>
> Its' been one month now since posting the last unmodified version
> (other than commit log) of this series [0] and no word or follow up
> from Ville. The merge window is closing in and other than the PCI
> changes this would be the last pending series. Can I trouble one of
> you for your review ? I will note that this series depends on the
> ioremap_uc() which went in through Ingo's tree and visible on
> linux-next.
>
> [0] http://lkml.kernel.org/r/[email protected]
Alright, I'll poke to see if Andrew might take these then. I'll post a
new clean series just to be crystal clear as this is a complex set, I
admit and it may be worth re-iterating things.
Luis
* Luis R. Rodriguez <[email protected]> wrote:
> On Fri, Jun 19, 2015 at 3:22 PM, Luis R. Rodriguez <[email protected]> wrote:
> > Tomi, Dave, Andy,
> >
> > Its' been one month now since posting the last unmodified version
> > (other than commit log) of this series [0] and no word or follow up
> > from Ville. The merge window is closing in and other than the PCI
> > changes this would be the last pending series. Can I trouble one of
> > you for your review ? I will note that this series depends on the
> > ioremap_uc() which went in through Ingo's tree and visible on
> > linux-next.
> >
> > [0] http://lkml.kernel.org/r/[email protected]
>
> Alright, I'll poke to see if Andrew might take these then. I'll post a new clean
> series just to be crystal clear as this is a complex set, I admit and it may be
> worth re-iterating things.
No, please send it to us against -tip as the previous patches, I'd like all these
changes that materially impact x86 to go through the x86 tree.
I can deal with the generic impact.
Thanks,
Ingo
On Thu, Jun 25, 2015 at 08:59:45AM +0200, Ingo Molnar wrote:
>
> * Luis R. Rodriguez <[email protected]> wrote:
>
> > On Fri, Jun 19, 2015 at 3:22 PM, Luis R. Rodriguez <[email protected]> wrote:
> > > Tomi, Dave, Andy,
> > >
> > > Its' been one month now since posting the last unmodified version
> > > (other than commit log) of this series [0] and no word or follow up
> > > from Ville. The merge window is closing in and other than the PCI
> > > changes this would be the last pending series. Can I trouble one of
> > > you for your review ? I will note that this series depends on the
> > > ioremap_uc() which went in through Ingo's tree and visible on
> > > linux-next.
> > >
> > > [0] http://lkml.kernel.org/r/[email protected]
> >
> > Alright, I'll poke to see if Andrew might take these then. I'll post a new clean
> > series just to be crystal clear as this is a complex set, I admit and it may be
> > worth re-iterating things.
>
> No, please send it to us against -tip as the previous patches, I'd like all these
> changes that materially impact x86 to go through the x86 tree.
Oh OK -- Andrew please ignore that atyfb series I sent yesterday to you then.
> I can deal with the generic impact.
Great, thanks.
Luis