From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
Date: Mon, 28 Feb 2011 21:44:45 +0000 [thread overview]
Message-ID: <20110228214445.GD1937@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.00.1102281949050.2701@localhost6.localdomain6>
On Mon, Feb 28, 2011 at 08:16:25PM +0100, Thomas Gleixner wrote:
> So what's the gain of a barebone chained handler over a regular
> interrupt:
>
> - 100 instructions less
> - lack of statistics
We don't want statistics. Don't care how many times we go to look
at the interrupt controller - and actually it's really wrong to count
them in the first place. Counting them means that you double-count
these interrupt events, and the more layers of interrupt controllers
there are the worse that problem gets.
So no, that's a definite argument *for* chained handers.
> - lack of affinity setting via standard interfaces
Don't want affinity for them, as setting their affinity means that
you then end up forcing the affinity for the sub-interrupts too.
How you do cope with the high-level interrupt having affinity to
CPU0 but a lower level interrupt being affine to CPU1 only?
It's non-sensible, and is broken. So no, again this isn't an
argument for not using chained handlers. It's an argument *for*
them.
Sorry, but I think this stuff is right, and chained handlers like
these have their place.
next prev parent reply other threads:[~2011-02-28 21:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 13:33 [PATCH v2 0/6] Migrate GIC to fasteoi flow control Will Deacon
2011-02-28 13:33 ` [PATCH 1/6] ARM: gic: use handle_fasteoi_irq for SPIs Will Deacon
2011-02-28 13:33 ` [PATCH 2/6] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip Will Deacon
2011-02-28 13:33 ` [PATCH 3/6] ARM: tegra: " Will Deacon
2011-03-01 13:11 ` Sergei Shtylyov
2011-03-01 13:24 ` Will Deacon
2011-02-28 13:33 ` [PATCH 4/6] ARM: s5pv310: update IRQ combiner " Will Deacon
2011-03-01 13:12 ` Sergei Shtylyov
2011-02-28 13:33 ` [PATCH 5/6] ARM: msm: update GPIO chained IRQ handler " Will Deacon
2011-02-28 13:33 ` [PATCH 6/6] ARM: nmk: " Will Deacon
2011-02-28 14:03 ` Russell King - ARM Linux
2011-02-28 18:09 ` Will Deacon
2011-02-28 19:16 ` Thomas Gleixner
2011-02-28 21:44 ` Russell King - ARM Linux [this message]
2011-03-01 10:57 ` Thomas Gleixner
2011-03-01 20:19 ` Russell King - ARM Linux
2011-03-01 21:29 ` Thomas Gleixner
2011-03-01 23:14 ` Russell King - ARM Linux
2011-03-01 23:44 ` Thomas Gleixner
2011-03-01 23:50 ` Russell King - ARM Linux
2011-03-02 8:53 ` Russell King - ARM Linux
2011-03-02 9:25 ` Thomas Gleixner
2011-03-02 19:17 ` Russell King - ARM Linux
2011-03-02 20:44 ` Thomas Gleixner
2011-03-02 15:33 ` Will Deacon
2011-03-02 17:10 ` Thomas Gleixner
2011-03-04 11:47 ` Will Deacon
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=20110228214445.GD1937@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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 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.