All of lore.kernel.org
 help / color / mirror / Atom feed
* ACPI vs. ISA IRQs
@ 2003-11-04 21:28 Len Brown
       [not found] ` <1067981294.6057.20.camel-D2Zvc0uNKG8@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Len Brown @ 2003-11-04 21:28 UTC (permalink / raw)
  To: ACPI Developers; +Cc: linux-acpi

Assumption: sharing interrupts is bad.

Plan:
ACPI should attempt to distribute interrupts across
the available IRQs.

This mostly applies to PIC mode, where PCI
IRQ Link Devices are available to route PCI
interrupts to open IRQs on the PIC.
(In IO-APIC mode, we generally get no choice
 which IO-APIC pins devices are attached to)

We have acpi_irq_penalty[] (disabled at the moment)
in pci_link.c hard-coded to tell ACPI to avoid some IRQs
that are commonly used by ISA devices.

But if,say, a sound-blaster card requests exclusive access
to an IRQ that we didn't happen to reserve, and we happened
to set a PCI link device to that IRQ, then sound doesn't
work.

How to fix?

We can manually reserve IRQs to over-ride acpi_irq_penalty[],
say "acpi_irq_used=5,10" to tell ACPI not to use IRQs that
it thought by default were available.

Conversely, we could us, say, "acpi_irq_free=3,15" to tell
ACPI that some IRQs it assumed were reserved for ISA are
actually available for PCI.

I don't know of an automatic way to handle this.
Seems that the ISA devices use Plug-and-Play methods
to request IRQs, but there is no mechanism for such
an event to boot a PIRQ off an IRQ if ACPI has put it there.
Also, if such a mechanism existed, it wouldn't work
if PNP were not available to ask for an IRQ.

thoughts?

thanks,
-Len

ref:
http://bugzilla.kernel.org/show_bug.cgi?id=430
http://bugzilla.kernel.org/show_bug.cgi?id=1139
http://bugzilla.kernel.org/show_bug.cgi?id=1391





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ACPI vs. ISA IRQs
       [not found] ` <1067981294.6057.20.camel-D2Zvc0uNKG8@public.gmane.org>
@ 2003-11-05  0:03   ` James Courtier-Dutton
  2003-11-06  8:49   ` Yury V. Umanets
  1 sibling, 0 replies; 4+ messages in thread
From: James Courtier-Dutton @ 2003-11-05  0:03 UTC (permalink / raw)
  To: Len Brown; +Cc: ACPI Developers, linux-acpi

Len Brown wrote:
> Assumption: sharing interrupts is bad.
> 
> Plan:
> ACPI should attempt to distribute interrupts across
> the available IRQs.
> 
> This mostly applies to PIC mode, where PCI
> IRQ Link Devices are available to route PCI
> interrupts to open IRQs on the PIC.
> (In IO-APIC mode, we generally get no choice
>  which IO-APIC pins devices are attached to)
> 
> We have acpi_irq_penalty[] (disabled at the moment)
> in pci_link.c hard-coded to tell ACPI to avoid some IRQs
> that are commonly used by ISA devices.
> 
> But if,say, a sound-blaster card requests exclusive access
> to an IRQ that we didn't happen to reserve, and we happened
> to set a PCI link device to that IRQ, then sound doesn't
> work.
> 
> How to fix?
> 
> We can manually reserve IRQs to over-ride acpi_irq_penalty[],
> say "acpi_irq_used=5,10" to tell ACPI not to use IRQs that
> it thought by default were available.
> 
> Conversely, we could us, say, "acpi_irq_free=3,15" to tell
> ACPI that some IRQs it assumed were reserved for ISA are
> actually available for PCI.
> 
> I don't know of an automatic way to handle this.
> Seems that the ISA devices use Plug-and-Play methods
> to request IRQs, but there is no mechanism for such
> an event to boot a PIRQ off an IRQ if ACPI has put it there.
> Also, if such a mechanism existed, it wouldn't work
> if PNP were not available to ask for an IRQ.
> 
> thoughts?
> 
> thanks,
> -Len
> 
> ref:
> http://bugzilla.kernel.org/show_bug.cgi?id=430
> http://bugzilla.kernel.org/show_bug.cgi?id=1139
> http://bugzilla.kernel.org/show_bug.cgi?id=1391
> 
> 
This explains IRQs a bit: -
http://www.microsoft.com/whdc/hwdev/platform/proc/IO-APIC.mspx




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ACPI vs. ISA IRQs
       [not found] ` <1067981294.6057.20.camel-D2Zvc0uNKG8@public.gmane.org>
  2003-11-05  0:03   ` James Courtier-Dutton
