mptables and missing devices

Stefan Reinauer stepan at suse.de
Mon Sep 29 17:24:00 CEST 2003


* Eric W. Biederman <ebiederman at lnxi.com> [030929 23:48]:
> > > is there a reason why the mptable creation uses dev_find_slot()
> > > to find the bridges instead of dev_find_device()? Since it does
> > > not even check whether the device it finds is the one it wants
> > > this sounds rather dangerous.
> 
> In the case of a specific motherboard it is safe, as long as all of 
> the upper level bridges are taken into account.  dev_find_device,
> is worse because you may have two devices with the same vendor
> and device id.
 
But you can give it a starting point, and you probably want entries for
both of them anyways...?

> It is on the todo list to generate all of this by walking the device
> tree.  What we have now is a place holder that let's LinuxBIOS work
> until we have generic code that will work for everyone.
 
Ok.. I think it's pretty easy doable if the bus number registers of the
bridges are filled reliably. Is this the case?

> > Is this an internal convention, a hardware rule or just common sense
> > that the ISA bus is the last bus in the mptable? An ISA bus has no 
> > bus number in the PCI view of things, does it?
> 
> Right.  A lot of this was modeled on how existing mptables are setup.
> I am not certain there needs to be a 1-1 mapping from bus numbers on
> the pci bus to other bus numbers but it can't hurt.  And the ISA can
> pretty much go anywhere else.
 
Hanging it at the end of the list should not hurt then as it keeps all
the rest of constant.

> >         /* ISA backward compatibility interrupts  */
> >         smp_write_intsrc(mc, mp_ExtINT, 
> >                 MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT,
> >                 bus_isa, 0x00, 0x02, 0x00);
> >         ...
> 
> Almost. Interrupts off of the LPC/ISA bus are the same because the bus
> generates them.   PCI interrupts that are routed through 8259 also vary.
> I think the irq controller can also vary.   Although it may be special
> cased.
 
So the above works only if you use an ioapic? at least for opteron/linux
this is always the case. Linux/x86_64 wont boot with no ioapic enabled.

> It must be left over.  I have it yanked out of my tree.  After I finish
> catching up on my email I will start synching the tress and kill it.
 
please do!! ;)

> > The interrupt src entries for the different PCI slots confuse me a bit..
> > Is there a way to find out in the system how many pci slots a bridge
> > has, or should the bridge entry in the config file get an entry similar to:
> >         register "slots" = 2
> 
> We should probably hang a ``slot'' device of the device tree to model this.
 
this is in the openfirmware kind of view a device node vs node property
consideration. Does a single slot need more information than the fact
that it's there?

> All pci bridges have a maximum of 32 devices behind them.  And we need to know
> which ones are actually devices.

We get that information during bus enumeration already, don't we?

  Stefan


-- 
Architecture Team
    SuSE Linux AG



More information about the coreboot mailing list