Re: [patch 00/47] Sparse irq rework

[Yinghai Lu <yinghai@kernel.org>]

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