[Xorg] The big multiconsole nasty

[Jesse Barnes]

On Monday, July 12, 2004 4:00 pm, Alan Cox wrote:
> On Llu, 2004-07-12 at 14:51, Jesse Barnes wrote:
> > In the arch specific in/out routines you mean?  I see lots of lines like
> > inb(0x3c8) in various drivers and other code...
>
> There are some fun problems with the vga module and devices that can
> relocate their vga registers too as with the SiS driver (and some good
> discussion in the driver code)

Ooh, fun.

> > in/out is pretty slow already, and is only used at startup time, afaict. 
> > Most code just does memory reads/writes to register space doesn't it?
>
> In iopl(3) mode out and in are pretty fast (obviously not as fast as
> posted PCI mmio).

But do any drivers use it as their primary mechanism for talking with their 
device?  At any rate, I think we can do it in such a way that in/out 
performance isn't adversely affected.

> > Yeah, I'm looking at the ia64 stuff, it's still missing the necessary
> > support. It looks like ppc is still limited to doing legacy I/O (like the
> > above inb) to one bus.
>
> Same with the IBM x440 if you use legacy addressing

On sn2 at least, we're not prevented by hardware from doing legacy I/O to 
multiple busses at the same time, I wonder if other platforms are the same?  
I seemed to gather from talking with benh that ppc could do better if given 
the chance...

So, in short, unless there are problems, I'd like to see things like

  val = inb(0x3c8)

changed to

  iobase = xf86GetLegacyIOBase(Tag);
  ...
  val = inb(iobase + 0x3c8)

*or*

  val = inb(Tag, 0x3c8)

(The latter would probably be slower, as was already mentioned.)

Is that possible?  It seems like we could move the current iopl(3) stuff to 
that function.  On x86, that'd be pretty much all that function did, but on 
other platforms it would allow per-device legacy I/O spaces.  I don't think 
it would hurt drivers like SiS either, since they'd just be changing the 
constant they added to the iobase variable, rather than the base itself, 
right?

Jesse