VGA Arbiter

[Jesse Barnes]

On Friday, October 26, 2007 6:48:06 pm Tiago Vignatti wrote:
> Hi Jesse, how are you?! Thanks to answer this quickly. It's very
> valuable to us.

Well, I'm glad you're doing this work, I'm happy to help! :)

> Jesse Barnes escreveu:
> > On Friday, October 26, 2007 12:17 pm Paulo Ricardo Zanoni wrote:
> >> The problem is that we're still trying to understand everything =)
> >> The code is a little complicated and we've never played with PCI
> >> stuff. So we want to hear your opinions if we're going on the right
> >> way.
> >
> > I can't see the code now, but I'm pretty sure you'll need a platform
> > hook so that different architectures (possibly with weird host<->pci
> > bridges) can route VGA correctly.  And of course for generic PCI
> > bridges the standard VGA routing bits can be used.  For two devices on
> > the same bus, I guess you'll need specific device drivers to
> > enable/disable VGA code (not sure about this part)?
>
> humm, what's the best way to see how is the PCI architecture of my
> machines? I just typed `ls /sys/bus/pci/devices/0000\:0*` in four
> machines here and all appeared a lot of device in the same bus but one
> or two in another one (and the domain, was always the same as you can
> see in the ls). So, this mean that I can assume the generic PCI routing
> could be in this form?

lspci -t gives you a nice tree view.  Yeah, I think the routing could be in 
the same form.  Since the VGA registers are just I/O ports, you need to both 
route them to the right PCI bus (this is sometimes a platform specific thing) 
and make sure the right card on that bus is responding to them (I think this 
may be card specific?  Or maybe there are generic I/O ports you can use to 
enable/disable VGA decode).

>
> >> To use the /dev interface you just write strings on the device and
> >> the kernel interprets it and does what it has to do. The interface is
> >> very simple and is explained at vgaarb.c:520 (kernel module code). It
> >> was originally written as part of the kernel, but we made it a module
> >> (to make easier to compile and test). The problem is that string
> >> comparing inside the kernel does not have too much performance.
> >
> > Having the device driver take an ioctl that has a PCI ID in it might be
> > a better interface (assuming PCI is all we want to support).
>
> yeah, this could be easily implemented. We're using the char device
> cause BenH initially started in that manner.

Yeah, a char device is fine, I was just trying to think of a way to avoid 
using string parsing.

> >> The xserver code is actually a modification in the RAC code. We
> >> wrapped the video driver calls with with "get_lock" and "put_lock".
> >> This is really not what should be done, it is just the easier way to
> >> test if things work. Currently, it is not working and we're studying
> >> X's code to see what we did wrong (maybe the problem is in the Kernel
> >> module).
> >
> > Can the code just be hidden away in vgahw?  Or are there lots of drivers
> > that bang on the VGA regs directly too?
>
> As Paulo said, initially we just used the same code of RAC to wrap all
> that functions which calls vga. But we don't know for sure if that is
> sufficiently. We also traced the code and saw that others functions --
> which is not wrapped by RAC -- like xf86EnableAccess() and
> xf86ActiveResources() also deal with vga things.

Yeah, I'm not sure what else is needed in the X server...

Jesse