Yinghai Lu <yinghai@xxxxxxxxxx> writes:
> On 02/27/2010 01:30 PM, Eric W. Biederman wrote:
> then will have all irq_desc for ioapic stay with BSP node.
This is what I am thinking....
static void __init setup_IO_APIC_irqs(void)
{
int apic_id, pin, idx, irq;
int notcon = 0;
struct irq_desc *desc;
struct irq_cfg *cfg;
int node = cpu_to_node(boot_cpu_id);
apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n");
for(apic_id = 0; apic_id < nr_ioapics; apic_id++) {
for (pin = 0; pin < nr_ioapic_registers[apic_id]; pin++) {
idx = find_irq_entry(apic_id, pin, mp_INT);
if (idx == -1) {
if (!notcon) {
notcon = 1;
apic_printk(APIC_VERBOSE,
KERN_DEBUG " %d-%d",
mp_ioapics[apic_id].apicid, pin);
} else
apic_printk(APIC_VERBOSE, " %d-%d",
mp_ioapics[apic_id].apicid, pin);
continue;
}
if (notcon) {
apic_printk(APIC_VERBOSE,
" (apicid-pin) not connected\n");
notcon = 0;
}
irq = pin_2_irq(idx, apic_id, pin);
+ if ((apic_id > 0) && (irq > 16))
+ continue;
/*
* Skip the timer IRQ if there's a quirk handler
* installed and if it returns 1:
*/
if (apic->multi_timer_check &&
apic->multi_timer_check(apic_id, irq))
continue;
desc = irq_to_desc_alloc_node(irq, node);
if (!desc) {
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
continue;
}
cfg = desc->chip_data;
add_pin_to_irq_node(cfg, node, apic_id, pin);
/*
* don't mark it in pin_programmed, so later acpi could
* set it correctly when irq < 16
*/
setup_IO_APIC_irq(apic_id, pin, irq, desc,
irq_trigger(idx), irq_polarity(idx));
}
}
if (notcon)
apic_printk(APIC_VERBOSE,
" (apicid-pin) not connected\n");
}
>> YH your current remapping patch looks like a pretty horrible hack
>> instead of real solution to the problem. I honestly think starting
>> with it will just obscure what is going and make it harder to
>> introduce a clean gsi_to_irq/irq_to_gsi.
>
> good, the mapping looks much clear.
Thanks. This code is just too convoluted to introduce many more
hacks and not have it fall over.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|