[EMAIL PROTECTED] (Eric W. Biederman) writes:
> > > Probably something like the nsuperio architecture, but looked into
> > > the a device tree, like we have for pci.
> > >
> >
> > What I was imaging is something like the current Linux PCI device driver
> > interface. The driver provides some static device probe/identify
> > structure, the main code uses the struct to "install" the driver (in
> > OO terms, constructor of the device object). This can not only be used
> > for PCI device, for instance, with properly modified cpuid routines,
> > we can also have some "CPU driver" too.
> >
> > /* ??? warnning, mixture of C and C++ */
> > class cpu_driver: generic_device {
> > public:
> > probe: cpuid();
> > private:
> > /* our own member function */
> > cache_on: intel_cache_on();
> > mtrr: p6_mtrr();
> > } intel_p6;
>
> Sounds roughly right. After thinking about it some more I actually
> thinkg we can go there, without a radical step like freebios2. The
> only practical objection I can think of is that it would mess up some
> hardcodes. Which is actually a good thing as it puts pressure on us
> to do things dynamically.
>
> As a small step in that direction I propose having drivers for pci
> devices, that initialize devices. Semantically equivalent to the
> loop.
>
> while(dev = pci_find_device(vendor, device)) {
> intitialize(dev);
> }
>
> Except packaged as something like.
> struct pci_id ids[] = {
> { vendor, device },
> { vendor, device },
> { vendor, device },
> ...
> { 0, 0 },
> }
>
> struct driver {
> struct pci_id ids;
> void (*initialize)(struct pci_dev *dev);
> ...
> } pci_driver = {
> pci_ids,
> initialize,
> ...
> };
>
> We will need to have helper libraries under the covers building up the
> data for tables, etc. But I believe this can be the primary interface
> to most of the device initialization needed in LinuxBIOS.
>
> Eventually we can enhance it with dependecy information on what needs
> to happen first. But given how many surprises I have seen from
> hardware slowly evolving the interface looks good.
>
> Ollie I think with just a little care this should work for your
> northbridge init problem. The very nice thing here is that this
> should be straight forward to implement, comprehensible, and work
> for a great number of cases.
>
> So at this point, do you want to write it or should I?
> Unless you can find the flaw in my beautiful idea :)
Hmm. I guess it will be me.
I currently have this fun issue with the P4DP[6E].
I have four pci buses. For each bus I have
a pci-pci bridge, and a ioapic. Plus another ioapic
for the ISA bus, and any 33Mhz onboard pci devices I have.
And I need to do fun things like automatically adjust the speed of
these busses depending upon what hardware is in them.
Plus I need to allocate the PCI devices as compactly as possible
so I don't waste ram with reserved areas for pci memory. Not a huge
issue but every little bit helps.
So it looks like to support this board properly I really need to add
this kind of thing based upon the pci layer, and then we can look
at generalizing this for non pci devices.
And given that this is a practical requirement I am more likely to get
a gradual evolution path than sitting at a drawing board trying to
anticipate this kind of thing. :)
Eric
