I'd rather see the original irq-renaming patch
and its subsequent multiple via workaround patches
reverted than to further complicate what is becoming
a fragile mess.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More maj
On Tuesday 25 April 2006 18:06, Kimball Murray wrote:
> Per Andi Kleen's request, I have made slight changes to the patch I
> submitted last week. Look for the "snip" further down if you don't
> want to re-read the original post. Thanks!
Added to my tree thanks.
But next time please don't paste
I think, it is about time, not thinking via quirks as workarounds,
because all pcis (on via) are quirked, some are quirked twice.
And we should think in programmer interrupts of via chipset, in specific
function for this propose, for me, doesn't make sense every time VIA put
other ID out, we have t
On Tuesday 25 April 2006 21:53, Brown, Len wrote:
> I'd rather see the original irq-renaming patch
> and its subsequent multiple via workaround patches
> reverted than to further complicate what is becoming
> a fragile mess.
Sorry rechecking - i already got the patch now. You want me to drop it ag
Hi Andi,
On 4/26/06, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tuesday 25 April 2006 21:53, Brown, Len wrote:
> > I'd rather see the original irq-renaming patch
> > and its subsequent multiple via workaround patches
> > reverted than to further complicate what is becoming
> > a fragile mess.
>
> I think, it is about time, not thinking via quirks as
> workarounds, because all pcis (on via) are quirked, some are
> quirked twice.
> And we should think in programmer interrupts of via chipset,
> in specific function for this propose, for me, doesn't make
> sense every time VIA put other I
Oops, previous message got sent before I had typed anything!
Andi, I just wanted to be clear that my patch is not a VIA workaround,
it is a VIA workaround workaround. So please don't remove my patch
while leaving in the original VIA workaround. That will break our
platform, and possibly others.
>There are probably better ways to control 224 possible IRQs by their
>total number instead of their range, and per-cpu IDTs are the better
>answer to the IRQ shortage altogether. But just going back to
>the way it was wouldn't be right I think.
>We were able to run 2 generations of
>systems only
On Thursday 27 April 2006 20:13, Brown, Len wrote:
>
> >There are probably better ways to control 224 possible IRQs by their
> >total number instead of their range, and per-cpu IDTs are the better
> >answer to the IRQ shortage altogether. But just going back to
> >the way it was wouldn't be right
>
> >There are probably better ways to control 224 possible IRQs by their
> >total number instead of their range, and per-cpu IDTs are the better
> >answer to the IRQ shortage altogether. But just going back
> to the way
> >it was wouldn't be right I think.
> >We were able to run 2 generations
On Thursday 27 April 2006 21:10, Protasevich, Natalie wrote:
> >
> > >There are probably better ways to control 224 possible IRQs by their
> > >total number instead of their range, and per-cpu IDTs are the better
> > >answer to the IRQ shortage altogether. But just going back
> > to the way
>
> > Len, maybe it sounds dramatic and/or extreme, but how about getting
> > rid of IRQs and just having GSI-vector pair.
> > I intuitively think that would be possible (not that I have all the
> > details lined up :) And this would probably take away confusing IRQ
> > abstraction out once and fo
>But I guess using GSI/vector internally only would be fine.
The last time I tried to name a variable "gsi" instead of "irq",
Linus launched into a tirade that "GSI" doesn't mean anything to him,
or anybody else that googles it. On the other hand "IRQ" means
something
to everybody, and if you go
> >But I guess using GSI/vector internally only would be fine.
>
> The last time I tried to name a variable "gsi" instead of "irq",
> Linus launched into a tirade that "GSI" doesn't mean anything to him,
> or anybody else that googles it. On the other hand "IRQ" means
> something
> to everybody,
"Protasevich, Natalie" <[EMAIL PROTECTED]> writes:
>> >But I guess using GSI/vector internally only would be fine.
>>
>> The last time I tried to name a variable "gsi" instead of "irq",
>> Linus launched into a tirade that "GSI" doesn't mean anything to him,
>> or anybody else that googles it. O
>The original IRQ (on x86) was simply the enumeration of the input
>pins on the pair of i8259 interrupt controllers.
The IOAPIC was originally supported by MPS before ACPI.
MPS used IRQ to describe the ISA inputs to IOAPICs too,
and PIRQ to describe the PCI inputs.
Linux (wisely, IMHO) simply used
> >- Modify do_IRQ to get passed an interrupt vector# from the
> > interrupt vector instead of an irq number, and then lookup
> > the irq number in vector_irq. This means we don't need
> > a code stub per irq, and allows us to handle more irqs
> > by simply increasing NR_IRQS.
>
> isn't the
"Brown, Len" <[EMAIL PROTECTED]> writes:
>>The original IRQ (on x86) was simply the enumeration of the input
>>pins on the pair of i8259 interrupt controllers.
>
> The IOAPIC was originally supported by MPS before ACPI.
> MPS used IRQ to describe the ISA inputs to IOAPICs too,
> and PIRQ to descri
Andi Kleen <[EMAIL PROTECTED]> writes:
>> >- Modify do_IRQ to get passed an interrupt vector# from the
>> > interrupt vector instead of an irq number, and then lookup
>> > the irq number in vector_irq. This means we don't need
>> > a code stub per irq, and allows us to handle more irqs
>> > b
On Tuesday 02 May 2006 08:57, Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> >> >- Modify do_IRQ to get passed an interrupt vector# from the
> >> > interrupt vector instead of an irq number, and then lookup
> >> > the irq number in vector_irq. This means we don't need
> >
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Tuesday 02 May 2006 08:57, Eric W. Biederman wrote:
>> Andi Kleen <[EMAIL PROTECTED]> writes:
>>
>> No. At best there is a fixed offset. They can't be
>> identical because the first 32 vectors are reserved,
>> for processor exceptions.
>>
>> Beyond
>IRQ is an interrupt request, from a device.
>Currently they can come in over a pin, or over a packet.
>IRQs at the source can be shared.
Well stated.
>For an IRQ number it is just an enumeration of interrupt sources.
>Ideally in a stable manner so that the assigned number does not
>depend on com
On Tuesday 02 May 2006 09:41, Brown, Len wrote:
> You are right. This code is wrong.
> It makes absolutely no sense to reserve vectors in advance
> for every RTE in the IOAPIC when we don't even know if they
> are going to be used.
>
> This is clearly a holdover from the early IOAPIC/MPS days
>
"Brown, Len" <[EMAIL PROTECTED]> writes:
>>IRQ is an interrupt request, from a device.
>>Currently they can come in over a pin, or over a packet.
>>IRQs at the source can be shared.
>
> Well stated.
>
>>For an IRQ number it is just an enumeration of interrupt sources.
>>Ideally in a stable manner
> On Tuesday 02 May 2006 09:41, Brown, Len wrote:
>
> > You are right. This code is wrong.
> > It makes absolutely no sense to reserve vectors in advance
> for every
> > RTE in the IOAPIC when we don't even know if they are going to be
> > used.
> >
> > This is clearly a holdover from the ear
>>> We should never have had a problem with un-connected interrupt lines
>>> consuming vectors, as the vectors are handed out at run-time
>>> only when interrupts are requested by drivers.
>>
>>Incorrect. By being requested by drivers I assume you mean by
>>request_irq. assign_irq_vector is calle
"Brown, Len" <[EMAIL PROTECTED]> writes:
We should never have had a problem with un-connected interrupt lines
consuming vectors, as the vectors are handed out at run-time
only when interrupts are requested by drivers.
>>>
>>>Incorrect. By being requested by drivers I assume you mea
We should never have had a problem with un-connected
>interrupt lines
consuming vectors, as the vectors are handed out at run-time
only when interrupts are requested by drivers.
>>>
>>>Incorrect. By being requested by drivers I assume you mean by
>>>request_irq. assign_irq_vector
> We should never have had a problem with un-connected
>interrupt lines
> consuming vectors, as the vectors are handed out at run-time
> only when interrupts are requested by drivers.
Incorrect. By being requested by drivers I assume you mean by
request_irq. assign_irq
>
> I think what we can do in the short term is to make these
> workarounds not have any effect on the systems which don't
> need them. This means searching like gsi_irq_sharing() does,
> instead of always compressing like mp_register_gsi() does.
> It also means not printing dmesg about vect
"Brown, Len" <[EMAIL PROTECTED]> writes:
>>In the case of ACPI. I think the mptable case has all of information
>>in mp_irqs at that point.
>
> Agreed, I just sent a note on this, but apparently it "crossed
> in the mail" with yours. The key point about MPS is that MPS
> should not describe pins
Natalie,
Regarding the "IRQ compression" in mp_register_gsi()
Some time ago we invented ioapic_renumber_irq() to handle the case
where the ES7000 BIOS is missing the INTERRUPT_OVERRIDES needed
to tell that legacy IRQs used pins > 15, and PCI interrupts used
pins < 16.
In that case, the ES7000
> Natalie,
> Regarding the "IRQ compression" in mp_register_gsi()
>
> Some time ago we invented ioapic_renumber_irq() to handle the
> case where the ES7000 BIOS is missing the INTERRUPT_OVERRIDES
> needed to tell that legacy IRQs used pins > 15, and PCI
> interrupts used pins < 16.
>
> In
> > Natalie,
> > Regarding the "IRQ compression" in mp_register_gsi()
> >
> > Some time ago we invented ioapic_renumber_irq() to handle the case
> > where the ES7000 BIOS is missing the INTERRUPT_OVERRIDES needed to
> > tell that legacy IRQs used pins > 15, and PCI interrupts
> used pins <
>
<6>IOAPIC[64]: apic_id 127, version 32, address 0xfec49000, GSI
1728-1751
wow, big box!
>I have tested this algorithm and it worked just fine for me... I used
>the following compression code in mp_register_gsi():
>
>
>int irqs_used = 0;
>int gsi_to_irq[NR_IRQS] = { [0 ... NR_IRQS-1] = -1
> <6>IOAPIC[64]: apic_id 127, version 32, address 0xfec49000, GSI
> 1728-1751
>
> wow, big box!
Yea, it's decent :) I asked for the big one since this way we can test
IRQs "wrapping around".
>
> >I have tested this algorithm and it worked just fine for
> me... I used
> >the following compres
>> >I have tested this algorithm and it worked just fine for
>> >me... I used
>> >the following compression code in mp_register_gsi():
>> >
>> >
>> >int irqs_used = 0;
>> >int gsi_to_irq[NR_IRQS] = { [0 ... NR_IRQS-1] = -1 };
>> >...
>> >
>> >if (triggering == ACPI_LEVEL_SENSITIVE
>> >I have tested this algorithm and it worked just fine for me... I
> >> >used the following compression code in mp_register_gsi():
> >> >
> >> >
> >> >int irqs_used = 0;
> >> >int gsi_to_irq[NR_IRQS] = { [0 ... NR_IRQS-1] = -1 };
> >> >...
> >> >
> >> >if (triggering == ACPI_LEVE
38 matches
Mail list logo
