VGA arbitration: API proposal

[Benjamin Herrenschmidt]

> At the point you are displaying an oops the machine is already in a
> pretty bad way and if the oops hangs the box then it's no worse than the
> oops being lost and the box hanging as occurs now under X.

We have such a low-level "bit banging" text engine on ppc, we use it for
early boot messages, the "xmon" kernel debugger and for oopses & panics.
>From experience, it tends to always work, even when X is doing 2D with
CP acceleration or 3D stuff.

> Time isn't always enough for the wait - on some chips you also need to
> stuff bytes down the data fifo in case a blit from CPU is in progress.
> That is something that can be improved over time and I'm sure the X
> folks have a lot of expertise here.
> 
> >  > app can lock vga we are in deadlock paradise. We may in fact need a
> >  > kernel API on the vga device to "issue vga sequence to device" which
> >  > does the locking entirely in kernel.
> >  > 
> > 
> > Hm, interesting idea. Could this be implemented in a driver transparent
> > way? Meaning just change the PIO functions and handle thing transparently
> > in a library and/or the kernel. Some 'cache' for register accesses?
> 
> Not really because the kernel needs to know which VGA device you are
> talking with. There would also be a bigger performance hit to do that
> than to take an
> ioctl for it. 

Agreed. I'm doing something that will sit in drivers/pci/vga.c for now
with the kernel-side arbitration and I'll be putting together a /dev
interface for experimenting a bit. I don't know if we can get full file
semantics with sysfs (that is the open/release callbacks and struct file
instance) so we can track users properly.

Ben.