public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@debian.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Arch list <linux-arch@vger.kernel.org>,
	Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	Andrew Morton <akpm@osdl.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"David S. Miller" <davem@redhat.com>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: RFC: being more anal about iospace accesses..
Date: Wed, 15 Sep 2004 20:40:01 +0100	[thread overview]
Message-ID: <20040915194001.GH642@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0409151205230.2333@ppc970.osdl.org>

On Wed, Sep 15, 2004 at 12:16:35PM -0700, Linus Torvalds wrote:
> On Wed, 15 Sep 2004, Geert Uytterhoeven wrote:
> > Before people really start using this: what's the advantage of this scheme
> > compared to e.g. dev->busops->in8(), which some of us have been waiting for
> > since a long time?
> 
> Ehh, exactly why would you wait for that? 

I'm no fan of bus->ops->in8, but the ioread8() interface is basically
impossible for some architectures.  There's just not enough information
in a single void * cookie to make this work; not without screwing the
speed of readb() down the the speed of inb().

For example, on some of the older PA machines, we can have an EISA
controller and multiple PCI controllers.  readb() is great, it's all
mapped into a flat memory space, and there are no problems.  But inb()
is a royal PITA.  First, we have to decode the port number to figure
out which controller it's under, then (if it's EISA) swizzle the bits in
the port number to get to an address, but if it's PCI, we have to take a
spinlock, write the port number into a register of the right controller,
read the data back from a different register (which is what triggers
the io port cycle to be generated on the PCI bus) and unlock the spinlock.

ioport_map() looks great for the EISA controller because it lets us
pre-map the port number to an address.  But it'd actually be deadly
if the device has more than 8 consecutive IO ports [1].  For the PCI
controllers, it's a complete misery.  We could do something horrid like
assuming no IO is less than 2GB and returning a cookie from ioport_map()
that then gets decoded into somethign similar to the current dance,
but that's really not pleasant.

I'm told SH is in even worse state than PA, but I haven't looked at
that code.

Could we have a 'dev' parameter to ioread8()?  Please?


[1] The implementation is:
        if (port & 0x300) {
                return 0xfc000000 | ((port & 0xfc00) >> 6)
                        | ((port & 0x3f8) << 9) | (port & 7);
        } else {
                return 0xfc000000 | port;
        }

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

  reply	other threads:[~2004-09-15 19:40 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 22:57 RFC: being more anal about iospace accesses Linus Torvalds
2004-09-08 23:07 ` David S. Miller
2004-09-08 23:25   ` Linus Torvalds
2004-09-09  1:19   ` Linus Torvalds
2004-09-09  4:36     ` David S. Miller
2004-09-09  5:56       ` Richard Henderson
2004-09-09  5:04     ` viro
2004-09-09  5:05       ` David S. Miller
2004-09-09  5:13       ` Linus Torvalds
2004-09-09  6:08         ` viro
2004-09-09  8:27   ` Geert Uytterhoeven
2004-09-09  6:23 ` David Woodhouse
2004-09-09 13:14   ` Alan Cox
2004-09-11  6:09 ` Linus Torvalds
2004-09-11  6:42   ` Anton Blanchard
2004-09-11  7:26     ` Benjamin Herrenschmidt
2004-09-11  7:29     ` Geert Uytterhoeven
2004-09-11  7:23   ` Benjamin Herrenschmidt
2004-09-11 14:42   ` Alan Cox
2004-09-15 15:03 ` Linus Torvalds
2004-09-15 19:02   ` Geert Uytterhoeven
2004-09-15 19:16     ` Linus Torvalds
2004-09-15 19:40       ` Matthew Wilcox [this message]
2004-09-15 20:10         ` Linus Torvalds
2004-09-15 20:17           ` Linus Torvalds
2004-09-16 12:17           ` David Woodhouse
2004-09-16 13:52             ` Linus Torvalds
2004-09-15 20:20       ` Russell King
2004-09-15 20:34         ` Linus Torvalds
2004-09-15 20:51           ` Linus Torvalds
2004-09-15 22:38       ` James Bottomley
2004-09-16  2:33         ` Matthew Wilcox
2004-09-16  4:28           ` Linus Torvalds
2004-09-16  4:57             ` Benjamin Herrenschmidt
2004-09-16  4:58               ` Benjamin Herrenschmidt
2004-09-16 13:41             ` Matthew Wilcox
2004-09-16 18:21               ` Linus Torvalds
2004-09-16 18:52                 ` Jesse Barnes
2004-09-16 19:09                   ` Linus Torvalds
2004-09-16 20:02                     ` Jesse Barnes
2004-09-16 20:37                       ` James Bottomley
2004-09-16 20:42                         ` Jesse Barnes
2004-09-16 21:37                           ` Grant Grundler
2004-09-16 20:04                   ` David S. Miller
2004-09-16 20:13                     ` Jeff Garzik
2004-09-16 20:45                       ` David S. Miller
2004-09-16 20:20                     ` Jesse Barnes
2004-09-17  5:17                   ` Benjamin Herrenschmidt
2004-09-17 15:30                     ` Jesse Barnes
2004-09-16 19:01                 ` Linus Torvalds
2004-09-16 19:13                   ` Jeff Garzik
2004-09-16 19:50                     ` Linus Torvalds
2004-09-16 20:07                       ` Alan Cox
2004-09-17  5:44                       ` Benjamin Herrenschmidt
2004-09-17  5:20                   ` Benjamin Herrenschmidt
2004-09-17 15:03                     ` Linus Torvalds
2004-09-16 22:30             ` Matthew Wilcox
2004-09-16 22:42               ` Linus Torvalds
2004-09-16 22:46                 ` Jeff Garzik
2004-09-16 23:15                   ` Linus Torvalds
2004-09-16 23:30                     ` Jeff Garzik
2004-09-16 23:43                       ` Linus Torvalds
2004-09-17 12:44                 ` Matthew Wilcox

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=20040915194001.GH642@parcelfarce.linux.theplanet.co.uk \
    --to=willy@debian.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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