lkml.org 
[lkml]   [1999]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.022 / U:0.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site