* [PATCH v8 4/9] video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
From: Luis R. Rodriguez @ 2015-06-25 1:22 UTC (permalink / raw)
To: bp
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Laurent Pinchart, Rob Clark,
Geert Uytterhoeven, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..f19133a 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
info->fix.smem_start = fb_phys;
info->fix.smem_len = pci_resource_len(pdev, 1);
- info->screen_base = pci_ioremap_bar(pdev, 1);
+ info->screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info->screen_base) {
dev_err(&pdev->dev, "gxt4500: cannot map framebuffer\n");
goto err_unmap_regs;
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v8 5/9] PCI: Add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-06-25 1:22 UTC (permalink / raw)
To: bp
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Davidlohr Bueso, konrad.wilk,
ville.syrjala, david.vrabel, jbeulich, Roger Pau Monné
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.
Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
of write combining when they know it's safe.
On architectures that don't fully support WC, e.g., x86 without PAT,
drivers for legacy framebuffers may get some of the benefit by using
arch_phys_wc_add() in addition to pci_iomap_wc(). But arch_phys_wc_add()
is unreliable and should be avoided in general. On x86, it uses MTRRs,
which are limited in number and size, so the results will vary based on
driver loading order.
The goals of adding pci_iomap_wc() are to:
- Give drivers an architecture-independent way to use WC so they can stop
using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
PAT when available)
- Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
and pci_mmap_page_range()")
Link: http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcgrof@do-not-panic.com
Original-posting: http://lkml.kernel.org/r/1432163293-20965-1-git-send-email-mcgrof@do-not-panic.com
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
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 <stefan.bader@canonical.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: konrad.wilk@oracle.com
Cc: ville.syrjala@linux.intel.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
include/asm-generic/pci_iomap.h | 14 ++++++++++
lib/pci_iomap.c | 61 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87..b1e17fc 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long max);
extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned lon
return NULL;
}
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long max)
+{
+ return NULL;
+}
static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
{
return NULL;
}
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f1..9604dcb 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
EXPORT_SYMBOL(pci_iomap_range);
/**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way. When possible write combining
+ * is used.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR from offset to the end, pass %0 here.
+ * */
+void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
+ int bar,
+ 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 NULL;
+ 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 */
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v8 6/9] lib: devres: add pcim_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-06-25 1:22 UTC (permalink / raw)
To: bp
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Davidlohr Bueso, konrad.wilk,
ville.syrjala, david.vrabel, jbeulich, Roger Pau Monné
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Now that we have pci_iomap_wc() add the respective
devres helpers. These go unexported for now but
note that should they later be exported this
must go with EXPORT_SYMBOL_GPL().
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
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 <stefan.bader@canonical.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: konrad.wilk@oracle.com
Cc: ville.syrjala@linux.intel.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
include/linux/pci.h | 2 ++
lib/devres.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1193975..5ff15c1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1609,9 +1609,11 @@ static inline void pci_dev_specific_enable_acs(struct pci_dev *dev) { }
#endif
void __iomem *pcim_iomap(struct pci_dev *pdev, int bar, unsigned long maxlen);
+void __iomem *pcim_iomap_wc(struct pci_dev *pdev, int bar, unsigned long maxlen);
void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr);
void __iomem * const *pcim_iomap_table(struct pci_dev *pdev);
int pcim_iomap_regions(struct pci_dev *pdev, int mask, const char *name);
+int pcim_iomap_wc_regions(struct pci_dev *pdev, int mask, const char *name);
int pcim_iomap_regions_request_all(struct pci_dev *pdev, int mask,
const char *name);
void pcim_iounmap_regions(struct pci_dev *pdev, int mask);
diff --git a/lib/devres.c b/lib/devres.c
index fbe2aac..38acc53 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -304,6 +304,29 @@ void __iomem *pcim_iomap(struct pci_dev *pdev, int bar, unsigned long maxlen)
EXPORT_SYMBOL(pcim_iomap);
/**
+ * pcim_iomap_wc - Managed pcim_iomap_wc()
+ * @pdev: PCI device to iomap for
+ * @bar: BAR to iomap
+ * @maxlen: Maximum length of iomap
+ *
+ * Managed pci_iomap_wc(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *pcim_iomap_wc(struct pci_dev *pdev, int bar, unsigned long maxlen)
+{
+ void __iomem **tbl;
+
+ BUG_ON(bar >= PCIM_IOMAP_MAX);
+
+ tbl = (void __iomem **)pcim_iomap_table(pdev);
+ if (!tbl || tbl[bar]) /* duplicate mappings not allowed */
+ return NULL;
+
+ tbl[bar] = pci_iomap_wc(pdev, bar, maxlen);
+ return tbl[bar];
+}
+
+/**
* pcim_iounmap - Managed pci_iounmap()
* @pdev: PCI device to iounmap for
* @addr: Address to unmap
@@ -383,6 +406,59 @@ int pcim_iomap_regions(struct pci_dev *pdev, int mask, const char *name)
EXPORT_SYMBOL(pcim_iomap_regions);
/**
+ * pcim_iomap_wc_regions - Request and iomap PCI BARs with write-combining
+ * @pdev: PCI device to map IO resources for
+ * @mask: Mask of BARs to request and iomap
+ * @name: Name used when requesting regions
+ *
+ * Request and iomap regions specified by @mask with a preference for
+ * write-combining.
+ */
+int pcim_iomap_wc_regions(struct pci_dev *pdev, int mask, const char *name)
+{
+ void __iomem * const *iomap;
+ int i, rc;
+
+ iomap = pcim_iomap_table(pdev);
+ if (!iomap)
+ return -ENOMEM;
+
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ unsigned long len;
+
+ if (!(mask & (1 << i)))
+ continue;
+
+ rc = -EINVAL;
+ len = pci_resource_len(pdev, i);
+ if (!len)
+ goto err_inval;
+
+ rc = pci_request_region(pdev, i, name);
+ if (rc)
+ goto err_inval;
+
+ rc = -ENOMEM;
+ if (!pcim_iomap_wc(pdev, i, 0))
+ goto err_region;
+ }
+
+ return 0;
+
+ err_region:
+ pci_release_region(pdev, i);
+ err_inval:
+ while (--i >= 0) {
+ if (!(mask & (1 << i)))
+ continue;
+ pcim_iounmap(pdev, iomap[i]);
+ pci_release_region(pdev, i);
+ }
+
+ return rc;
+}
+
+/**
* pcim_iomap_regions_request_all - Request all BARs and iomap specified ones
* @pdev: PCI device to map IO resources for
* @mask: Mask of BARs to iomap
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v8 7/9] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez @ 2015-06-25 1:22 UTC (permalink / raw)
To: bp
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Laurent Pinchart, Geert Uytterhoeven,
Lad, Prabhakar, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/arkfb.c | 36 +++++-------------------------------
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e..6a317de 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
#include <linux/console.h> /* Why should fb driver call console functions? because console_lock() */
#include <video/vga.h>
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
-
struct arkfb_info {
int mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
static char *mode_option = "640x480-8@60";
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
MODULE_AUTHOR("(c) 2007 Ondrej Zajicek <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
-
static int threshold = 4;
module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1057,14 +1044,8 @@ static int ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start, info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
-
+ par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
/* Error handling */
@@ -1092,14 +1073,7 @@ static void ark_pci_remove(struct pci_dev *dev)
if (info) {
struct arkfb_info *par = info->par;
-
-#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
-#endif
-
+ arch_phys_wc_del(par->wc_cookie);
dac_release(par->dac);
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v8 8/9] video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez @ 2015-06-25 1:22 UTC (permalink / raw)
To: bp
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Jean-Christophe Plagniol-Villard, Jingoo Han,
Geert Uytterhoeven, Daniel Vetter, Lad, Prabhakar,
Rickard Strandqvist, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Dave Airlie, Antonino Daplas
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (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: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/s3fb.c | 35 ++++++-----------------------------
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a..13b1090 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
#include <linux/i2c.h>
#include <linux/i2c-algo-bit.h>
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
-
struct s3fb_info {
int chip, rev, mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
-
static int fasttext = 1;
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc) (deprecated)");
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, default=1)");
-#endif
module_param(fasttext, int, 0644);
MODULE_PARM_DESC(fasttext, "Enable S3 fast text mode (1=enable, 0=disable, default=1)");
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1365,12 +1354,9 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start, info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
@@ -1405,14 +1391,7 @@ static void s3_pci_remove(struct pci_dev *dev)
if (info) {
par = info->par;
-
-#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
-#endif
-
+ arch_phys_wc_del(par->wc_cookie);
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
@@ -1551,10 +1530,8 @@ static int __init s3fb_setup(char *options)
if (!*opt)
continue;
-#ifdef CONFIG_MTRR
else if (!strncmp(opt, "mtrr:", 5))
mtrr = simple_strtoul(opt + 5, NULL, 0);
-#endif
else if (!strncmp(opt, "fasttext:", 9))
fasttext = simple_strtoul(opt + 9, NULL, 0);
else
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v8 9/9] video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez @ 2015-06-25 1:22 UTC (permalink / raw)
To: bp
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Rob Clark, Laurent Pinchart, Jingoo Han,
Lad, Prabhakar, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (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: Rob Clark <robdclark@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/vt8623fb.c | 31 ++++++-------------------------
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index ea7f056..60f24828 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
#include <linux/console.h> /* Why should fb driver call console functions? because console_lock() */
#include <video/vga.h>
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
-
struct vt8623fb_info {
char __iomem *mmio_base;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
/* Module parameters */
static char *mode_option = "640x480-8@60";
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
MODULE_AUTHOR("(c) 2006 Ondrej Zajicek <santiago@crfreenet.org>");
MODULE_LICENSE("GPL");
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
module_param_named(mode, mode_option, charp, 0);
MODULE_PARM_DESC(mode, "Default video mode e.g. '648x480-8@60' (deprecated)");
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, default=1)");
-#endif
/* ------------------------------------------------------------------------- */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
info->fix.mmio_len = pci_resource_len(dev, 1);
/* Map physical IO memory address into kernel space */
- info->screen_base = pci_iomap(dev, 0, 0);
+ info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -781,12 +771,9 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par->mtrr_reg = -1;
- par->mtrr_reg = mtrr_add(info->fix.smem_start, info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
@@ -816,13 +803,7 @@ static void vt8623_pci_remove(struct pci_dev *dev)
if (info) {
struct vt8623fb_info *par = info->par;
-#ifdef CONFIG_MTRR
- if (par->mtrr_reg >= 0) {
- mtrr_del(par->mtrr_reg, 0, 0);
- par->mtrr_reg = -1;
- }
-#endif
-
+ arch_phys_wc_del(par->wc_cookie);
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v5 0/3] atyfb: address MTRR corner case
From: Luis R. Rodriguez @ 2015-06-25 1:34 UTC (permalink / raw)
To: akpm
Cc: bp, mingo, syrjala, ville.syrjala, luto, tomi.valkeinen, mst,
benh, linux-kernel, linux-fbdev, linux-pci, airlied,
Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Andrew,
Forgive me for the TL;DR, I'm afraid I need to be crystal clear on this
patchset as its the most complex in the entire series. The skinny is that this
patchset addresses a complex work around with APIs now merged upstream going in
for v4.2, the driver maintainer hasn't followed up with the driver changes for
over a month and no one else has provided Acks for these device driver
changes [0]. We have a few options:
0) Sit and wait for a driver maintainer to review this
1) Merge this as-is and hope for reports
2) go with the nopat requirement as with the ivtv and ipath driver
I'd prefer to merge this as is, and only if reports come back with
issues should we then consider 2) as we'd then have at least a well
documented work effort required for this transformation. This device
driver is also old, so I don't expect much reports anyway.
----
The TL;DR:
As part of the long haul effort to rid the world of direct MTRR use [1] we've
have had to also work on alternative solutions which can co-exist with PAT
interfaces. Most of the transformation of device drivers to use PAT was fairly
easy (TM): so long as ioremap_wc() was used we could then convert over the
drivers using mtrr_add() over to the arch-agnostic and PAT-aware (ignored when
PAT is enabled) arch_phys_wc_add(). This was typically easy to do, for instance
in cases where a full PCI BAR was used for MMIO registers and another PCI BAR
was used with write-combining effects desirable. In some cases we just needed
new WC apis for some buses. This was the case for most modern devices, but a
few old devices had a combined set of MMIO registers and the write-combined
area mixed. In such situations even when using MTRR one had to figure out
creative solutions to make things work, specially considering MTRRs were
limited and they had size constraints: an MTRR base and size must be
a power of two.
The good news is that on Linux there were only three device drivers in total
that we ended up with radical issue with when converting them over to PAT
interfaces. One was with the ivtv media device driver, another was the
infiniband ipath device driver. The other one was the framebuffer atyfb
device driver that this series addresses. For both ivtv and ipath we've
decided to simply require users of those devices to boot with the nopat
kernel parameter because both devices drivers are ancient and the work
required to fully convert to PAT interfaces is significant (in the ipath case)
or nearly almost impossible (ivtv). For details please refer to the respective
and now upstream commits:
7ea402d x86/mm/pat, drivers/infiniband/ipath: Use arch_phys_wc_add() and require PAT disabled
1bf1735 x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled
To demo exactly how much effort would have been required I decided to venture
into atyfb and try to fix that device driver first, considering it had the
worst case situation to address as it used size hackery and MTRR combinations
of different types. In order to accomplish this we needed to map out all
possible combinatorial effects of PAT page entries with write-combining, and
page attributes (PAT, PCD, PWT) with write-combining effects for non-PAT
systems. We did this not only for atyfb's sake but also for any other possible
future driver which might meet these same needs. We needed to take this a bit
more seriously given that our long term goal was also to change the default
behaviour of ioremap_nocache() to use strong UC instead of UC-, we needed
to take this into consideration when converting drivers over. The documentation
table for all these possible combinatorial entries is now upstream:
2f9e897 x86/mm/mtrr, pat: Document Write Combining MTRR type effects on PAT / non-PAT pages
Of importance to this patch set is this 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
----------------------------------------------------------------------
In the atyfb case it used to use two MTRR calls, a large WC MTRR followed by a
UC MTRR "hole" call for the MMIO registers. This was done this way on atyfb
because of the offset and size of the framebuffer area would only work well
this way, otherwise you'd also have to try a series of small MTRR calls and you
might end up running out of MTRRs. For non-PAT systems we take advantage of the
above map to protect an MMIO region with 011 page attributes (this maps to
strong UC for PAT systems) so that if a large MTRR is issued that encompasses
the MMIO region, the MMIO region remains with an effective UC type, while the
desired wc area would have an effective memory type of WC as its region would
have been mapped with ioremap_wc(). This makes use of the newly introduced
ioremap_uc() as otherwise if we would have used ioremap_nocache() we would
not get the UC effective memeory type. This also let us remove the only UC MTRR
call from the kernel :) after this then we'd only have WC MTRR calls in effect
on non-PAT systems on Linux. The more complex patch then is patch 2 which does
most of the magic.
[0] http://lkml.kernel.org/r/CAB=NE6Xy1UGAqZ8CsVc+JzKqsxREaXBYK+1GjZKN8d2FG8xqJg@mail.gmail.com
[1] http://lkml.kernel.org/r/CAB=NE6UgtdSoBsA=8+ueYRAZHDnWUSmQAoHhAaefqudBrSY7Zw@mail.gmail.com
Luis R. Rodriguez (3):
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()
drivers/video/fbdev/aty/atyfb.h | 5 +--
drivers/video/fbdev/aty/atyfb_base.c | 74 +++++++++++-------------------------
2 files changed, 24 insertions(+), 55 deletions(-)
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply
* [PATCH v5 1/3] video: fbdev: atyfb: clarify ioremap() base and length used
From: Luis R. Rodriguez @ 2015-06-25 1:34 UTC (permalink / raw)
To: akpm
Cc: bp, mingo, syrjala, ville.syrjala, luto, tomi.valkeinen, mst,
benh, linux-kernel, linux-fbdev, linux-pci, airlied,
Luis R. Rodriguez, Toshi Kani, Suresh Siddha, Linus Torvalds,
Thomas Gleixner, Juergen Gross, Daniel Vetter, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Rob Clark, Mathias Krause,
Andrzej Hajda, Mel Gorman, Vlastimil Babka, Davidlohr Bueso
In-Reply-To: <1435196060-27350-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI we *know* this defaults to 0x800000.
atyfb_setup_generic() is *only* used on PCI probe.
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/aty/atyfb_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index 16936bb..8025624 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3489,7 +3489,9 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info,
/* Map in frame buffer */
info->fix.smem_start = addr;
- info->screen_base = ioremap(addr, 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
^ permalink raw reply related
* [PATCH v5 2/3] video: fbdev: atyfb: replace MTRR UC hole with strong UC
From: Luis R. Rodriguez @ 2015-06-25 1:34 UTC (permalink / raw)
To: akpm
Cc: bp, mingo, syrjala, ville.syrjala, luto, tomi.valkeinen, mst,
benh, linux-kernel, linux-fbdev, linux-pci, airlied,
Luis R. Rodriguez, Toshi Kani, Suresh Siddha, Linus Torvalds,
Thomas Gleixner, Juergen Gross, Daniel Vetter, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Rob Clark, Mathias Krause,
Andrzej Hajda, Mel Gorman, Vlastimil Babka, Davidlohr Bueso
In-Reply-To: <1435196060-27350-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
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 <toshi.kani@hp.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
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
^ permalink raw reply related
* [PATCH v5 3/3] video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez @ 2015-06-25 1:34 UTC (permalink / raw)
To: akpm
Cc: bp, mingo, syrjala, ville.syrjala, luto, tomi.valkeinen, mst,
benh, linux-kernel, linux-fbdev, linux-pci, airlied,
Luis R. Rodriguez, Toshi Kani, Suresh Siddha, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Rob Clark, Mathias Krause,
Andrzej Hajda, Mel Gorman, Vlastimil Babka, Davidlohr Bueso
In-Reply-To: <1435196060-27350-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This driver uses strong UC for the MMIO region, and ioremap_wc()
for the framebuffer to whitelist for the WC MTRR what can be 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 <toshi.kani@hp.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/aty/atyfb.h | 4 +---
drivers/video/fbdev/aty/atyfb_base.c | 36 +++++++-----------------------------
2 files changed, 8 insertions(+), 32 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..96c605c 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -98,9 +98,6 @@
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/backlight.h>
#endif
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
/*
* Debug flags.
@@ -303,9 +300,7 @@ static struct fb_ops atyfb_ops = {
};
static bool noaccel;
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
static int vram;
static int pll;
static int mclk;
@@ -2628,17 +2623,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 +2757,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 +3646,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 +3713,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 +3830,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 +4001,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
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: convert pr_err to pr_info
From: Dan Carpenter @ 2015-06-25 7:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150618125052.GA21893@IND12F0122>
On Wed, Jun 24, 2015 at 04:32:38PM +0000, Gujulan Elango, Hari Prasath (H.) wrote:
> On Mon, Jun 22, 2015 at 06:15:06PM +0300, Dan Carpenter wrote:
> > On Thu, Jun 18, 2015 at 12:56:54PM +0000, Gujulan Elango, Hari Prasath (H.) wrote:
> > > From: Hari Prasath Gujulan Elango <hgujulan@visteon.com>
> > >
> > > This patch modifies few debug prints from pr_err() to pr_info() as they
> > > fall under that category.
> > >
> >
> > They should be dbg or removed.
> >
> > regards,
> > dan carpenter
> >
>
> Dan,Greg has already merged this patch.Should I now send another patch
> to convert this from pr_info() to pr_dbg() ?
Nah. Don't worry about it until someone complains.
Eventually all the debug output in this driver needs to be redone.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3 11/19] staging: sm750fb: consistent spacing around operators
From: Sudip Mukherjee @ 2015-06-25 11:56 UTC (permalink / raw)
To: Juston Li
Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel,
dan.carpenter
In-Reply-To: <1435163120-3253-11-git-send-email-juston.h.li@gmail.com>
On Wed, Jun 24, 2015 at 09:25:12AM -0700, Juston Li wrote:
> fixes checkpatch.pl error:
> ERROR: need consistent spacing around ''
little bit confused.
1) Your subject says consistent space around operators but here it says
around ''
2) Considering that you are giving consitent space around operators, then
i think you have missed few operators like '|','&',':' in this
patch.
regards
sudip
^ permalink raw reply
* Re: [PATCH v3 16/19] staging: sm750fb: fix brace placement
From: Sudip Mukherjee @ 2015-06-25 12:29 UTC (permalink / raw)
To: Juston Li
Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel,
dan.carpenter
In-Reply-To: <1435163120-3253-16-git-send-email-juston.h.li@gmail.com>
On Wed, Jun 24, 2015 at 09:25:17AM -0700, Juston Li wrote:
> Fix brace placement errors caught by checkpatch.pl
> ERROR: that open brace { should be on the previous line
>
> Signed-off-by: Juston Li <juston.h.li@gmail.com>
> ---
<snip>
> @@ -71,14 +66,11 @@ static void setDisplayControl(int ctrl, int dispState)
> POKE32(PANEL_DISPLAY_CTRL, ulDisplayCtrlReg);
> }
>
> - }
> /* Set the secondary display control */
> - else
> - {
> + } else {
just a thought. The comment previously was at the beginning of the else
block, but now it will be placed inside the if block - at the end.
will it confuse code readers afterwards?
regards
sudip
^ permalink raw reply
* RE: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
From: Casey Leedom @ 2015-06-25 15:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Luis R. Rodriguez
Cc: Michael S. Tsirkin, Bjorn Helgaas, Toshi Kani, Andy Lutomirski,
Juergen Gross, Tomi Valkeinen, Arnd Bergmann,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
xen-devel@lists.xensource.com, linux-fbdev, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Daniel Vetter, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi@intel.com, Stefan Bader,
Ville Syrjälä, Mel Gorman, Vlastimil Babka,
Borislav Petkov, Davidlohr Bueso, Konrad Rzeszutek Wilk,
Ville Syrjälä, David Vrabel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <1435189081.3790.24.camel@kernel.crashing.org>
/ From: Benjamin Herrenschmidt [benh@kernel.crashing.org]
| Sent: Wednesday, June 24, 2015 4:38 PM
|
| It is to be noted that on powerpc at least, writel() and co will never
| combine due to the memory barriers in them. Only "normal" stores (or
\ __raw_writel) will.
/ From: Benjamin Herrenschmidt [benh@kernel.crashing.org]
| Sent: Wednesday, June 24, 2015 5:52 PM
|
| Right, and as I mentioned, on some archs like powerpc (and possibly
\ more), writel() and co contains an implicit mb()
Hhmmm, interesting. I definitely hadn't known that. In our network
drivers we explicitly manage all of our own memory barrier semantics.
(wmb() between writes to DMA Queues and writes to Device Registers
informing hardware of new data available to be DMA'ed, etc.) And we
do have code to take advantage of Write Combining Mappings using
writeq(). It looks like this is implemented eventually as out_be64()
in arch/powerpc/include/asm/io.h for PPC-BE:
#define DEF_MMIO_OUT_D(name, size, insn) \
static inline void name(volatile u##size __iomem *addr, u##size val) \
{ \
__asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0" \
: "=m" (*addr) : "r" (val) : "memory"); \
IO_SET_SYNC_FLAG(); \
}
DEF_MMIO_OUT_D(out_be64, 64, std);
So, if understand your notes and the source correctly, all of
our code to do register reads/writes are getting SYNC instructions,
as are the 64-bit writeq()s we're attempting to use for our Write
Combining code on PowerPC. Hhmmm indeed ...
Is there a reference I can read on this so I can understand
when and where we can use the __raw_*() APIs? Can these
Raw Read/Write operations be reordered with respect to
each other or are the use of the various flavors of SYNC
instructions just to maintain order between Cached Memory
Accesses and I/O Instructions?
Casey
^ permalink raw reply
* Re: [PATCH v8 5/9] PCI: Add pci_iomap_wc() variants
From: Borislav Petkov @ 2015-06-25 15:09 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Davidlohr Bueso, konrad.wilk,
ville.syrjala, david.vrabel, jbeulich, Roger Pau Monné
In-Reply-To: <1435195342-26879-6-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jun 24, 2015 at 06:22:18PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> PCI BARs tell us whether prefetching is safe, but they don't say anything
> about write combining (WC). WC changes ordering rules and allows writes to
> be collapsed, so it's not safe in general to use it on a prefetchable
> region.
>
> Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
> of write combining when they know it's safe.
>
> On architectures that don't fully support WC, e.g., x86 without PAT,
> drivers for legacy framebuffers may get some of the benefit by using
> arch_phys_wc_add() in addition to pci_iomap_wc(). But arch_phys_wc_add()
> is unreliable and should be avoided in general. On x86, it uses MTRRs,
> which are limited in number and size, so the results will vary based on
> driver loading order.
>
> The goals of adding pci_iomap_wc() are to:
>
> - Give drivers an architecture-independent way to use WC so they can stop
> using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
> PAT when available)
>
> - Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
> on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
> performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
> and pci_mmap_page_range()")
...
> diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
> index bcce5f1..9604dcb 100644
> --- a/lib/pci_iomap.c
> +++ b/lib/pci_iomap.c
> @@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
> EXPORT_SYMBOL(pci_iomap_range);
>
> /**
> + * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
> + * @dev: PCI device that owns the BAR
> + * @bar: BAR number
> + * @offset: map memory at the given offset in BAR
> + * @maxlen: max length of the memory to map
> + *
> + * Using this function you will get a __iomem address to your device BAR.
> + * You can access it using ioread*() and iowrite*(). These functions hide
> + * the details if this is a MMIO or PIO address space and will just do what
> + * you expect from them in the correct way. When possible write combining
> + * is used.
> + *
> + * @maxlen specifies the maximum length to map. If you want to get access to
> + * the complete BAR from offset to the end, pass %0 here.
> + * */
> +void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
> + int bar,
> + 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 NULL;
I've moved this check at the beginning of the function so that we bail
out before doing the computations above it.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* Re: [PATCH v8 6/9] lib: devres: add pcim_iomap_wc() variants
From: Borislav Petkov @ 2015-06-25 15:40 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Dave Hansen, Stefan Bader,
Ville Syrjälä, Mel Gorman, Vlastimil Babka,
Davidlohr Bueso, konrad.wilk, ville.syrjala, david.vrabel,
jbeulich, Roger Pau Monné
In-Reply-To: <1435195342-26879-7-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jun 24, 2015 at 06:22:19PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Now that we have pci_iomap_wc() add the respective
> devres helpers. These go unexported for now but
> note that should they later be exported this
> must go with EXPORT_SYMBOL_GPL().
Do I see it correctly, those are not used in this patchset?
If so, then let's keep this patch in the bag and pick it up only when
those functions have users.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* Re: [PATCH v3 16/19] staging: sm750fb: fix brace placement
From: Juston Li @ 2015-06-25 15:49 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: teddy.wang, Greg KH, linux-fbdev, devel, linux-kernel,
Dan Carpenter
In-Reply-To: <20150625121729.GD13366@sudip-PC>
On Thu, Jun 25, 2015 at 5:17 AM, Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
> On Wed, Jun 24, 2015 at 09:25:17AM -0700, Juston Li wrote:
>> Fix brace placement errors caught by checkpatch.pl
>> ERROR: that open brace { should be on the previous line
>>
>> Signed-off-by: Juston Li <juston.h.li@gmail.com>
>> ---
> <snip>
>> @@ -71,14 +66,11 @@ static void setDisplayControl(int ctrl, int dispState)
>> POKE32(PANEL_DISPLAY_CTRL, ulDisplayCtrlReg);
>> }
>>
>> - }
>> /* Set the secondary display control */
>> - else
>> - {
>> + } else {
> just a thought. The comment previously was at the beginning of the else
> block, but now it will be placed inside the if block - at the end.
> will it confuse code readers afterwards?
>
> regards
> sudip
I placed it above the else to make it consistent with the if statement with
similar comment that the else corresponds to:
/* Set the primary display control */
- if (!ctrl)+ if (!ctrl) {
Thanks
Juston
^ permalink raw reply
* Re: [PATCH v8 6/9] lib: devres: add pcim_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-06-25 15:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ingo Molnar, Arnd Bergmann, Bjorn Helgaas, Andy Lutomirski,
Andrew Morton, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Michael S. Tsirkin,
Toshi Kani, linux-fbdev, xen-devel@lists.xensource.com,
Benjamin Herrenschmidt, Suresh Siddha, Ingo Molnar,
Thomas Gleixner, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard, Dave Hansen,
Stefan Bader, Ville Syrjälä, Mel Gorman,
Vlastimil Babka, Davidlohr Bueso, Konrad Rzeszutek Wilk,
Ville Syrjälä, David Vrabel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <20150625154031.GB4898@pd.tnic>
On Thu, Jun 25, 2015 at 8:40 AM, Borislav Petkov <bp@suse.de> wrote:
> On Wed, Jun 24, 2015 at 06:22:19PM -0700, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> Now that we have pci_iomap_wc() add the respective
>> devres helpers. These go unexported for now but
>> note that should they later be exported this
>> must go with EXPORT_SYMBOL_GPL().
>
> Do I see it correctly, those are not used in this patchset?
That's correct. It was a preemptive implementation of devres pci wc APIs.
> If so, then let's keep this patch in the bag and pick it up only when
> those functions have users.
OK!
Luis
^ permalink raw reply
* Re: [PATCH v8 5/9] PCI: Add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-06-25 15:53 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ingo Molnar, Arnd Bergmann, Bjorn Helgaas, Andy Lutomirski,
Andrew Morton, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Michael S. Tsirkin,
Toshi Kani, linux-fbdev, xen-devel@lists.xensource.com,
Benjamin Herrenschmidt, Suresh Siddha, Ingo Molnar,
Thomas Gleixner, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Davidlohr Bueso,
Konrad Rzeszutek Wilk, Ville Syrjälä, David Vrabel,
Jan Beulich, Roger Pau Monné
In-Reply-To: <20150625150918.GA4898@pd.tnic>
On Thu, Jun 25, 2015 at 8:09 AM, Borislav Petkov <bp@suse.de> wrote:
>> +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 NULL;
>
> I've moved this check at the beginning of the function so that we bail
> out before doing the computations above it.
That indeed looks like a good optimization.
Luis
^ permalink raw reply
* Re: [PATCH v3 11/19] staging: sm750fb: consistent spacing around operators
From: Juston Li @ 2015-06-25 16:26 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: teddy.wang, Greg KH, linux-fbdev, devel, linux-kernel,
Dan Carpenter
In-Reply-To: <20150625115618.GC13366@sudip-PC>
On Thu, Jun 25, 2015 at 4:56 AM, Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
> On Wed, Jun 24, 2015 at 09:25:12AM -0700, Juston Li wrote:
>> fixes checkpatch.pl error:
>> ERROR: need consistent spacing around ''
> little bit confused.
> 1) Your subject says consistent space around operators but here it says
> around ''
The specific checkpatch.pl error was different for each error, the quotes
were suppose to contain the specific operator but I left it out so that there
would be one generic error message. The quotes left behind were confusing,
sorry.
> 2) Considering that you are giving consitent space around operators, then
> i think you have missed few operators like '|','&',':' in this
> patch.
>
These were the only instances the checkpatch.pl error came up. This patch
only fixes even spacing around a specific operator. Other operators either
have even or no spacing around them with PATCH 11/19 fixing any operators
with spacing around required. This leaves operators that checkpatch deems
spacing as optional which I left as a separate issue to be addressed of making
optional spacing of operators consistent with each other.
Thanks
Juston
^ permalink raw reply
* Re: [PATCH v5 0/3] atyfb: address MTRR corner case
From: Luis R. Rodriguez @ 2015-06-25 16:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: akpm, bp, mingo, syrjala, ville.syrjala, luto, tomi.valkeinen,
mst, benh, linux-kernel, linux-fbdev, linux-pci, airlied
In-Reply-To: <1435196060-27350-1-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jun 24, 2015 at 06:34:17PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Andrew,
Andrew, as Ingo noted please disregard these patches as it seems we'll be
preferring for this to go through the x86 tree.
Luis
^ permalink raw reply
* Re: [PATCH v3 16/19] staging: sm750fb: fix brace placement
From: Dan Carpenter @ 2015-06-25 20:31 UTC (permalink / raw)
To: Juston Li
Cc: Sudip Mukherjee, teddy.wang, Greg KH, linux-fbdev, devel,
linux-kernel
In-Reply-To: <CAFow2F_zK42gJ0UoV+GwqLrfsxB2Nqi8kaB7OB+=-APftp=FfQ@mail.gmail.com>
On Thu, Jun 25, 2015 at 08:49:30AM -0700, Juston Li wrote:
> I placed it above the else to make it consistent with the if statement with
> similar comment that the else corresponds to:
>
> /* Set the primary display control */
> - if (!ctrl)+ if (!ctrl) {
Once you add the else statement, then that kind of doesn't make sense.
Sudip is right. It should be:
} else {
/* commentary about else side */
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
From: Arnd Bergmann @ 2015-06-25 20:44 UTC (permalink / raw)
To: Casey Leedom
Cc: Benjamin Herrenschmidt, Luis R. Rodriguez, Michael S. Tsirkin,
Bjorn Helgaas, Toshi Kani, Andy Lutomirski, Juergen Gross,
Tomi Valkeinen, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
linux-fbdev, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi@intel.com, Stefan Bader,
Ville Syrjälä, Mel Gorman, Vlastimil Babka,
Borislav Petkov, Davidlohr Bueso, Konrad Rzeszutek Wilk,
Ville Syrjälä, David Vrabel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com>
On Thursday 25 June 2015 15:01:56 Casey Leedom wrote:
>
> Is there a reference I can read on this so I can understand
> when and where we can use the __raw_*() APIs? Can these
> Raw Read/Write operations be reordered with respect to
> each other or are the use of the various flavors of SYNC
> instructions just to maintain order between Cached Memory
> Accesses and I/O Instructions?
The interpretation is not consistent across architectures.
My best description would be that the __raw_*() accessors should
only be used for accessing RAM areas that are known to have no
side-effects and can be read in any size (8-bit to 64-bit wide),
any alignment, and do not have a specific endianess.
If you are dealing with MMIO registers that have a fixed endianess
and size, the correct accessor would be readl_relaxed(), which
is like readl() but lacks the barriers on certain architectures.
Arnd
^ permalink raw reply
* Re: [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Borislav Petkov @ 2015-06-25 20:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, arnd, bhelgaas, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh,
Luis R. Rodriguez
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jun 24, 2015 at 06:22:13PM -0700, Luis R. Rodriguez wrote:
> Luis R. Rodriguez (9):
> pci: add pci_ioremap_wc_bar()
> 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: gxt4500: use pci_ioremap_wc_bar() for framebuffer
> PCI: Add pci_iomap_wc() variants
> lib: devres: add pcim_iomap_wc() variants
> video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
> video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc()
> video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()
>
> drivers/pci/pci.c | 14 ++++++++
> drivers/video/fbdev/arkfb.c | 36 +++----------------
> drivers/video/fbdev/gxt4500.c | 2 +-
> drivers/video/fbdev/i740fb.c | 35 ++++--------------
> drivers/video/fbdev/kyro/fbdev.c | 33 ++++++-----------
> drivers/video/fbdev/s3fb.c | 35 ++++--------------
> drivers/video/fbdev/vt8623fb.c | 31 ++++------------
> include/asm-generic/pci_iomap.h | 14 ++++++++
> include/linux/pci.h | 3 ++
> include/video/kyro.h | 4 +--
> lib/devres.c | 76 ++++++++++++++++++++++++++++++++++++++++
> lib/pci_iomap.c | 61 ++++++++++++++++++++++++++++++++
> 12 files changed, 204 insertions(+), 140 deletions(-)
Took those, modulo the devres one.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* Re: [PATCH v5 0/3] atyfb: address MTRR corner case
From: Borislav Petkov @ 2015-06-25 20:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: akpm, mingo, syrjala, ville.syrjala, luto, tomi.valkeinen, mst,
benh, linux-kernel, linux-fbdev, linux-pci, airlied,
Luis R. Rodriguez
In-Reply-To: <1435196060-27350-1-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jun 24, 2015 at 06:34:17PM -0700, Luis R. Rodriguez wrote:
> Luis R. Rodriguez (3):
> 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()
>
> drivers/video/fbdev/aty/atyfb.h | 5 +--
> drivers/video/fbdev/aty/atyfb_base.c | 74 +++++++++++-------------------------
> 2 files changed, 24 insertions(+), 55 deletions(-)
Took those too along with
"[PATCH] video: fbdev: atyfb: move framebuffer length fudging to helper"
which was missing here.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox