IRQ-Tables once again

[Eric W. Biederman]

Stefan Reinauer <stepan at suse.de> writes:

> Hi,
> 
> I'm trying to factor the IRQ Table generation a bit, since the
> current way to write an IRQ Table plain sucks. This means
> 
> * gather all information before actually generating the table
> * gather information in a readable and adjustable way.
> 
> I juggled with the Arima Hdama irq table, since this one seems to 
> work. (See attachment)
> 
> Currently I have a couple of defines that are hardcoded into the file.
> This should maybe be moved to the motherboard configuration files. 
> (At least I would move them and the IRQ_SLOT_COUNT together)
> 
> #define IRQ_ROUTER_BUS          1
> #define IRQ_ROUTER_DEVFN        PCI_DEVFN(4,3)
> #define IRQ_ROUTER_VENDOR       0x1022
> #define IRQ_ROUTER_DEVICE       0x746b
> #define AVAILABLE_IRQS          0xdef8
> 
> Then I substituted the longish irq table entries with a macro
> IRQ_SLOT which takes the following arguments:
>  * slot number
>  * bus,dev,fn
>  * 4* irq link line id
> 
> Example:
> /* PCI Slot 1 */
> IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
> /* Let Linux know about bus 1 */
> IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),
> 
> If there are no objections, I am going to make this change in the code.
> Who else is having IRQ Table trouble here?

Sounds like a good small step.  I object only on the grounds
it does not go far enough.  We should go at least as far as
we have with mptable generation, so we can be isolated from
bus renumbering.  And preferably we should go all of the way
to generating it from the device tree.

Eric