weighing in

[steven james]

Greetings,

Given the many permutations of com lpt, and other devices from (possibly
multiple) superios, I wonder if a linked list of single device structs
might not be a better abstraction. 

I've certainly seen enough cases where various chips provide the same
class of device, such as e750[01] where ICH3 provides IDE and Intel puts a
Promise IDE-RAID (really just IDE with soft raid in firmware) on the
board.

Then there's the SiS630 boards that have an rtl8139 and a disconnected
SiS900 ethernet on board.

G'day,
sjames

On 18 Feb 2003, Eric W. Biederman wrote:

> "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> 
> > 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. 
> 
> Right.  The one I have for pci is a little different but roughly equivalent.
>  
> > This one, I think is the mistake:
> 
> I would just call it in need of a better abstraction.  Not
> a really a 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. 
> 
> Correct.
>  
> > Make sense?
> 
> Yes.
> 
> I am thinking of something like:
> 
> struct setup_info {
>         struct setup_info *next;
>         int type;
> };
> 
> struct irq_routing {
>         struct setup_info info;
>         /* Flesh this out... */
> };
> 
> struct static_resources {
>         struct setup_info info;
>         /* Flesh this out... */
> };
> 
> struct old_superio {
>         struct setup_info info;
>         struct com_ports com1, com2, com3, com4;
>         struct lpt_ports lpt1,lpt2;
> 	unsigned int ide, floppy, lpt;
> 	unsigned int keyboard, cir, game;
> 	unsigned int gpio1, gpio2, gpio3;
> 	unsigned int acpi,hwmonitor;
>         /* Don't use this for real.. */
> };
> 
> The important characteristics are:
> 
> - Any developer can add new structure types and they can be
>   motherboard or device specific
> 
> - There is a way for generic code to access configuration settings
>   information about a device.
> 
> Eric
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                     230 peachtree st nw ste 701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------