> Allocating the entire device strikes me as extremely limiting.
I didn't say it's the only possibility :-)) Anyway, it's fine for
most cases.
> parport already needs to share the same parallel port,
Think of parport as of a bus with virtual devices corresponding to
the devices daisy-chained on the parport.
> and the stuff I
> am interested in -- VGA and video drivers -- often wind up needing to
> share the VGA ports. In order to support multiple VGA cards in a single
> machine, I do this
>
> pci_disable_other_vga_card_io_regions()
> pci_enable_my_vga_card_io_regions()
>
> { the fb driver does some VGA port I/O }
>
> pci_disable_my_vga_card_io_regions()
> pci_enable_other_vga_card_io_regions()
VGA ports certainly cannot be handled as ordinary PCI I/O ports since they
don't obey any sane rules. Support of multiple VGA cards is a nightmare
and basically it's going to contain a lot of card-dependent code and be
handled by an extra kernel module. No need to encumber the generic resource
management stuff with this.
> This is definitely important, as one particular S3 card will report its
> MMIO region as 32 MB instead of the correct 64 MB.
Yes, this is exactly the case where we need to relocate a PCI card
even in a non-hotplug environment. Anyway, except for such cases we should
avoid PCI relocation as otherwise we'd have to know about all non-standard
host bridges.
> Slightly off topic: What about AGP? Is any work or planning going on
> in that direction? I know it's compatible with PCI, but there don't
> seem to be any constants in the kernel yet for accessing the new
> configuration commands and such.
From the configuration point of view, AGP is identical to PCI. Maybe
generic AGP access routines will appear one day, but for now I know of
no driver needing it.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "MIPS: Meaningless Indicator of Processor Speed."- 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/