Re: [patch 2.6] remove PCI_BRIDGE_CTL_VGA handling from setup-bus.c

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2005-07-15 at 01:46 +0400, Ivan Kokshaysky wrote:
> On Thu, Jul 14, 2005 at 10:07:34AM -0400, Jon Smirl wrote:
> > I'm don't think it has ever been working in the 2.6 series. If you are
> > getting rid of it get rid of the #define PCI_BRIDGE_CTL_VGA in pci.h
> > too since this code was the only user.
> 
> No. The PCI_BRIDGE_CTL_VGA is not something artificial, it just describes
> some well defined hardware bit in the p2p bridge config header, so anyone
> working on VGA switching API will have to use it.
> 
> > This code is part of VGA arbitration which BenH is addressing with a
> > more globally comprehensive patch. Ben's code will probably replace
> > it.
> 
> Yes, I've heard Ben is working on this, but I've yet to see the code. ;-)
> Any pointers?

I posted an early untested implementation a while ago (I don't have it
at hand sorry) and then got distracted by other things. I'll be back on
it soon though. The main "issue" I have at the moment isn't the arbiter
itself, which is not too tricky, but making things cooperate with him.
That is mostly

 - Console subsystem &| vgacon. That needs some serious work to deal
with the fact that the HW may not be accessible due to arbitration
issues. I'm considering replacing the trylock() on the console semaphore
by a per-console lock() callback here, though I yet have to decide what
happens to data in the printk buffer if you have, for example, 2 console
drivers, one of them "eats" the data, but the second one fails (returns
-EAGAIN due to lost arbitration).

 - Existing X servers & other apps using fbdev and mmap'ing /dev/fb*
directly. The current fbdev API provides no arbitration mecanism and
existing X servers just bang the hardware and toggle VGA routing
directly. To work around that, I've started toying with the VT mode.
That is, define a new KD_GRAPHICS_NEW mode that is equivalent to today's
KD_GRAPHICS, and have the "old" KD_GRAPHICS "disengage" the arbiter.
When leaving the later mode, the arbiter should "recover" from whatever
userland and/or X did.

While I've been thinking about these & possible solutions, I didn't have
time to write any actual code. Without solving those issues, though, a
VGA arbiter is fairly useless.

Ben.


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