[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CB33910.1020002@kernel.org>
Date: Mon, 11 Oct 2010 09:19:28 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
CC: Grant Likely <grant.likely@...retlab.ca>,
Russell King - ARM Linux <linux@....linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
Linus Torvalds <torvalds@...l.org>,
Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mundt <lethal@...ux-sh.org>,
David Woodhouse <dwmw2@...radead.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [patch 00/47] Sparse irq rework
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists