VGA arbitration: API proposal

[Benjamin Herrenschmidt]

On Fri, 2005-03-04 at 23:46 -0500, Jon Smirl wrote:
> There is no real reason to be using VGA in current machines. Could we
> take this concept further and separate all cards into two piles:
> require VGA or can live without it. The obvious exception to this is
> during the post process.

In fact, it's a bit more convoluted. With cards like ATIs, we don't
need VGA, _but_ the card may still be decoding legacy VGA accesses on
the bus, and thus harm another VGA card in the machine. We must make
sure we can disable that properly.

Anyway, what is wrong with my API proposal ? It's simple and should do
the job for all our needs, no ?

> So my simple idea is:
> mark all drivers as VGA or not
> only allow a single card in the system that is marked as requiring VGA

Well, what is the difference with what I proposed ? Again, you have to
take into account cards that don't necessarily need VGA but may still
conflict on the bus due to their decoding of the VGA space.

By default, we assume they all do, thus they all get turned off (IO/MEM)
when somebody requests VGA access (vga_get()).

Drivers can call vga_set_legacy_decoding() to indicate they have
disabled VGA decoding on the card and it's safe to "ignore" it from now
on. I added the additional subtlety of separating VGA IOs from VGA
Memory accesses, since those are separate things, that can be
enabled/disabled separately, and not all drivers need both (iirc, a 3dfx
lives well with MMIO for the aperture and VGA IOs for the registers,
no ? Or can the registes be remapped too and VGA IO decoding be
disabled ?)

> require fbdev/fbcon on the non-VGA cards
> the first card that arrives requiring VGA get VGAcon

How do you know who "require" what ?

Again, what's wrong with my proposal ? It's simple and should deal with
all our needs. I'll try to implement something in the kernel with
appropriate userland library if I get some time next week (i'm currently
busy rewriting radeonfb :)

> build whatever is needed to get through the post process for non-VGA cards
> if there is a second VGA required card, print a big message and refuse to boot
> discourage any further writing of code that uses VGA

Why just drop support for existing working setups while it's rather
simple to do the arbitration properly ? Besides, VGA/VESA is a quite
useful fallback setup for diagnosing a config with problems. Even
Windoze can do that :)

> PCI Express is really going to aggravate this problem.

Are legacy cycles still allowed on PEX ? I'm afraid that since it's an
Intel standard, such cruft might still be there :(

> With the
> NForce4 there are now motherboards that support four 16x slots and the
> Nvidia expansion chips allow motherboards to be built with 16 16x
> slots (would have to be quad Opteron). I suspect the next generation
> of low end chipsets will support two 16x slots.
> 
> Long term I'm not in favor of the ruby approach of modifying the
> kernel for multiple consoles. Instead I would like to kick the console
> out to user space where we can have as many as we want. The in-kernel
> console would then be reserved for things like system recovery, OOPs,
> sysReq, kernel debugger, etc... instead of normal logins. We already
> have user space consoles today -- xterms.

Wether we are talking with kernel consoles or user consoles, the problem
of VGA access remains the same. Let's be constructive now, please
comment on my proposal, and if you have nothing to object, let's try to
make it a reality.

I don't know what's up with the various BSDs, so I'll need help from BSD
folks to do the BSD kernel side if any is needed.

Ben.