Re: New resources - pls, explain :-(

David S. Miller (davem@redhat.com)
Fri, 6 Aug 1999 06:24:26 -0700


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/