From: Jeff Garzik <jgarzik@pobox.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Add skeleton "generic IO mapping" infrastructure.
Date: Tue, 14 Sep 2004 10:30:12 -0400 [thread overview]
Message-ID: <41470074.9010900@pobox.com> (raw)
In-Reply-To: <1095152147.9144.254.camel@imladris.demon.co.uk>
David Woodhouse wrote:
> On Mon, 2004-09-13 at 18:32 +0000, Linux Kernel Mailing List wrote:
>
>>ChangeSet 1.1869, 2004/09/13 11:32:00-07:00, torvalds@ppc970.osdl.org
>>
>> Add skeleton "generic IO mapping" infrastructure.
>>
>> Jeff wants to use this to clean up SATA and some network drivers.
>
>
>
>>+ * Read/write from/to an (offsettable) iomem cookie. It might be a PIO
>>+ * access or a MMIO access, these functions don't care. The info is
>>+ * encoded in the hardware mapping set up by the mapping functions
>>+ * (or the cookie itself, depending on implementation and hw).
>>+ *
>>+ * The generic routines don't assume any hardware mappings, and just
>>+ * encode the PIO/MMIO as part of the cookie. They coldly assume that
>>+ * the MMIO IO mappings are not in the low address range.
>>+ *
>>+ * Architectures for which this is not true can't use this generic
>>+ * implementation and should do their own copy.
>>+ *
>>+ * 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
>>+ * we can do some sanity checks on the low bits, and don't
>>+ * need to just take things for granted.
>>+ */
>>+#define PIO_OFFSET 0x10000
>>+#define PIO_MASK 0x0ffff
>>+#define PIO_RESERVED 0x40000
>
>
>>+#define IO_COND(addr, is_pio, is_mmio) do { \
>>+ unsigned long port = (unsigned long __force)addr; \
>>+ if (port < PIO_RESERVED) { \
>>+ VERIFY_PIO(port); \
>>+ port &= PIO_MASK; \
>>+ is_pio; \
>>+ } else { \
>>+ is_mmio; \
>>+ } \
>>+} while (0)
>
>
> Argh! Please no. You can't infer the IO space from the address. Provide
> a cookie containing {space, address} instead -- or indeed {bus,
> address}. Let some architectures optimise that by ignoring the bus and
> working it out from the address if you must, but don't put that in the
> generic version.
Override it in your arch if you don't like the generic version ;-)
Jeff
next prev parent reply other threads:[~2004-09-14 14:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200409132206.i8DM6dSC030620@hera.kernel.org>
2004-09-14 8:55 ` Add skeleton "generic IO mapping" infrastructure David Woodhouse
2004-09-14 14:30 ` Jeff Garzik [this message]
2004-09-14 14:33 ` David Woodhouse
2004-09-14 15:06 ` Jeff Garzik
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=41470074.9010900@pobox.com \
--to=jgarzik@pobox.com \
--cc=dwmw2@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox