From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] I/O Access Abstractions
Date: Tue, 3 Jul 2001 01:54:47 +0200 [thread overview]
Message-ID: <20010702235447.1201@smtp.wanadoo.fr> (raw)
In-Reply-To: <E15HByZ-0006hZ-00@the-village.bc.nu>
In-Reply-To: <E15HByZ-0006hZ-00@the-village.bc.nu>
>
>Can you give me an idea of what sort of cookie decoding a PPC/PMac would need
>and why - Im working off things like pa-risc so I dont have a full picture.
Each domain provide an IO space (size depends on the bridge, recent Apple
UniNorth hosts have 16Mb per domain).
That IO space can be in any location (depends on the box, bridge config,
..), so basically, we must assume that each host bridge can have it's IO
space anywhere in CPU mem space.
Currently, we store the physical address of those in our pci_controller
structure, and ioremap all of them. One is picked up as the "ISA" io base
(for VGA and such things as legacy devices on non-pmac PPCs). That
isa_io_base is used as an offset to inx/outx, and all PCI IO_RESOURCES
are fixed up to be their real virtual address offset'ed with isa_io_base.
(A bit weird but works and we have only an addition in inx/outx).
I'm more concerned about having all that space mapped permanently in
kernel virtual space. I'd prefer mapping on-demand, and that would
require a specific ioremap for IOs.
Ben.
next prev parent reply other threads:[~2001-07-02 23:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-28 13:13 [RFC] I/O Access Abstractions David Howells
2001-06-28 13:32 ` Alan Cox
2001-06-28 13:55 ` David Woodhouse
2001-06-28 16:02 ` Jes Sorensen
2001-06-29 8:31 ` David Howells
2001-06-29 21:02 ` Jes Sorensen
2001-07-02 14:22 ` David Woodhouse
2001-07-02 15:57 ` David Howells
2001-07-02 16:17 ` David Woodhouse
2001-07-02 16:20 ` Alan Cox
2001-07-02 16:41 ` David Woodhouse
2001-07-02 16:56 ` Alan Cox
2001-07-02 18:22 ` Russell King
2001-07-02 18:26 ` Jeff Garzik
2001-07-02 20:10 ` Alan Cox
2001-07-02 22:08 ` Benjamin Herrenschmidt
2001-07-02 22:15 ` Alan Cox
2001-07-02 23:54 ` Benjamin Herrenschmidt [this message]
2001-07-03 12:02 ` Alan Cox
2001-07-03 14:38 ` Benjamin Herrenschmidt
2001-07-03 2:06 ` Jeff Garzik
2001-07-03 8:38 ` David Howells
2001-07-07 11:27 ` Geert Uytterhoeven
2001-07-03 8:15 ` David Howells
2001-07-03 8:22 ` Jeff Garzik
2001-07-03 8:31 ` Jeff Garzik
2001-07-03 9:00 ` David Howells
2001-07-03 9:29 ` Jeff Garzik
2001-07-02 22:10 ` Benjamin Herrenschmidt
2001-07-03 8:04 ` David Howells
2001-07-03 7:55 ` David Howells
2001-07-03 8:00 ` Jeff Garzik
2001-07-03 8:07 ` David Howells
2001-07-03 11:53 ` Alan Cox
2001-07-07 11:26 ` Geert Uytterhoeven
[not found] <20010702191129.A29246@flint.arm.linux.org.uk>
2001-07-03 8:12 ` David Howells
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=20010702235447.1201@smtp.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=alan@lxorguk.ukuu.org.uk \
--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