[PATCH] VGA arbitration: draft of kernel side

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue Mar 8 19:53:18 PST 2005


On Tue, 2005-03-08 at 22:17 -0500, Jon Smirl wrote:
> How do I do the 'disable all, post, renable last active' sequence in
> this scheme?

You don't do it that way. You vga_get(IO|MEM) the card you want to
POST, do the POST, then vga_put().

Subsequent user will get back ownership when it does vga_get(something)
again.

BTW. I have a draft of the userland API. It will be a /dev entry (so
other OSes can implement the same API, also, it's just doing too much
for sysfs, I debated it with a few kernel folks and we decided it should
be that way) :

 *  open	: open user instance of the arbitrer. by default, it's
 *                attached to the default VGA device of the system.
 *
 *  close	: close user instance, release locks
 *
 *  read	: return a string indicating the status of the target.
 *                an IO state string is of the form {mem,io,mem+io,none},
 *                mc and ic are respectively mem and io lock counts (for
 *                debugging/diagnostic only). "decodes" indicate what the
 *                card currently decodes, "owns" indicates what is currently
 *                enabled on it, and "locks" indicates what is locked by this
 *                card.
 *
 *   "<card_ID>:decodes=<io_state>,owns=<io_state>,locks=<io_state> (mc,ic)"
 *
 * write	: write a command to the arbiter. List of commands is:
 *
 *   target <card_ID>   : switch target to card <card_ID> (see below)
 *   lock <io_state>    : acquires locks on target ("none" is invalid io_state)
 *   trylock <io_state> : non-blocking acquire locks on target
 *   unlock <io_state>  : release locks on target
 *   decodes <io_state> : set the legacy decoding attributes for the card
 * 
 * poll         : event if something change on any card (not just the target)


I also added nesting counters (mostly to make things safer, though it could
be useful for scenarios where IRQ stuffs are doing a tryget kind of thing
as described in a previous message).

Ben.





More information about the xorg mailing list