Re: Exposing ROM's though sysfs

[Benjamin Herrenschmidt]

On Wed, 2004-08-04 at 11:37, Jon Smirl wrote:
> Ben, can you put together a first pass on a "VGA arbitration driver"?
> You probably know more about the quirks necessary on non-x86 platforms
> than anyone else. I can help from the desktop x86 side but I've never
> worked on high end hardware that allows things like multiple active VGA
> devices. I'm sure the Mac machines and ia64 systems will need some
> special code too.

At this point, even the kernel doesn't have internally the necessary
platform hooks for dealing with multi domains legacy port IOs or
VGA memory space, it's all plaform hacks. But we can define an API at
least for userland and fix the kernel driver afterward.

I'm fairly busy this week, so it would be nice if you guys could come
up with some rough idea of the API you think the kernel driver should
provide (a /dev entry with ioctl's ? Linus won't be too happy ... something
in sysfs ?) and I can sit down & code something hopefully next week end
and/or next week.

Jesse did a pretty good summary of what features need to be provided
though. Note also that this "arbitration" layer may also need an in-kernel
API for things like vgacon or whatever may want to "grab" access to the
VGA device.

I suggest that at this point, we don't try to bother with simultaneous
access to devices on separate PCI domains, but just use an in-kernel
semaphore to arbitrate the single user at a given point in time who "owns"
the VGA access, whatever bus it is on. So we need 2 things, both in-kernel
and for userland:

 - A way to identify a VGA device on a given bus. Could this be a PCI
ID (or in kernel a pci_dev ?). That would mean no support for non-PCI stuffs,
how bad would that be ? Or we can try to be more smart and have userland
pass an ID string that contains the bus type, leaving us with some room
for accomodation of crappy bus types (read: embedded).
Maybe we just need to add to any entry in sysfs that is a VGA device some
kind of "vga_token" attribute that contains a "magic string" to be then used
with the driver for identification purposes ? For in kernel, we then just
use the pci_dev, with a special case for "legacy non-PCI" VGA ?

 - Basic API for grabbing/releasing the VGA lock, passing a given ID. This
would both take the exclusive access lock, and "set" IOs to the given device
(enable IOs to it). The API doesn't prevent future implementation of per-domain
locks if we want to have some concurrency here, though I feel that's useless.
The kernel-side is simple, the userland side could be an ioctl (hrm....).
However, should it be blocking or of trylock kind ? I don't like the idea of
userland beeing able to block the kernel (vgacon or whoever else in the kernel
need to do legacy IOs). Also, some console drivers still need to run in
'atomic' environment, though we did move a lot of things down to normal
task protected by the console semaphore, the printk and blanking code path,
afaik, are still a problem. So a simple semaphore may not do the trick. We
could simply abuse the console sem instead for now as our VGA lock, which means
that an fb driver would alwyas be called with the lock already held... but then,
we still need a call to "set"  the current active VGA device while already
owning the lock... I liked the idea of having one single call doing both.
Alan, what is your opinion there ?

 - In kernel API for vga_inX/outX and vga mem access on a given device

 - Userland should use read/write for IOs imho, either to a /dev device
(with maybe an ioctl to switch between PIO and VGA mem, though mmap is
better for the later) or to some sysfs entry (in which case, can we add
mmap call to a sysfs attribute ? last time I looked, it wasn't simple).

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/