Hi,
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.
Taking the PCI_CLASS field into regard, it should be possible to search for all bridges in the system and generate the necessary mptable entries from the information gathered from the devices (SUBORDINATE_BUS, SECONDARY_BUS)
Am I digging in the dark?
Stefan
overall, we have some work to do on PCI, so my guess is that you are not digging in the dark at all, Stefan.
ron
* Stefan Reinauer stepan@suse.de [030929 22:15]:
Hi,
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.
Taking the PCI_CLASS field into regard, it should be possible to search for all bridges in the system and generate the necessary mptable entries from the information gathered from the devices (SUBORDINATE_BUS, SECONDARY_BUS)
/* define bus and isa numbers */ for(bus_num = 0; bus_num < bus_isa; bus_num++) { smp_write_bus(mc, bus_num, "PCI "); } smp_write_bus(mc, bus_isa, "ISA ");
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?
I assume that the ISA compatibility interrupts handling is the same on all platforms that have ISA, is it? /* ISA backward compatibility interrupts */ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_isa, 0x00, 0x02, 0x00); ...
Local interrupts are probably one per CPU: /* Standard local interrupt assignments */ What's the way to find out the number of CPUs while writing the mptable?
The HDAMA has no AGP slot.. is this a left over, or is it good for something? /* AGP Slot */
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
Stefan
Stefan Reinauer stepan@suse.de writes:
- Stefan Reinauer stepan@suse.de [030929 22:15]:
Hi,
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.
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.
Taking the PCI_CLASS field into regard, it should be possible to search for all bridges in the system and generate the necessary mptable entries from the information gathered from the devices (SUBORDINATE_BUS, SECONDARY_BUS)
/* define bus and isa numbers */ for(bus_num = 0; bus_num < bus_isa; bus_num++) { smp_write_bus(mc, bus_num, "PCI "); } smp_write_bus(mc, bus_isa, "ISA ");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.
I assume that the ISA compatibility interrupts handling is the same on all platforms that have ISA, is it? /* 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.
Local interrupts are probably one per CPU: /* Standard local interrupt assignments */ What's the way to find out the number of CPUs while writing the mptable?
The HDAMA has no AGP slot.. is this a left over, or is it good for something? /* AGP Slot */
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.
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.
All pci bridges have a maximum of 32 devices behind them. And we need to know which ones are actually devices.
Eric
* Eric W. Biederman ebiederman@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
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@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?
Yes. And the bus number values are also in the device tree. Which is where it would be better to read them from. Just in case we have a non-standard pci bus. Like the Opteron's multiple host bridges off of one cpu.
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.
Yes.
/* 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.
Yes. The MPtables are IOAPIC specific.
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?
Yes. Which the irq routing information.
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?
For the most part yes. But an empty slot won't show up. So at least in the hot-plug case we need to force it's information to be present.
Saying to much is better than saying to little.
Eric
* Eric W. Biederman ebiederman@lnxi.com [030930 00:16]:
Ok.. I think it's pretty easy doable if the bus number registers of the bridges are filled reliably. Is this the case?
Yes. And the bus number values are also in the device tree. Which is where it would be better to read them from. Just in case we have a non-standard pci bus. Like the Opteron's multiple host bridges off of one cpu.
ack
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?
Yes. Which the irq routing information.
This information is also held in the pirq table. Can it be generated from there or are there other caveats? It would be nice if a new board only needs an adapted pirq table, no matter whether it provides an mptable or not.
Stefan
Stefan Reinauer stepan@suse.de writes:
- Eric W. Biederman ebiederman@lnxi.com [030930 00:16]:
Ok.. I think it's pretty easy doable if the bus number registers of the bridges are filled reliably. Is this the case?
Yes. And the bus number values are also in the device tree. Which is where it would be better to read them from. Just in case we have a non-standard pci bus. Like the Opteron's multiple host bridges off of one cpu.
ack
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?
Yes. Which the irq routing information.
This information is also held in the pirq table. Can it be generated from there or are there other caveats?
The pirq routing information has a slightly different flavor and slightly different rules but in principle we want to generate it from the same tree as well.
It would be nice if a new board only needs an adapted pirq table, no matter whether it provides an mptable or not.
There are boards that a pirq routing table simply does not work for, because not all interrupts go through the pirq router. For those boards we either we need to just go through the mptable, or we need to pre route the irqs and fill in the routing in pci space. Pre routing the irqs is the most compatible with multiple kernels and OS's.
Even in cases where pirq tables work there are not forced correspondences from how an irq line is routed into a pirq router and an ioapic. So we probably need separate routing information from irq lines to the ioapics and to the pirq routers. With the possibility for older boards of no router being present at all.
What is required in LinuxBIOS is enough information to do the routing ourselves.
Once we get that we can figure out how to export that information via the LinuxBIOS table, the mptable, and pirq table. I am tempted at that point to move the mptable and pirq table generation code into mkelfImage, and to start looking at having the kernel support the LinuxBIOS table directly.
But for now need a way to represent that information.
Eric
On 30 Sep 2003, Eric W. Biederman wrote:
There are boards that a pirq routing table simply does not work for, because not all interrupts go through the pirq router. For those boards we either we need to just go through the mptable, or we need to pre route the irqs and fill in the routing in pci space. Pre routing the irqs is the most compatible with multiple kernels and OS's.
still worse, there are those cases (Linux) where the interpretation of PIRQ is broken (e.g. for Geode). So I've reluctantly come to the conclusion that LinuxBIOS should do this routing.
Once we get that we can figure out how to export that information via the LinuxBIOS table, the mptable, and pirq table. I am tempted at that point to move the mptable and pirq table generation code into mkelfImage, and to start looking at having the kernel support the LinuxBIOS table directly.
we need to leave them in LinuxBIOS, I think, so that I can continue to support 9load, plan 9, and all the other systems that want to read PIRQ. I would hate to see mkelfImage get too complicated, as I need to be able to generate these elf Images on systems that have no GNUbin utilities.
ron
ron minnich rminnich@lanl.gov writes:
On 30 Sep 2003, Eric W. Biederman wrote:
There are boards that a pirq routing table simply does not work for, because not all interrupts go through the pirq router. For those boards we either we need to just go through the mptable, or we need to pre route the irqs and fill in the routing in pci space. Pre routing the irqs is the most compatible with multiple kernels and OS's.
still worse, there are those cases (Linux) where the interpretation of PIRQ is broken (e.g. for Geode). So I've reluctantly come to the conclusion that LinuxBIOS should do this routing.
Once we get that we can figure out how to export that information via the LinuxBIOS table, the mptable, and pirq table. I am tempted at that point to move the mptable and pirq table generation code into mkelfImage, and to start looking at having the kernel support the LinuxBIOS table directly.
we need to leave them in LinuxBIOS, I think, so that I can continue to support 9load, plan 9, and all the other systems that want to read PIRQ. I would hate to see mkelfImage get too complicated, as I need to be able to generate these elf Images on systems that have no GNUbin utilities.
mkelfImage 2.x does not have a binutils requirement, except when it is built. mkelfImage 2.x is a standalone C binary.
Removing the non native interface from the core is something I'm playing with. It is not something I care about much either was as long as we have a good native interface. But it should not much matter if we actually pre route the irqs. As suggested for the Geode.
In addition if we have maintain a subset of the kernel that understands native LinuxBIOS tables then we define the proper interpretation of the tables and we can say who has the correct interpretation.
But I totally agree this is something we need to move forward slowly with.
Eric
-
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer