From: Paul Mackerras <paulus@linuxcare•com.au>
To: Dan Malek <dan@mvista•com>
Cc: Linux/PPC Development <linuxppc-dev@lists•linuxppc.org>
Subject: Re: __ioremap_at() in 2.4.0-test9-pre2
Date: Thu, 21 Sep 2000 13:35:28 +1100 (EST) [thread overview]
Message-ID: <14793.29680.948198.119368@argo.linuxcare.com.au> (raw)
In-Reply-To: <39C96EBC.6BE23535@mvista.com>
Dan Malek writes:
> No, I mean the evolution of address maps of platforms has resulted
> in holes, restrictions, and just some weird things unique to any one
> of them.
At the physical address level? Can't we hide that at the virtual
address level?
> People make assumptions that a particular device always
> resides at a certain address, so they either hard code that or take
> short cuts based upon those assumptions.
If you have a super-I/O chip with a serial port at I/O address 0x3f8
(for example), you just have to know that number, there's nothing that
is going to tell you.
> As others have mentioned, we don't use all of the drivers in this
> manner. There are some legacy drivers that have worked well given
> the PReP/CHRP/PMac mapping hacks we have done in the past. With the new
> PowerMacs in particular, we now have a few drivers that need a little
> more work. As I said, I have updated some of these.
Which ones in particular?
> I mean everywhere. The PCI (or ISA, or any bus) should have a resource
> map (or data base or whatever you want to call it) of devices, addresses
> and attributes. A driver should ask for these to be mapped (at some
> arbitrary virtual address) and then use the supplied virtual address.
Thereby assuming that all I/O is memory-mapped, making the driver
non-portable to intel machines.
> A driver should never simply 'inb(SERIAL_PORT_STATUS)' using some #define,
Why not?
> I don't think I would call it "tricks", but we need some layers of
> translation and flexibility. The "trick" you have been proposing for
> PMac will work fine there, but won't work many other places because
> the bridges or systems don't have the flexibility. My point is that
Huh? All I am proposing is that we set up the virtual -> physical
mapping in a certain way. The I/O space of a host bridge has to be
accessible somewhere in the physical address space, that's the only
way it can be accessible. If the bridge connects the address lines up
in a strange way (e.g. the prep mapping option which puts 64 (I
think?) ports in each 4kB page) then inb/outb will have to cope with
that. I hope it doesn't become necessary.
> you can do that on the PMac, but that assumption shouldn't find it's
> way into the in/out read/write macros. The in/out macros should either
> map to in/out x86 instructions, or simply a memory access with any
> barrier instructions necessary. When a driver asks for the address of
> that serial port on PCI bus 1, you can give them the 0xff10xxxx address.
No, that's broken. That's what I don't want. That's an extra
unnecessary incompatibility with intel. Like it or not, not all
devices are PCI, and most drivers are developed and tested on intel
machines.
> When that same driver asks that question on a 8260 with PowerSPAN PCI
> bridge, it will get a very different address. In this latter case,
> if they ask for the serial port on PCI bus 2, they are likely to get
> something that isn't even a reasonable address calculation from the
> previous. Done correctly, you could even make some drivers switch from
> using I/O space to using memory mapped space, depending upon how the
> system resources can be allocated, without changing the driver.
> Unfortunately, too much of this information is coded into drivers today.
The access functions for PCI memory space will always be distinct from
the access functions for I/O space, because intel uses different
instructions. Sorry.
> Although it doesn't result in portable drivers, people have asked to
> get ready to use mapped addresses to devices so they can manage their
> own memory barriers and take advantage of deep FIFOs in bridges for
> throughput rather than use any of the I/O macros. This would also
> allow it.
That's fine for devices with registers in PCI memory space. For
registers in PCI I/O space there are more constraints which mean that
you can't do these optimizations.
Paul.
--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare•com.au, http://www.linuxcare.com.au/
Linuxcare. Support for the revolution.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-09-21 2:35 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-17 18:59 __ioremap_at() in 2.4.0-test9-pre2 Geert Uytterhoeven
2000-09-19 3:59 ` Paul Mackerras
2000-09-19 5:56 ` Michel Lanners
2000-09-19 14:28 ` Dan Malek
2000-09-19 18:31 ` Roman Zippel
2000-09-19 20:09 ` Dan Malek
2000-09-19 23:42 ` Roman Zippel
2000-09-20 0:10 ` Dan Malek
2000-09-20 17:18 ` Roman Zippel
2000-09-20 18:11 ` Dan Malek
2000-09-20 20:22 ` Roman Zippel
2000-09-20 20:41 ` David Edelsohn
2000-09-21 2:16 ` Dan Malek
2000-09-21 2:26 ` David Edelsohn
2000-09-21 2:40 ` Dan Malek
2000-09-21 3:53 ` David Edelsohn
2000-09-19 22:06 ` Matt Porter
2000-09-19 22:58 ` Paul Mackerras
2000-09-20 6:12 ` Matt Porter
2000-09-20 12:15 ` Geert Uytterhoeven
2000-09-20 23:08 ` Paul Mackerras
2000-09-21 20:12 ` Matt Porter
2000-09-20 8:34 ` Roman Zippel
2000-09-20 22:54 ` Paul Mackerras
2000-09-20 15:56 ` Dan Malek
2000-09-20 23:22 ` Paul Mackerras
2000-09-21 2:13 ` Dan Malek
2000-09-21 2:35 ` Paul Mackerras [this message]
2000-09-21 3:57 ` Dan Malek
2000-09-21 5:06 ` Paul Mackerras
2000-09-21 6:51 ` Dan Malek
2000-09-21 14:03 ` Geert Uytterhoeven
2000-09-21 22:40 ` Benjamin Herrenschmidt
2000-09-22 3:53 ` Dan Malek
2000-09-22 11:58 ` Geert Uytterhoeven
2000-09-22 18:46 ` Dan Malek
2000-09-22 20:06 ` Frank Rowand
2000-09-23 21:38 ` Matt Porter
2000-09-21 20:22 ` Matt Porter
2000-09-22 3:49 ` Paul Mackerras
2000-09-22 4:16 ` Dan Malek
2000-09-23 12:34 ` Geert Uytterhoeven
2000-09-27 10:37 ` Benjamin Herrenschmidt
2000-09-28 9:59 ` Geert Uytterhoeven
2000-09-28 19:19 ` Benjamin Herrenschmidt
2000-09-28 23:33 ` Benjamin Herrenschmidt
2000-09-29 5:08 ` Dan Malek
2000-09-29 11:37 ` Geert Uytterhoeven
2000-09-29 17:12 ` Kostas Gewrgiou
2000-09-29 17:18 ` Benjamin Herrenschmidt
2000-09-29 21:35 ` Michel Lanners
2000-09-30 0:11 ` Matt Porter
2000-09-29 0:22 ` Paul Mackerras
2000-09-29 0:40 ` Benjamin Herrenschmidt
2000-09-29 1:17 ` Paul Mackerras
2000-09-29 4:22 ` Dan Malek
2000-09-29 4:29 ` Dan Malek
2000-09-29 4:36 ` Paul Mackerras
2000-09-29 5:40 ` Dan Malek
2000-09-29 19:07 ` Frank Rowand
2000-09-30 1:39 ` Paul Mackerras
2000-09-30 22:50 ` Frank Rowand
2000-10-01 1:09 ` Dan Malek
2000-10-01 8:16 ` Paul Mackerras
2000-10-01 21:30 ` Dan Malek
2000-10-01 22:50 ` Paul Mackerras
2000-10-02 9:04 ` Dan Malek
2000-09-28 23:24 ` Frank Rowand
2000-09-21 13:44 ` Geert Uytterhoeven
2000-09-21 22:41 ` Benjamin Herrenschmidt
2000-09-22 21:59 ` Michel Lanners
2000-09-20 12:08 ` Geert Uytterhoeven
2000-09-20 16:31 ` Matt Porter
-- strict thread matches above, loose matches on Subject: below --
2000-09-21 7:30 Iain Sandoe
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=14793.29680.948198.119368@argo.linuxcare.com.au \
--to=paulus@linuxcare$(echo .)com.au \
--cc=dan@mvista$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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