> >
> > * 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.
Steffen
----------------- e-mail: [EMAIL PROTECTED] -----------------
