Re: [PATCH] VGA arbitration: draft of kernel side

From: Benjamin Herrenschmidt
Date: Tue Mar 08 2005 - 22:59:36 EST


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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/