Re: Reusing existing VGA text mode-setting functions

[Steffen S. <se...@ph...>]

Rodolphe Ortalo wrote:
> 
> First, thanks for all your answers Steffen (not only this thread). They
> very helpful (as usual).
> 
> On Mon, 9 Apr 2001, Steffen Seeger wrote:
> > Rodolphe Ortalo wrote:
> > The Permedia driver defines a vga driver (pgc->vga) which is actually only
> > the state info for the VGA vga_chipset driver (VGA-meta.{c,h})
> >
> > This is handled in the binding driver (PERMEDIA-bind.c), which provides
> > MMIO based I/O routines to access it's VGA core.
> 
> > No. All resources required to do the I/O are claimed by the Matrox driver,
> > and it knows what to do so that it doesn't need VGA ports to access it's VGA
> > core. E.g. if you can use a VGA core by MMIO, provide state info in the
> > chipset driver (make sure vga state comes first) and the proper routines
> > in the binding driver. Then claim the memory aperture in chipset_init()
> > and you are operational.
> 
> What do you mean by "make sure the vga state comes first" ? I see the
> vga struct member is the first (in pgc_chipset_io_t): is this
> mandatory? vga is also the first struct member after the kgim_chipset_t
> "chipset" type in struct pgc_chipset_t - is it also mandatory? (If so,
> why btw?)

The vga driver calls its I/O routines with a vga_chipset_io_t context.
What is actually called are the pgc_chipset binding driver routines. 
Thus the binding driver needs to be sure this is actually a
pgc_chipset_io_t. In order this to be the case, the vga IO state has to come
first.

For the chipset_t itself there are no call-backs possible so far, so here
vga_chipset_t comes first just for consistency. However, it makes more
obvious that your driver relies on the VGA core driver
to handle the VGA stuff.

> > >  * Assuming such conflicts exist is it needed to de-activate the first VGA
> > > card io ports before insmod-ing the second card module to solve these
> > > conflicts ? How can you do this ?
> >
> > Yes and no. If you can wake up disabled hardware without ever requiring standard
> > VGA port access (like the Permedia does) do it, and there will never be
> > any VGA port conflicts.
> 
> Hmmm, do you think that the G400 card (AGP) will be left totally
> unitialized (aside from PCI init) after booting on a S3 card (PCI) with
> the "PCI/AGP" boot sequence set in the BIOS ?

Yes. Every card I have seen so far is. Just try.

> [Also looking at my G400 documentation...]
> 
> It seems all VGA registers are accessible via a MMIO aperture that is
> setup via the PCI configuration space... Do you think it is adequate ?

Yes.

> In fact, it seems the thing is rather similar to the way the PERMEDIA
> operates (as I understand it from your driver source files).
> 
> MGC_VGA_BASE is MGA_CONTROL_BASE(PCI) + MGA_VGABase(1F00h) + C0h
> on the Gx00 apparently.

So you can probably easily adopt the PGC vga bindings.

> Hmmm, not totally, the "Palette RAM" (3C6,7,8,9h for VGA I suppose) is
> accessible somewhere else... Is this similar to the kind of special case
> you do for the DAC subsystem in PERMEDIA-bind.c ?
> In fact, this "PGC_VGA_DAC" is the last thing I don't really understand I
> think.

Depending on the operation mode (graphics controller or VGA compatible core)
you have to access the DAC either through the VGA core or the extended
DAC registers in the control aperture.

In pgc_chipset_setmode(), the chipset hardware is prepared to respond
to either the VGA or enhanced DAC and pgc_io->flags are set properly so the
DAC routines work as intended.

> > PS> This design allows you to stack those things. E.g. imagine I have a
> > new chip (like the Matrox G450) which actually implements two cores of the
> > same desing on one chip.
> > I write a driver for one core (the meta driver) (which reuses the VGA core).
> > Then I make a binding driver which actually instantiates two cores, sets
> > the I/O functions properly for the VGA core, the G400 cores and that's it.
> 
> Hmmm. Maybe I should write a G200 driver then. It seems the G400 is a
> superset of the G200... ;-) But well, first, let's start with the VGA
> core... :-)

One step after the other. Suddenly you can walk. And then run.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...
TU-Chemnitz                                      http://www.tu-chemnitz.de/~sse