linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Neil Brown <neilb@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Stephen Hemminger <shemminger@osdl.org>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: better leve triggered IRQ management needed
Date: Sat, 29 Apr 2006 23:59:13 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0604292343020.3690@g5.osdl.org> (raw)
In-Reply-To: <17492.21870.649828.686244@cse.unsw.edu.au>



On Sun, 30 Apr 2006, Neil Brown wrote:
> 
> The thing is: This is exactly what I am currently doing to solve the
> problem.

I'm not entirely surprised. As mentioned, the ELCR register _originally_ 
selected between EISA (level) and ISA (edge) interrupts.

But EISA (and later PCI) interrupts were not just level, they were level 
active _low_. While old ISA interrupts are edge-triggered, active _high_.

Which explains why it not only changes the trigger, but also the polarity.

Now, fast-forward a decade or two, and imagine that the world is 99% PCI, 
and nobody really has any devices that are _electrically_ ISA any more, 
but there are some legacy stuff that _looks_ like ISA. What would you do 
to simplify your life from a hw perspective?

I suspect that the thing to do is to internally just say that all 
interrupts are active low. There's no reason to _really_ have active high, 
because there are no real devices left that drive the irq line that way. 

Now, the _sane_ thing to do would be to also make all interrupts be 
level-triggered, and make the whole ELCR register be a total dummy 
register. But you can't really do that without being worried about 
breaking compatibility (for example, the timer interrupt is a 50% 
duty-cycle on/off thing, so it really _does_ end up being edge-triggered). 

So you leave the ELCR register mattering for a edge/level thing, but the 
polarity issue is just gone.

But then on _other_ southbridges, you'll have the old behaviour, and there 
simply is no way for the OS to know. Yeah, we could look at the 
nortbridge and southbridge combination, and perhaps know that some of them 
always have a "active low" polarity regardless of ELCR. But nobody even 
_documents_ these things, exactly because it's not supposed to matter.

So we're kind of screwed. We have to _act_ as if we still lived in the 
middle ages, and people still used edge-triggered active-high interrupts. 
Even when it's not necessarily the case any more..

Gaah.

That said, I'm surprised that the kernel doesn't set ELCR for you. If it 
sees a PCI device, it really should know that it's a PCI interrupt. I 
wonder if we should do the following.. (Does this automatically make it do 
the right thing on your machine?)

			Linus

---
diff --git a/arch/i386/pci/irq.c b/arch/i386/pci/irq.c
index 7323544..6e3eaef 100644
--- a/arch/i386/pci/irq.c
+++ b/arch/i386/pci/irq.c
@@ -881,6 +881,7 @@ static int pcibios_lookup_irq(struct pci
 	((!(pci_probe & PCI_USE_PIRQ_MASK)) || ((1 << irq) & mask)) ) {
 		DBG(" -> got IRQ %d\n", irq);
 		msg = "Found";
+		eisa_set_level_irq(newirq);
 	} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
 		DBG(" -> assigning IRQ %d", newirq);
 		if (r->set(pirq_router_dev, dev, pirq, newirq)) {

  reply	other threads:[~2006-04-30  6:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24 18:41 better leve triggered IRQ management needed Stephen Hemminger
2006-04-24 18:59 ` linux-os (Dick Johnson)
2006-04-24 19:02 ` Linus Torvalds
2006-04-24 19:08   ` Linus Torvalds
2006-04-24 19:53     ` Arjan van de Ven
2006-04-24 20:16       ` Alan Cox
2006-04-24 20:43         ` Arjan van de Ven
2006-04-24 21:07           ` Linus Torvalds
2006-04-24 21:20             ` Alan Cox
2006-04-24 22:26               ` Linus Torvalds
2006-04-24 21:22             ` [RFC 1/2] irq: record edge-level setting Stephen Hemminger
2006-04-24 21:49               ` Alan Cox
2006-04-24 21:41                 ` Stephen Hemminger
2006-04-24 22:34                   ` Linus Torvalds
2006-04-24 22:58                     ` Stephen Hemminger
     [not found]             ` <20060424141926.3872f921@localhost.localdomain>
2006-04-24 21:22               ` [RFC 2/2] warn on shared edge-triggered irq Stephen Hemminger
2006-04-25 15:23             ` better leve triggered IRQ management needed Michael Buesch
2006-04-24 19:15   ` Russell King
2006-04-24 20:18     ` Linus Torvalds
2006-04-24 19:25   ` Stephen Hemminger
2006-04-24 19:35   ` linux-os (Dick Johnson)
2006-04-24 20:19     ` Linus Torvalds
2006-04-24 20:50       ` linux-os (Dick Johnson)
2006-04-24 21:09         ` Linus Torvalds
2006-04-29 21:25 ` Alan Cox
2006-04-29 21:58   ` Linus Torvalds
2006-04-30  4:48     ` Neil Brown
2006-04-30  5:19       ` Linus Torvalds
2006-04-30  6:13         ` Neil Brown
2006-04-30  6:59           ` Linus Torvalds [this message]
2006-05-02  5:10             ` Neil Brown
2006-05-02 15:05               ` Linus Torvalds
2006-04-30  7:36       ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0604292343020.3690@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).