From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: ia64 implementation of lib/iomap.c
Date: Mon, 25 Oct 2004 16:48:48 +0000 [thread overview]
Message-ID: <200410251048.48249.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <16759.51459.598187.91726@napali.hpl.hp.com>
[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]
On Thursday 21 October 2004 8:34 am, David Mosberger wrote:
> Is anybody already working on an ia64-version of lib/iomap.c?
Here's a start (also attached, because of the kmail bug that
corrupts whitespace).
The idea is that all MMIO iomem cookies are in region 6, so
anything less than that must be a PIO cookie. So we have:
0xCxxxxxxxxxxxxxxx MMIO cookie (return from ioremap)
0xRxxxxxxx1SPPPPPP PIO cookie (R=[0-9AB], S=space num, P..P=port)
I heard a rumor that ioreadX() on PIO cookies is supposed to
have looser semantics than inX() on the port, so we might be
able to get away without the memory fence in inb(). But I
can't substantiate that, so this keeps the generic behavior
of ioreadX() and inX() having identical semantics for PIO.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
===== include/asm-ia64/io.h 1.21 vs edited =====
--- 1.21/include/asm-ia64/io.h 2004-10-05 12:30:39 -06:00
+++ edited/include/asm-ia64/io.h 2004-10-25 10:06:00 -06:00
@@ -32,7 +32,8 @@
*/
#define IO_SPACE_LIMIT 0xffffffffffffffffUL
-#define MAX_IO_SPACES 16
+#define MAX_IO_SPACES_BITS 4
+#define MAX_IO_SPACES (1UL << MAX_IO_SPACES_BITS)
#define IO_SPACE_BITS 24
#define IO_SPACE_SIZE (1UL << IO_SPACE_BITS)
@@ -52,10 +53,16 @@
# ifdef __KERNEL__
+#define PIO_OFFSET (1UL << (MAX_IO_SPACES_BITS + IO_SPACE_BITS))
+#define PIO_MASK (PIO_OFFSET - 1)
+#define PIO_RESERVED __IA64_UNCACHED_OFFSET
+#define HAVE_ARCH_PIO_SIZE
+
#include <asm/intrinsics.h>
#include <asm/machvec.h>
#include <asm/page.h>
#include <asm/system.h>
+#include <asm-generic/iomap.h>
/*
* Change virtual addresses to physical addresses and vv.
===== lib/iomap.c 1.5 vs edited =====
--- 1.5/lib/iomap.c 2004-10-18 23:27:35 -06:00
+++ edited/lib/iomap.c 2004-10-25 10:09:26 -06:00
@@ -19,7 +19,10 @@
*
* Architectures for which this is not true can't use this generic
* implementation and should do their own copy.
- *
+ */
+
+#ifndef HAVE_ARCH_PIO_SIZE
+/*
* We encode the physical PIO addresses (0-0xffff) into the
* pointer by offsetting them with a constant (0x10000) and
* assuming that all the low addresses are always PIO. That means
@@ -29,6 +32,7 @@
#define PIO_OFFSET 0x10000UL
#define PIO_MASK 0x0ffffUL
#define PIO_RESERVED 0x40000UL
+#endif
/*
* Ugly macros are a way of life.
[-- Attachment #2: diffs --]
[-- Type: text/x-diff, Size: 1515 bytes --]
===== include/asm-ia64/io.h 1.21 vs edited =====
--- 1.21/include/asm-ia64/io.h 2004-10-05 12:30:39 -06:00
+++ edited/include/asm-ia64/io.h 2004-10-25 10:06:00 -06:00
@@ -32,7 +32,8 @@
*/
#define IO_SPACE_LIMIT 0xffffffffffffffffUL
-#define MAX_IO_SPACES 16
+#define MAX_IO_SPACES_BITS 4
+#define MAX_IO_SPACES (1UL << MAX_IO_SPACES_BITS)
#define IO_SPACE_BITS 24
#define IO_SPACE_SIZE (1UL << IO_SPACE_BITS)
@@ -52,10 +53,16 @@
# ifdef __KERNEL__
+#define PIO_OFFSET (1UL << (MAX_IO_SPACES_BITS + IO_SPACE_BITS))
+#define PIO_MASK (PIO_OFFSET - 1)
+#define PIO_RESERVED __IA64_UNCACHED_OFFSET
+#define HAVE_ARCH_PIO_SIZE
+
#include <asm/intrinsics.h>
#include <asm/machvec.h>
#include <asm/page.h>
#include <asm/system.h>
+#include <asm-generic/iomap.h>
/*
* Change virtual addresses to physical addresses and vv.
===== lib/iomap.c 1.5 vs edited =====
--- 1.5/lib/iomap.c 2004-10-18 23:27:35 -06:00
+++ edited/lib/iomap.c 2004-10-25 10:09:26 -06:00
@@ -19,7 +19,10 @@
*
* Architectures for which this is not true can't use this generic
* implementation and should do their own copy.
- *
+ */
+
+#ifndef HAVE_ARCH_PIO_SIZE
+/*
* We encode the physical PIO addresses (0-0xffff) into the
* pointer by offsetting them with a constant (0x10000) and
* assuming that all the low addresses are always PIO. That means
@@ -29,6 +32,7 @@
#define PIO_OFFSET 0x10000UL
#define PIO_MASK 0x0ffffUL
#define PIO_RESERVED 0x40000UL
+#endif
/*
* Ugly macros are a way of life.
next prev parent reply other threads:[~2004-10-25 16:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-21 14:34 ia64 implementation of lib/iomap.c David Mosberger
2004-10-21 17:34 ` Bjorn Helgaas
2004-10-21 17:38 ` David Mosberger
2004-10-25 16:48 ` Bjorn Helgaas [this message]
2004-10-26 7:48 ` David Mosberger
2004-10-26 15:21 ` Linus Torvalds
2004-10-26 16:26 ` David Mosberger
2004-10-26 16:23 ` Jesse Barnes
2004-10-26 17:06 ` Linus Torvalds
2004-10-26 17:49 ` Jesse Barnes
2004-10-26 17:55 ` Grant Grundler
2004-10-26 18:05 ` Grant Grundler
2004-10-26 18:12 ` Grant Grundler
2004-10-26 18:19 ` Jesse Barnes
2004-10-26 18:37 ` Grant Grundler
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=200410251048.48249.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox