On Mon, Nov 29, 1999 at 10:28:41AM +0100, Steffen Seeger wrote:
> > >
> > > * Don't use pcicfg space for other purposes than initial configuration.
> > > Especially do not use it in _mode_setup() to distinguish device versions.
> > > Use flags or a chipset_version field in the <meta>_t structure instead.
> > >
> >
> > A question on this.
> >
> > Is it sugested that I detect the vendor/device id and revision once in the
> > chipset bind code only, and then somehow share that data with the ramdac and
> > clock code, or should I probe this in every <meta> driver?
>
> Neither nor. vendor/device id and revision should be probed in
> the chipset binding driver and the ramdac binding driver if it is an integrated
> ramdac. All code in the binding driver has to 'bind' the meta driver to
> a particular instance of the device(s) handled by the meta driver.
> Therefore it has to do detection and verification.
>
> Chipset drivers must verify the vendor/device ID and ramdac drivers should
> do this, if the chipset driver may serve at least one device that does not
> have this ramdac fitted.
>
> > In this specific case, I also need to know the RAM type, since the cards
> > clock capabilities vary from RAM type to RAM type.
>
> Can you give some more details on this? How do the clock capabilties vary
> between the RAM types? If it only affects the RAM bandwidth, or LCLK limits,
> this can safely be handled in the chipset drivers.
>
> > now I have this
> > implemented as a flag in _chipset_t, but I'm not aware of how to share this
> > with the other sections, like the GET_PRIVATE does in KGIcon.
>
> Not at all. Each driver should not make assumptions about others, except
> where a kgim_ metalanguage type (e.g. kgim_monitor_mode_t) is defined.
> This requires some proper thought, but should be possible.
>
Ok, here we go.
The 1x64 and the Gx00 series can be fitted with either SGRAM or SDRAM. If
SGRAM is fitted, I can write a register in the PCI OPTION register to set
enhanced memory access, since the SGRAM contains a block mode operator that
the SDRAM does not contain, setting this bit can speed up things like the
BLT engine by an order of magnitude, so it's definitly a wanted feature.
The 1x64 has only been made in SGRAM version as far as I know, but I have to
destinguish between three known revisions (1-3), where dclk.max and fvco.max
differ between the revisions. (also, in revisions prior to 3, the control
and frambuffer regions were not swapped, as they are on all later cards)
the G100 I have no specifications for, but I know the board exists in both
SDRAM and SGRAM versions, and dclk.max, fvco.max and the system clock
itself, differ between the cards with the various memory types.
The G200 can have either SDRAM and SGRAM, the dclk.max and fvco.max differ
between the two, beeing 230Mhz for SDRAM, and 250Mhz for SGRAM
The G400 can have either memory type, but so far, I'm unaware of any SDRAM
G400's, and I pray to god they are not created.
now, to me, it makes sense to have dclk.max handled by the RAMDAC driver,
and fvco.max handled byt the clock driver, (This is an integrated chipset, so
neither chipset, ramdac or clock will apear separate from eachother) but in
order to do so, I need to switch() on vendorID (ther are G200's with vendor
numbers from Siemens, although I'm not supporting these just yet), DeviceID,
and for the Mystique, revision, to set these limits.
Now, I can probe in the chipset driver, and that is fine for the chipset
driver, thats no problem, but for the clock and ramdac parts to have access
to that information, I have to either share the information between
subsystems, or, I can reprobe for vendorID, deviceID, revision and memory
type in _each_ subsytem, as the information is needed in _each_ susbsystems
bind, and later in the meta code (to control some behavioral differances)
(this also assumes the chipset is always initialized first, or I won't have
access to regions, nor can i guarantee that the card is awake and/or alive)
Unfortunatley there isn't a sane way to probe for the memory subsystem on a
Matrox board, old or new. the only information I know of is the mystique and
some of the old G200's have a documented BIOS format with identifiers that
can only be reached on primary boards, and only on non-integrated solutions.
Anyway, this got long fast...
Johan