VGA arbitration: API proposal

[Benjamin Herrenschmidt]

On Sat, 2005-03-05 at 22:08 +0100, Egbert Eich wrote:
> Benjamin Herrenschmidt writes:
>  > 
>  > > Seems to make sense to me--you really do have to introduce the concept of a 
>  > > VGA owner for cases where multiple VGA cards share the same bus or legacy 
>  > > I/O/mem decode segment.  In that sense, it complements the existing 
>  > > legacy_io/mem API presented by sysfs.
>  > >
>  > > Might be nice if the  vga_set_legacy_decoding routine also returned the 
>  > > addresses of legacy I/O and memory space for that card.
>  > 
>  > How so ? The legacy stuff may be at different places ? 
> 
> 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.

> 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, ...

> 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.

> >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 ...

Ben.