Re: [patch 00/47] Sparse irq rework

From: Thomas Gleixner
Date: Mon Oct 11 2010 - 04:16:48 EST


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.

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.

Thanks,

tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/