Stefan Reinauer stepan@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