VGA arbitration: API proposal

Benjamin Herrenschmidt benh at kernel.crashing.org
Fri Mar 4 18:15:49 PST 2005


> 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 ? 

> This API is needed to properly POST multiple VGA cards per-bus,

Yes, that and more, like X using a legacy VGA card while your other card
is in non-legacy mode taking irqs ... kaboom ! as mentioned by Jon, and
other subtle issues like that.
 
>  but it would 
> be *really* nice if we could avoid using VGA at all after POSTing has been 
> done (i.e. use the fb drivers instead of vgacon, don't use VGA ports from X 
> space, etc.). 

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.

> Of course that assumes that the full functionality of every 
> display devices that we care about is a proper superset of the functionality 
> they provide as VGA services, otherwise we'd be giving something up by 
> dropping VGA based services.

Ben.





More information about the xorg mailing list