irq tables generation - coreboot

3 Dec 2003


      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
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development