weighing in
Ronald G. Minnich
rminnich at lanl.gov
Tue Feb 18 20:51:01 CET 2003
On 18 Feb 2003, Eric W. Biederman wrote:
> Right now I have a larger number of initialization functions being
> called from mainboard_fixup. Those are the real functions that need
> to be tackled. The superio model comes close to handling those cases
> cleanly. The big issue with superio code is that we use one structure
> for all possible static values, that is silly.
There are two static structures in there, and I think I know which one you
mean, but want to clarify.
This one, I assume, is OK
struct superio_control {
void (*pre_pci_init)(struct superio *s);
void (*init)(struct superio *s);
void (*finishup)(struct superio *s);
unsigned int defaultport; /* the defaultport. Can be overridden
* by commands in config
*/
// This is the print name for debugging
char *name;
};
Fairly generic and represents how to attack a superio. Universal to all
superios.
This one, I think is the mistake:
struct superio {
struct superio_control *super; // the ops for the device.
unsigned int port; // if non-zero, overrides the default port
// com ports. This is not done as an array (yet).
// We think it's easier to set up from python if it is not an
array.
struct com_ports com1, com2, com3, com4;
// DMA, if it exists.
struct lpt_ports lpt1, lpt2;
/* flags for each device type. Unsigned int. */
// low order bit ALWAYS means enable. Next bit means to enable
// LPT is in transition, so we leave this here for the moment.
// The winbond chips really stretched the way this works.
// so many functions!
unsigned int ide, floppy, lpt;
unsigned int keyboard, cir, game;
unsigned int gpio1, gpio2, gpio3;
unsigned int acpi,hwmonitor;
};
because all the superios are so different (I never realized how
different!) this struct is a mess and we don't want to repeat this for the
south and north bridge hardware.
Make sense?
ron
More information about the coreboot
mailing list