@ 2003-11-06  8:49   ` Yury V. Umanets
  1 sibling, 0 replies; 4+ messages in thread
From: Yury V. Umanets @ 2003-11-06  8:49 UTC (permalink / raw)
  To: Len Brown; +Cc: ACPI Developers, linux-acpi

On Wed, 2003-11-05 at 00:28, Len Brown wrote:
> Assumption: sharing interrupts is bad.
> 
> Plan:
> ACPI should attempt to distribute interrupts across
> the available IRQs.
> 
> This mostly applies to PIC mode, where PCI
> IRQ Link Devices are available to route PCI
> interrupts to open IRQs on the PIC.
> (In IO-APIC mode, we generally get no choice
>  which IO-APIC pins devices are attached to)
> 
> We have acpi_irq_penalty[] (disabled at the moment)
> in pci_link.c hard-coded to tell ACPI to avoid some IRQs
> that are commonly used by ISA devices.
> 
> But if,say, a sound-blaster card requests exclusive access
> to an IRQ that we didn't happen to reserve, and we happened
> to set a PCI link device to that IRQ, then sound doesn't
> work.
> 
> How to fix?
> 
> We can manually reserve IRQs to over-ride acpi_irq_penalty[],
> say "acpi_irq_used=5,10" to tell ACPI not to use IRQs that
> it thought by default were available.
> 
> Conversely, we could us, say, "acpi_irq_free=3,15" to tell
> ACPI that some IRQs it assumed were reserved for ISA are
> actually available for PCI.
> 
> I don't know of an automatic way to handle this.
> Seems that the ISA devices use Plug-and-Play methods
> to request IRQs, but there is no mechanism for such
> an event to boot a PIRQ off an IRQ if ACPI has put it there.
> Also, if such a mechanism existed, it wouldn't work
> if PNP were not available to ask for an IRQ.
> 
> thoughts?
Hello,

How about to ask particular bus driver about reserved irqs, etc?
> 
> thanks,
> -Len
> 
> ref:
> http://bugzilla.kernel.org/show_bug.cgi?id=430
> http://bugzilla.kernel.org/show_bug.cgi?id=1139
> http://bugzilla.kernel.org/show_bug.cgi?id=1391
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
-- 
umka



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: ACPI vs. ISA IRQs
@ 2003-11-04 23:28 Grover, Andrew
  0 siblings, 0 replies; 4+ messages in thread
From: Grover, Andrew @ 2003-11-04 23:28 UTC (permalink / raw)
  To: Brown, Len, ACPI Developers; +Cc: linux-acpi, Diefenbaugh, Paul S

> From: Brown, Len 
> Assumption: sharing interrupts is bad.

It's not ideal, but it's not bad. PCI was designed to allow shared irqs.
IIRC we originally distributed IRQs, but we changed for exactly the
reason you describe below - ISA. (Paul correct me if I'm wrong.) And,
this is the default behavior on Windows (my T20 has 7 devices on irq 11)
to better support docking.

Sharing works OK as long as everyone doesn't take too long in their
ISRs, so that would be where I'd look first to make fixes, rather than
disturbing IRQ assignment. Plus, this problem goes away when IOAPIC
becomes the norm, doesn't it?

my 2c -- Andy

> 
> Plan:
> ACPI should attempt to distribute interrupts across
> the available IRQs.
> 
> This mostly applies to PIC mode, where PCI
> IRQ Link Devices are available to route PCI
> interrupts to open IRQs on the PIC.
> (In IO-APIC mode, we generally get no choice
>  which IO-APIC pins devices are attached to)
> 
> We have acpi_irq_penalty[] (disabled at the moment)
> in pci_link.c hard-coded to tell ACPI to avoid some IRQs
> that are commonly used by ISA devices.
> 
> But if,say, a sound-blaster card requests exclusive access
> to an IRQ that we didn't happen to reserve, and we happened
> to set a PCI link device to that IRQ, then sound doesn't
> work.
> 
> How to fix?
> 
> We can manually reserve IRQs to over-ride acpi_irq_penalty[],
> say "acpi_irq_used=5,10" to tell ACPI not to use IRQs that
> it thought by default were available.
> 
> Conversely, we could us, say, "acpi_irq_free=3,15" to tell
> ACPI that some IRQs it assumed were reserved for ISA are
> actually available for PCI.
> 
> I don't know of an automatic way to handle this.
> Seems that the ISA devices use Plug-and-Play methods
> to request IRQs, but there is no mechanism for such
> an event to boot a PIRQ off an IRQ if ACPI has put it there.
> Also, if such a mechanism existed, it wouldn't work
> if PNP were not available to ask for an IRQ.
> 
> thoughts?
> 
> thanks,
> -Len
> 
> ref:
> http://bugzilla.kernel.org/show_bug.cgi?id=430
> http://bugzilla.kernel.org/show_bug.cgi?id=1139
> http://bugzilla.kernel.org/show_bug.cgi?id=1391
> 
> 
> 
> 


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-11-06  8:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-04 21:28 ACPI vs. ISA IRQs Len Brown
     [not found] ` <1067981294.6057.20.camel-D2Zvc0uNKG8@public.gmane.org>
2003-11-05  0:03   ` James Courtier-Dutton
2003-11-06  8:49   ` Yury V. Umanets
2003-11-04 23:28 Grover, Andrew

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.