Messages in this thread | | | Date | Fri, 6 Aug 1999 06:24:26 -0700 | From | "David S. Miller" <> | Subject | Re: New resources - pls, explain :-( |
| |
Date: Fri, 6 Aug 1999 15:06:23 +0200 (CEST) From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
On Thu, 5 Aug 1999, Martin Mares wrote: > Yes, the generic PCI code will allocate everything.
How does a device know the region is not in use, if the generic PCI code takes care of that?
If you care that much about I/O and MEM resource usage, you can indeed get what you want. Look at how check_region works now, the I/O port top-level parent always exists, and represents the whole space.
When a check_region is done, it's carving out a "piece" of the I/O port top-level parent space and marking that "piece" as in-use. It makes a new resource to represent this, and hangs it as a child of the root.
Actually, it hangs it as a child of the "least specific" parent, so you could nest these things arbitrarily, so as to represent things like:
MEM space [0x00000000 --> 0xffffffff] my card [0x00100000 --> 0x00200fff] sram buffer A [0x00100000 --> 0x0017ffff] sram buffer B [0x00180000 --> 0x001fffff] control registers [0x00200000 --> 0x00200fff]
You get the idea. In fact, I have just this situation on my UltraSparc right here, the EBUS is what Sun uses as a bridge between PCI and the "ISA like" devices (mostly a NatSemi chip with floppy controller, serial ports, etc.) and that portion of /proc/ioports looks for me like:
fffff9fff1000000-fffff9fff17fffff : EBUS fffff9fff1000000-fffff9fff1001fff : clock fffff9fff1200000-fffff9fff120003f : cs4231 regs fffff9fff13062f8-fffff9fff13062ff : su(mouse) fffff9fff13083f8-fffff9fff13083ff : su(kbd) fffff9fff1400000-fffff9fff140003f : serial(sab82532) fffff9fff1400040-fffff9fff140007f : serial(sab82532) fffff9fff1702000-fffff9fff170200b : 4231 playback DMA fffff9fff1704000-fffff9fff170400b : 4231 capture DMA fffff9fff1706000-fffff9fff170600b : floppy DMA fffff9fff1726000-fffff9fff1726003 : LED auxio
Later, David S. Miller davem@redhat.com
- 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/
| |