irq tables generation

[Stefan Reinauer]

Hi,

* ron minnich <rminnich at 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