Hi,
* ron minnich rminnich@lanl.gov [031202 00:28]:
{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},pci_assign_irqs(2, 0x5, dualenetbIrq);'' in addition i had to play with the irq lists.
eek. You know that this is exactly the wrong way to do this and why, I assume. But it works, so keep it for now. But this will never go into the CVS.
Do we agree that interrupts should be _unassigned_ during firmware execution and set by the OS only? Another way of handling this might be to set some default values and allow the OS to reconfigure those.
A PIRQ-Table has to contain
* one entry for each PCI device that needs an interrupt * one entry for each peer bus to be visible.
It seems we know these parameters in-system already and can generate a valid table assuming some fixed parameters (cycling interrupts a la {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}} and a fixed mask of 0xdeb8.
irq_table.c is for linux, it tells linux how the irqs are wired up. In an ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd and those OSes would do everything correctly. In our world, each of these OSes get it wrong often enough that we have to now assign it directly. I had hoped to avoid IRQ assignment in linuxbios but it seems that we have no choice -- too many busted hardware/OS bits out there.
Not to forget the mptable - that contains additional information on which busses are available - information that Linux obviously don't like to read from there but from the irq table.
Stefan