From: Jesse Barnes <jbarnes@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] [PATCH] mmio barrier patch update
Date: Wed, 09 Jan 2002 01:36:00 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590698805779@msgid-missing> (raw)
Here's a new version of the mmio barrier patch (against 2.4.17 w/the
ia64 patch) I posted before the break. In addition to writing some
documentation for the macro, I've removed the argument to the mmiob()
macro for a few reasons:
(1) platforms that need to do dummy reads from bridge chips or devices
can do a loop of reads from each bridge chip or a device on each
bus to ensure ordering
(2) hopefully there aren't that many platforms that have to do the
above
(3) it simplifies another change I think we'll need--a mmiob() in the
scheduler for processes that have done I/O in their timeslice
If these aren't good reasons, please let me know. I'd like to get as
much input about the first two as possible; I'm really hoping that (2)
is true at the very least because it would mean that (1) might be a
valid workaround.
Thanks,
Jesse
diff -Naur --exclude=*~ --exclude=TAGS linux-2.4.17-ia64/Documentation/mmio_barrier.txt linux-2.4.17-ia64-mmiob/Documentation/mmio_barrier.txt
--- linux-2.4.17-ia64/Documentation/mmio_barrier.txt Wed Dec 31 16:00:00 1969
+++ linux-2.4.17-ia64-mmiob/Documentation/mmio_barrier.txt Tue Jan 8 15:57:37 2002
@@ -0,0 +1,15 @@
+On some platforms, so-called memory-mapped I/O is weakly ordered. For
+example, the following might occur:
+
+CPU A writes 0x1 to Device #1
+CPU B writes 0x2 to Device #1
+Device #1 sees 0x2
+Device #1 sees 0x1
+
+On such platforms, driver writers are responsible for ensuring that I/O
+writes to memory-mapped addresses on their device arrive in the order
+intended. The mmiob() macro is provided for this purpose. A typical use
+of this macro might be immediately prior to the exit of a critical
+section of code proteced by spinlocks. This would ensure that subsequent
+writes to I/O space arrived only after all prior writes (much like a
+typical memory barrier op, mb(), only with respect to I/O).
diff -Naur --exclude=*~ --exclude=TAGS linux-2.4.17-ia64/arch/ia64/sn/kernel/sn1/iomv.c linux-2.4.17-ia64-mmiob/arch/ia64/sn/kernel/sn1/iomv.c
--- linux-2.4.17-ia64/arch/ia64/sn/kernel/sn1/iomv.c Tue Jan 8 15:45:11 2002
+++ linux-2.4.17-ia64-mmiob/arch/ia64/sn/kernel/sn1/iomv.c Tue Jan 8 15:58:54 2002
@@ -9,6 +9,8 @@
#include <asm/io.h>
#include <linux/pci.h>
#include <asm/sn/simulator.h>
+#include <asm/pio_flush.h>
+#include <asm/delay.h>
static inline void *
sn1_io_addr(unsigned long port)
@@ -134,3 +136,9 @@
__ia64_mf_a();
}
#endif /* SN1_IOPORTS */
+
+void
+sn_mmiob ()
+{
+ PIO_FLUSH();
+}
diff -Naur --exclude=*~ --exclude=TAGS linux-2.4.17-ia64/include/asm-ia64/io.h linux-2.4.17-ia64-mmiob/include/asm-ia64/io.h
--- linux-2.4.17-ia64/include/asm-ia64/io.h Fri Nov 9 14:26:17 2001
+++ linux-2.4.17-ia64-mmiob/include/asm-ia64/io.h Tue Jan 8 15:58:03 2002
@@ -69,6 +69,22 @@
*/
#define __ia64_mf_a() __asm__ __volatile__ ("mf.a" ::: "memory")
+/**
+ * __ia64_mmiob - I/O space memory barrier
+ *
+ * Acts as a memory mapped I/O barrier for platforms that queue writes to
+ * I/O space. This ensures that subsequent writes to I/O space arrive after
+ * all previous writes. For most ia64 platforms, this is a simple
+ * 'mf.a' instruction, so the address is ignored. For other platforms,
+ * the address may be required to ensure proper ordering of writes to I/O space
+ * since a 'dummy' read might be necessary to barrier the write operation.
+ */
+static inline void
+__ia64_mmiob ()
+{
+ __ia64_mf_a();
+}
+
static inline const unsigned long
__ia64_get_io_port_base (void)
{
@@ -271,6 +287,7 @@
#define __outb platform_outb
#define __outw platform_outw
#define __outl platform_outl
+#define __mmiob platform_mmiob
#define inb __inb
#define inw __inw
@@ -284,6 +301,7 @@
#define outsb __outsb
#define outsw __outsw
#define outsl __outsl
+#define mmiob __mmiob
/*
* The address passed to these functions are ioremap()ped already.
diff -Naur --exclude=*~ --exclude=TAGS linux-2.4.17-ia64/include/asm-ia64/machvec.h linux-2.4.17-ia64-mmiob/include/asm-ia64/machvec.h
--- linux-2.4.17-ia64/include/asm-ia64/machvec.h Tue Jan 8 15:45:11 2002
+++ linux-2.4.17-ia64-mmiob/include/asm-ia64/machvec.h Tue Jan 8 15:59:44 2002
@@ -60,6 +60,7 @@
typedef void ia64_mv_outb_t (unsigned char, unsigned long);
typedef void ia64_mv_outw_t (unsigned short, unsigned long);
typedef void ia64_mv_outl_t (unsigned int, unsigned long);
+typedef void ia64_mv_mmiob_t (void);
extern void machvec_noop (void);
@@ -107,6 +108,7 @@
# define platform_outb ia64_mv.outb
# define platform_outw ia64_mv.outw
# define platform_outl ia64_mv.outl
+# define platofrm_mmiob ia64_mv.mmiob
# endif
struct ia64_machine_vector {
@@ -140,6 +142,7 @@
ia64_mv_outb_t *outb;
ia64_mv_outw_t *outw;
ia64_mv_outl_t *outl;
+ ia64_mv_mmiob_t *mmiob;
};
#define MACHVEC_INIT(name) \
@@ -173,7 +176,8 @@
platform_inl, \
platform_outb, \
platform_outw, \
- platform_outl \
+ platform_outl, \
+ platform_mmiob \
}
extern struct ia64_machine_vector ia64_mv;
@@ -287,6 +291,9 @@
#endif
#ifndef platform_outl
# define platform_outl __ia64_outl
+#endif
+#ifndef platform_mmiob
+# define platform_mmiob __ia64_mmiob
#endif
#endif /* _ASM_IA64_MACHVEC_H */
diff -Naur --exclude=*~ --exclude=TAGS linux-2.4.17-ia64/include/asm-ia64/machvec_sn1.h linux-2.4.17-ia64-mmiob/include/asm-ia64/machvec_sn1.h
--- linux-2.4.17-ia64/include/asm-ia64/machvec_sn1.h Tue Jan 8 15:45:11 2002
+++ linux-2.4.17-ia64-mmiob/include/asm-ia64/machvec_sn1.h Tue Jan 8 15:45:54 2002
@@ -14,6 +14,7 @@
extern ia64_mv_outb_t sn1_outb;
extern ia64_mv_outw_t sn1_outw;
extern ia64_mv_outl_t sn1_outl;
+extern ia64_mv_mmiob_t sn_mmiob;
extern ia64_mv_pci_alloc_consistent sn1_pci_alloc_consistent;
extern ia64_mv_pci_free_consistent sn1_pci_free_consistent;
extern ia64_mv_pci_map_single sn1_pci_map_single;
@@ -45,6 +46,7 @@
#define platform_outb sn1_outb
#define platform_outw sn1_outw
#define platform_outl sn1_outl
+#define platform_mmiob sn_mmiob
#define platform_pci_dma_init machvec_noop
#define platform_pci_alloc_consistent sn1_pci_alloc_consistent
#define platform_pci_free_consistent sn1_pci_free_consistent
next reply other threads:[~2002-01-09 1:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-09 1:36 Jesse Barnes [this message]
2002-01-10 21:28 ` [Linux-ia64] [PATCH] mmio barrier patch update Jesse Barnes
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=marc-linux-ia64-105590698805779@msgid-missing \
--to=jbarnes@sgi.com \
--cc=linux-ia64@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.