VGA arbitration: API proposal

[Egbert Eich]

Benjamin Herrenschmidt writes:
 > > 
 > > Different PCI-host bridges may map things to
 > > different address areas so that things don't conflict.
 > 
 > Oh, yes, I know that, it even happens on Macs :)
 > 
 > That can be hidden in the arbiter implementation though, via a
 > platform-provided API of the kind of what Alan proposed. And it can be
 > implemented in a second step. That is, we can assume the worst case for
 > now, in order to quickly have a proof of concept, and add fancy
 > "optimisations" like this later on.

Right.
 > 
 > > So you only have to look for resource conflicts for 
 > > resources behind bridges that have overlapping ranges.
 > 
 > Or substractive decoding, or forwarding of VGA IOs enabled, ...

With this we are even able to support one legacy ISA card in X.
Not a big deal today any more but it shows how far we can get.

 > 
 > > You only have to deal with VGA routing issues on
 > > PCI-PCI bridges behind one set of overlapping host
 > > bridges. (unfortunately on x86 and x86-64 HW all
 > > host bridges overlap).
 > 
 > Yes. We are lucky on PPC they tend not to. But that can all be hidden in
 > the implementation of the arbiter.
 >  
 > >  > Sure, that's the preferred way. That's why I introduce that
 > >  > vga_set_legacy_decoding() function so that drivers that go to full
 > >  > non-VGA mode and can disable VGA decoding on the card can happily stop
 > >  > caring. Also, if nobody ever calls vga_get()/vga_put(), there is no
 > >  > problem neither, though It's not something you can rely on as far as the
 > >  > interrupt problem is concern since a VGA card can be hotplugged. It
 > >  > would be possible to deal with this special case scenario if it happens
 > >  > to be very common (that or simply the case of only one card) by
 > >  > introducing a callback mecanism telling drivers to forget about their
 > >  > interrupts and disable them once the "bad" device gets into the system,
 > >  > but that would significantly bloat the complexity of the whole scheme.
 > > 
 > > If we cannot come up with something that would still allow us to
 > > use interrupts even though a bad card is in the system.
 > 
 > Well... if the "good" card can disable it's decoding of legacy space, or
 > at least it's legacy VGA memory space, then it doesn't care about having
 > a bad card around. For example, radeons only really need MMIO, so even
 > if I don't find a way to disable decoding of VGA IO on them, I don't
 > care, I can just leave them with IOs disabled so they won't conflict
 > with a bad card. I just need to check wether I can actually disable
 > decoding of the VGA memory aperture tho. The spec isn't clear and I have
 > no machine at hand on which I can generate VGA memory type cycles (can't
 > on Macs) so it makes it difficult to test.
 >  
 > > Also when a bad card is inserted it is expected to require posting.
 > > This will require a call to get_vga() no matter how legacy free
 > > the card may be otherwise.
 > 
 > Yup. But that's ok. If the "other/good" card doesn't do legacy decoding,
 > then there is no problem giving the VGA lock to the bad one. Again, that
 > all depends on wether the major modern cards (radeons, nvidia's, savage
 > maybe, ...) can disable they legacy decoding, or at least the VGA memory
 > side of it. I'll need to dig out to get an answer there. If we think
 > yes, then it's fine, they'll be able to cope with a bad card around and
 > keep interrupt operations. If not, then we'll need a more complex
 > mecanism, involving either a callback, or the interrupt
 > disabling/postponing thing I described.

Allowing just one 'bad' card in the system may be too restrictive.
If the only bottleneck is interrupt handling, then yes I don't think
there will be a problem. We should be able to deal with more than
one 'bad' card in user space using a 'wrapper' library that wraps
all functions that do harware access. This wrapper function would 
deal with the arbiter, sets locks, makes sure only one function 
enters the critical area at any given time, lets all other calls
wait and makes sure the lock is released on exit.
This function can use short cuts in cases where only one such card
is in the system.
The only problem may be vgacon. We may have to disallow oops logging
to vgacon if we have more than one such card in the system.


 > 
 > > >From the point we enable the newly inserted card until the driver
 > > has taken over we have to expect the worst. X is currently doing this
 > > when it starts up.
 > 
 > We need a mecanism that works at anytime. Think hotplug ...

So we need to allow the assumption that there can be more than one bad
card in the system.

Cheers,
	Egbert.