* Eric W. Biederman <[EMAIL PROTECTED]> [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 _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios