VGA arbitration: API proposal

Egbert Eich eich at freedesktop.org
Sat Mar 5 13:08:52 PST 2005


Benjamin Herrenschmidt writes:
 > 
 > > Seems to make sense to me--you really do have to introduce the concept of a 
 > > VGA owner for cases where multiple VGA cards share the same bus or legacy 
 > > I/O/mem decode segment.  In that sense, it complements the existing 
 > > legacy_io/mem API presented by sysfs.
 > >
 > > Might be nice if the  vga_set_legacy_decoding routine also returned the 
 > > addresses of legacy I/O and memory space for that card.
 > 
 > How so ? The legacy stuff may be at different places ? 

Different PCI-host bridges may map things to
different address areas so that things don't conflict.

So you only have to look for resource conflicts for 
resources behind bridges that have overlapping ranges.
You only have to deal with VGA routing issues on
PCI-PCI bridges behind one set of overlapping host
bridges. (unfortunately on x86 and x86-64 HW all
host bridges overlap).
 > 
 > Sure, that's the preferred way. That's why I introduce that
 > vga_set_legacy_decoding() function so that drivers that go to full
 > non-VGA mode and can disable VGA decoding on the card can happily stop
 > caring. Also, if nobody ever calls vga_get()/vga_put(), there is no
 > problem neither, though It's not something you can rely on as far as the
 > interrupt problem is concern since a VGA card can be hotplugged. It
 > would be possible to deal with this special case scenario if it happens
 > to be very common (that or simply the case of only one card) by
 > introducing a callback mecanism telling drivers to forget about their
 > interrupts and disable them once the "bad" device gets into the system,
 > but that would significantly bloat the complexity of the whole scheme.

If we cannot come up with something that would still allow us to
use interrupts even though a bad card is in the system.
Also when a bad card is inserted it is expected to require posting.
This will require a call to get_vga() no matter how legacy free
the card may be otherwise.
>From the point we enable the newly inserted card until the driver
has taken over we have to expect the worst. X is currently doing this
when it starts up.

Egbert.




More information about the xorg mailing list