Re: FW: [PATCH] i386: irq: Kill IRQ compression

Re: FW: [PATCH] i386: irq: Kill IRQ compression

[Natalie Protasevich]

> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> Sent: Friday, February 16, 2007 12:44 AM
> To: Len Brown
> Cc: Andi Kleen; Protasevich, Natalie; lkml - Kernel Mailing List;
> linux-acpi@vger.kernel.org
> Subject: Re: [PATCH] i386: irq: Kill IRQ compression
>
> Len Brown <lenb@kernel.org> writes:
>
> > This code makes simple systems complex:
> >
> > ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 18 (level, low) -> IRQ 16
> > ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17
> > ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18
> > ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
> >
> > The same code was already removed from x86_64
>
> By itself I don't think we are going to observe any real problems
> with this patch.
>
> However if we are going to be serious about this we need to do a
> few more things.
>
> - kill iopaic_renumber_irq.

This routine actually renumbers gsi's. I don't think you can kill
ioapic_renumber_irq without bringing down ES7000 that have swapped
legacy/PCI ranges and are still out there. Moreover, mach-es7000
purpose is to define and use the range swapper on the first ioapic.
Kernel still assumes legacy mapping having no overrides of that
extent. Perhaps the real fix is to have ACPI/MPS parsers to read the
actual pin/gsi information from the tables, which turned out pretty
difficult last time we tried.
--Natalie

> - Increase NR_IRQS.
>
> We will still be limited to about 208 interrupts in use at one
> time, but we can allow more irq sources to be described.
>
> This reminds me.  I really need to dig up my patch that doesn't
> allocate a vector for an irq until request irq time.
>
> Eric
>

Re: FW: [PATCH] i386: irq: Kill IRQ compression

[Eric W. Biederman]

"Natalie Protasevich" <protasnb@gmail.com> writes:

> This routine actually renumbers gsi's. I don't think you can kill
> ioapic_renumber_irq without bringing down ES7000 that have swapped
> legacy/PCI ranges and are still out there. Moreover, mach-es7000
> purpose is to define and use the range swapper on the first ioapic.
> Kernel still assumes legacy mapping having no overrides of that
> extent. Perhaps the real fix is to have ACPI/MPS parsers to read the
> actual pin/gsi information from the tables, which turned out pretty
> difficult last time we tried.
> --Natalie

Yes I noticed, and you replied just before I send off an email explicitly
asking you about this :)  At first glance I thought it was that other piece of
irq compression that showed up in arch/x86_64/io_apic.c but it appears
arch/i386/io_apic.c does not have that.

Anyway now all we have to do is bump up NR_IRQS and we should be good, patch
in a moment.

Eric

Re: FW: [PATCH] i386: irq: Kill IRQ compression

[Natalie Protasevich]

l> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> Sent: Friday, February 16, 2007 2:22 AM
> To: Protasevich, Natalie
> Cc: Len Brown; Andi Kleen; lkml - Kernel Mailing List;
> linux-acpi@vger.kernel.org
> Subject: Re: [PATCH] i386: irq: Kill IRQ compression
>
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > By itself I don't think we are going to observe any real problems
> > with this patch.
> >
> > However if we are going to be serious about this we need to do a
> > few more things.
> >
> > - kill ioapic_renumber_irq.
>
> Looking closer ioapic_renumber_irq does not appear to be an irq
> compress thing.  Rather it appears to be a work around for a weird
> acpi implementation where gsi 0 - 15 are not the ISA irqs.
>
> Natalie is my reading of the code there correct?

Yes, indeed.

>
> If so keeping ioapic_renumber_irq makes sense.  Although giving
> it a name that suggests it is working around weird implementation
> details would be good.

Sure. I think it was originally renumber_gsi something, but Len had to
change it so it sounds more explicit as familiar "IRQ".
--Natalie
>
> Eric
>