Messages in this thread | | | Date | Fri, 30 Jul 1999 15:46:47 +0200 (CEST) | From | Geert Uytterhoeven <> | Subject | Re: New kernel/resource.c |
| |
I just read the whole discussion and wanted to share a few comments with you. Please forgive me for the `itemized' style, but I wrote the comments while following the thread.
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/
| |