RE: ACPI vs. ISA IRQs

RE: ACPI vs. ISA IRQs

[Grover, Andrew]

> 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/

Re: RE: ACPI vs. ISA IRQs

[Matthew Wilcox]

On Tue, Nov 04, 2003 at 03:28:54PM -0800, Grover, Andrew wrote:
> > From: Brown, Len 
> > Assumption: sharing interrupts is bad.
> > How to fix?

I would ask Linus.  He tends to have pretty strong opinions on how
this kind of thing should be done.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
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/

Re: RE: ACPI vs. ISA IRQs

[Len Brown]

Re-reading my message I realize I wrote it backwards with the
unimportant part first.

Forget the IRQ sharing/performance part -- that is just a nice-to-have. 
Yes, if you want fast interrupts, you wouldn't be using the PIC in the
first place.

The unsolved issue is what happens when an ISA device needs to claim an
IRQ that ACPI has routed PCI to.  Declining to re-route active PCI link
devices and/or piling up all the PCI devices on the same IRQ make this
problem less frequent, but it doesn't make it go away.

The patch I just sent out should be able to manually cope with the issue
-- though the user has to know enough to figure out what IRQ is at issue
and to use the cmdline flag.

I think the automatic fix would require ACPI to re-program the link
device off an IRQ that is later requested by an ISA device...

-Len

On Tue, 2003-11-04 at 18:28, Grover, Andrew wrote:
> > 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/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
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/

RE: RE: ACPI vs. ISA IRQs

[Grover, Andrew]

> From: Brown, Len 
> I think the automatic fix would require ACPI to re-program the link
> device off an IRQ that is later requested by an ISA device...

Sounds good to me. I think this implies infrastructure that does not yet
exist. request_irq would have to do something like "if requested
interrupt is used but SA_SHIRQ, and the requestor is requesting it
unshared, move the current guys off it (call ACPI to reprogram links),
set it back to ISA trigger/polarity, and return success."

Ya?

Which then raises the question, can we reassign irqs under a device and
have things keep working? Or do we need to tell the driver its irq is
now different, possibly with interrupts disabled?

just rambling -- Andy

> 
> -Len
> 
> On Tue, 2003-11-04 at 18:28, Grover, Andrew wrote:
> > > 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/
> > _______________________________________________
> > Acpi-devel mailing list
> > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> 


-------------------------------------------------------
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/