[lkml]   [2001]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: The IO problem on multiple PCI busses
    >As a side note, Alpha has a special PCI syscall to get the "PCI
    >controller number" a given PCI device is behind. We could add
    >another ioctl number which does the same thing on /proc/bus/pci/*/*
    >nodes. This way sparc64 and Alpha could have the same user visible
    >API for this as well.

    And on PPC too since I adapted the pci controller mecanism to
    it in 2.4.

    In fact, all that is done by our various syscalls could be done by
    ioctl's on /proc/bus/pci/*/*.

    To be generic, the pci controller number should rather be the pci bus
    number of the host bridge (the top of the PCI tree a given device lives
    on). The internal controller numbers have no real meaning I think to

    Also, an ioctl to retreive the iobase would be useful too (in addition
    to the mmap), especially for getting access to VGA IOs associated with a
    given PCI card, but also for whatever test tool one would want to write
    in userland that access legacy IOs on a given PCI bus.
    Having the mmap is fine, but I like having also the ability to retreive
    all the informations via an ioctl too.

    I beleive that if we can agree on the in-kernel format of the PCI
    controller structure and function to retreive it from a bus number, we
    can make this generic.

    For us, the pci controller requires at least an iobase (physical &
    virtual as we always ioremap the IO space during boot) for generating
    io cycles, the config ops, the mem offset (some platforms don't have
    a 1:1 mapping of memory cycles vs. CPU bus cycles for PCI memory, for
    example, on PReP, you write to physical c0000000 to get a PCI memory
    write to 00000000). And finally the isa memory base (it may be located
    differently, some bridge have 1:1 mappings and so allow only high
    memory addresses to go to the PCI, but do open a "window" at a different
    physical address to generate ISA memory cycles (low address cycles)).

    Finally, we have some private datas (pointer to OF node for example),
    the resource structures (so that we know what a given host bridge can
    decode and can allocate unallocated PCI resources properly).

    I'm not familiar with the requirements of other archs however.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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