All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] ioremap_cached()
Date: Thu, 30 Mar 2006 09:41:20 -0700	[thread overview]
Message-ID: <20060330164120.GJ13590@parisc-linux.org> (raw)


We currently have three ways for getting access to device memory --
ioremap(), ioremap_nocache() and pci_iomap().  99% of the callers of
ioremap() are doing it to access device registers, and really, really
want to use ioremap_nocache() instead.  I presume nobody notices on PCs
because they have write-through caches, but it ought to trip up people
trying to flush writes.

pci_iomap() gets this right -- it calls ioremap() if the resource is
tagged with IORESOURCE_CACHEABLE and ioremap_nocache() if it isn't.
Unfortunately, the only resources tagged with IORESOURCE_CACHEABLE
are PCI ROM resources, so even frame buffers and similar that could be
cached aren't.

It seems clear to me that ioremap() and ioremap_nocache() are the
wrong way around.  The default needs to be uncached -- and the obvious
(rare) alternative becomes ioremap_cached().

So here's a patch for i386 to add ioremap_cached() and make ioremap()
uncached.  ioremap_nocache() remains as an alias for ioremap() so we
don't needlessly break old drivers.  Architecture maintainers will need
to fix up their ports if this patch is accepted.


Index: include/asm-i386/io.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-i386/io.h,v
retrieving revision 1.10
diff -u -p -r1.10 io.h
--- a/include/asm-i386/io.h	17 Jan 2006 14:52:36 -0000	1.10
+++ b/include/asm-i386/io.h	30 Mar 2006 16:39:22 -0000
@@ -115,12 +115,13 @@ extern void __iomem * __ioremap(unsigned
  * address. 
  */
 
-static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
+static inline void __iomem * ioremap_cached(unsigned long offset, unsigned long size)
 {
 	return __ioremap(offset, size, 0);
 }
 
-extern void __iomem * ioremap_nocache(unsigned long offset, unsigned long size);
+#define ioremap_nocache(a, b) ioremap(a, b)
+extern void __iomem * ioremap(unsigned long offset, unsigned long size);
 extern void iounmap(volatile void __iomem *addr);
 
 /*
Index: arch/i386/mm/ioremap.c
===================================================================
RCS file: /var/cvs/linux-2.6/arch/i386/mm/ioremap.c,v
retrieving revision 1.13
diff -u -p -r1.13 ioremap.c
--- a/arch/i386/mm/ioremap.c	19 Dec 2005 12:42:12 -0000	1.13
+++ b/arch/i386/mm/ioremap.c	30 Mar 2006 16:39:22 -0000
@@ -167,11 +167,11 @@ void __iomem * __ioremap(unsigned long p
 EXPORT_SYMBOL(__ioremap);
 
 /**
- * ioremap_nocache     -   map bus memory into CPU space
+ * ioremap     -   map bus memory into CPU space
  * @offset:    bus address of the memory
  * @size:      size of the resource to map
  *
- * ioremap_nocache performs a platform specific sequence of operations to
+ * ioremap 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
@@ -188,7 +188,7 @@ EXPORT_SYMBOL(__ioremap);
  * Must be freed with iounmap.
  */
 
-void __iomem *ioremap_nocache (unsigned long phys_addr, unsigned long size)
+void __iomem *ioremap(unsigned long phys_addr, unsigned long size)
 {
 	unsigned long last_addr;
 	void __iomem *p = __ioremap(phys_addr, size, _PAGE_PCD);
@@ -221,7 +221,7 @@ void __iomem *ioremap_nocache (unsigned 
 
 	return p;					
 }
-EXPORT_SYMBOL(ioremap_nocache);
+EXPORT_SYMBOL(ioremap);
 
 /**
  * iounmap - Free a IO remapping

             reply	other threads:[~2006-03-30 16:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-30 16:41 Matthew Wilcox [this message]
2006-03-30 18:27 ` [PATCH] ioremap_cached() Andi Kleen
2006-03-30 19:34   ` Matthew Wilcox
2006-03-30 19:50     ` Andi Kleen
2006-03-30 20:14       ` Matthew Wilcox
2006-03-30 20:17         ` Andi Kleen
2006-03-30 20:21           ` Kumar Gala
2006-03-30 20:27             ` Andi Kleen
2006-03-31 11:20 ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060330164120.GJ13590@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.