On 10/11/2010 01:16 AM, Thomas Gleixner wrote:
> On Sun, 10 Oct 2010, Yinghai Lu wrote:
>
>> On 10/10/2010 02:32 AM, Thomas Gleixner wrote:
>>> On Sat, 9 Oct 2010, Yinghai Lu wrote:
>>>> On 10/08/2010 11:34 PM, Thomas Gleixner wrote:
>>>>> On Fri, 8 Oct 2010, Yinghai Lu wrote:
>>>>>> + /* only handle fall out from setup_IO_APIC_irqs() */
>>>>>
>>>>> What's the fallout ? And why are we coming here in the first place
>>>>> when the irq is < 16 ?
>>>>
>>>> setup_IO_APIC_irqs only handle apic_id == 0 or apic_id > 0 but irq < 16 via acpi override.
>>>>
>>>> it seems IBM's system have apic_id == 1, and sci irq is using 30.
>>>>
>>>> so at that time add that setup_IO_APIC_irq_extra() to workaround it.
>>>> but it seems we set that two time when irq < 16.
>>>>
>>>>>
>>>>>> + if (!((apic_id > 0) && (irq > 16)))
>>>>>> + return;
>>>
>>> I added this into the queue, but simplified it to
>>>
>>> if (apic_id == 0 || irq < NR_IRQS_LEGACY)
>>>
>>> Folded in the other fix and pushed out an updated tree.
>>
>> still have the irq_2_iommu_alloc warning from pnpacpi
>
> Hmm, that's probably a problem for all legacy interrupts which are
> never torn down once they are set up. And we set them all up during
> early boot.
>
> So either we special case the legacy area or remove the warning
> alltogether.
or use pr_warning instead of WARN_ONCE?
>
> Another option I discussed with Suresh recently is to remove the
> allocator in intr_remapping.c and just embedd irq_2_iommu into
> irq_cfg.
in setup_IO_APIC_irqs(), pin_programmed is not set.
/*
* don't mark it in pin_programmed, so later acpi could
* set it correctly when irq < 16
*/
setup_ioapic_irq(apic_id, pin, irq, cfg, irq_trigger(idx),
irq_polarity(idx));
because we found some systems have strange ioapic setting, their pci devices irq < 16.
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
