struct resource ioport_resource = { "PCI IO", 0x0000, 0xFFFF };
^^^
struct resource iomem_resource = { "PCI mem", 0x00000000, 0xFFFFFFFF };
^^^
- PCI I/O is really ISA I/O (or: you cannot distinguish between both).
Technically this is not 100% correct, but that's the way it works.
- You have `memory accesses' (on the memory bus) and `I/O accesses' (on the
I/O bus). So one can says we need two resource allocation lists only:
`I/O space' and `memory space'.
Things may be different for architectures where accessing different memory
spaces requires different methods (e.g. the reason why readb() and friends
are needed). So one can claim there are three spaces: `port I/O space',
`memory I/O space' and `system memory space'. YMMV and some of them may be
collapsed together (yielding one unified space on PPC).
- Both are CPU specific. Many CPUs (e.g. m68k, PPC) don't have separate `I/O
accesses', they have memory mapped I/O only. But that's a hardware issue
and doesn't matter here.
- readb() and friends must be used on all kinds of memory mapped I/O, not
only for PCI, and should follow the endianness of the accessed space
(that's what I've been discussing about a lot with Davem).
But now Linus claims all these things are for PCI only?? What should I use
for other busses then?? Don't forget there are many drivers that work for
the same device connected to different busses.
- Linus says I/O space has 64K entries, and memory space has 4GB entries.
In the mean time 32 bit I/O space showed up in the thread. What about
busses with a 64-bit memory space (64-bit PCI)?
- Instead of `peanuts', I'd vote for `io' and `memory' :-)
Calling it `PCI' is confusing, since there are machines without PCI
busses, and machines with PCI and other (SBUS, Zorro) busses in one box.
Well, in the mean time it became `ioport_resource' and `iomem_resource',
which is fine for me, except for the "PCI IO" and "PCI mem" strings.
- Currently the resource lists are for allocated resources only, right? At
some point the discussion moved towards lists for all present devices,
whether they have an activate drive or not. Then we would have something
like the Open Firmware device tree (cfr. /proc/device-tree/ on PPC). Nice!
P.S. In contrast with what you might think from some of my notes, I strongly
like the idea behind this. Finally we have a request_region() for non-I/O
space!
This means I can get rid of the zorro_{config,unconfig}_board() calls.
And suddenly my headache about offb (the Open Firmware frame buffer
device) and a chipset specific frame buffer device driver wanting to
control the same board is over...
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/