Ingo Molnar [EMAIL PROTECTED] wrote:
i cannot find Thomas' recent 2.6 one (Thomas, do you have a link to
it?), but i did one 5 years ago:
http://people.redhat.com/mingo/irq-rewrite-patches/irq-cleanup-2.4.15-B1.bz2
in general it's a large but otherwise pretty dumb patch.
I wrote my own
But funky cascading using chained flow handlers doesn't work if the cascade
must share an IRQ with some other device, right?
Indeed. Best way there is then to have a normal action handler like you
do and have it call generic_handle_irq() on the cascaded interrupts.
Ben.
-
To unsubscribe
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
No, you do a chain handler. Look at how I do it in
arch/powerpc/platform/pseries/setup.c for example. It's actually
trivial. You install a special flow handler (which means that there is
very little overhead, almost none, from the toplevel irq
On Fri, 2006-09-08 at 11:25 +0100, David Howells wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
No, you do a chain handler. Look at how I do it in
arch/powerpc/platform/pseries/setup.c for example. It's actually
trivial. You install a special flow handler (which means that there
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Please update Documentation/DocBook/genericirq.tmpl. That doesn't mention
it.
I must admit I haven't read the documentation :) I looked at the
code/patches when genirq was posted and did my powerpc implementation
based on my understanding
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Now, if you have funky cascades, then you can always group them into a
virtual irq cascade line and have a special chained flow handler that
does all the figuring out off those... it's up to you.
You make it sound so easy, but it's
* David Howells [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] wrote:
we'll get rid of that pt_regs thing centrally, from all drivers at once
- there's upstream buy-in for that already, and Thomas already generated
a test-patch for that a few months ago. But it's not a big
On Thu, 2006-09-07 at 10:55 +0100, David Howells wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Well, genirq gives you more flexibility than the current mecanism so ...
No, it doesn't because the FRV arch contains its own mechanism and I can do
what ever I like in it.
But genirq
Ingo Molnar [EMAIL PROTECTED] wrote:
So, again, why _should_ I use the generic IRQ stuff? [...]
To have shared code between architectures?
That's reasonable as far as it goes, the algorithms are similar per-arch, but
the PICs are quite ofter quite different. My FRV board here has three
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Well, genirq gives you more flexibility than the current mecanism so ...
No, it doesn't because the FRV arch contains its own mechanism and I can do
what ever I like in it.
genirq's flexibility comes at a price. Count the number of hooks in
* David Howells [EMAIL PROTECTED] wrote:
The genirq subdir all wraps up into this:
109083272 12 141923770 kernel/irq/built-in.o
1548 64 41616 650 arch/frv/kernel/irq.o
john stultz [EMAIL PROTECTED] wrote:
From this patch it looks like the FRV arch could be trivially converted
to GENERIC_TIME.
Would you consider the following, totally untested patch?
It certainly looks interesting. I'll have to study the clocksource stuff -
some FRV CPUs have an effective
* David Howells [EMAIL PROTECTED] wrote:
john stultz [EMAIL PROTECTED] wrote:
From this patch it looks like the FRV arch could be trivially
converted to GENERIC_TIME.
Would you consider the following, totally untested patch?
It certainly looks interesting. I'll have to study the
Ingo Molnar [EMAIL PROTECTED] wrote:
btw., would be nice to convert it to genirq (and irqchips) too =B-) That
would solve the kind of disable_irq_lockdep() breakage that was reported
recently.
I can think of reasons for not using that stuff also.
(1) Passing struct pt_regs *regs around is
* David Howells [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] wrote:
btw., would be nice to convert it to genirq (and irqchips) too =B-) That
would solve the kind of disable_irq_lockdep() breakage that was reported
recently.
I can think of reasons for not using that stuff
Under some circumstances I can work out which sources have triggered which
interrupts (there are various off-CPU FPGAs which implement auxiliary PICs
that
do announce their sources), but the aux-PIC channels are grouped together upon
delivery to the CPU PIC, so some of the ACK'ing has to be
Ingo Molnar [EMAIL PROTECTED] wrote:
we'll get rid of that pt_regs thing centrally, from all drivers at once
- there's upstream buy-in for that already, and Thomas already generated
a test-patch for that a few months ago. But it's not a big issue right
now.
Yay! Can you give me a pointer
Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
instead.
This patch also provides a placeholder macro for getting hardware timer data to
be filled in when such is available.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
warthogdiffstat -p1
On Tue, 2006-09-05 at 16:35 +0100, David Howells wrote:
Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
instead.
This patch also provides a placeholder macro for getting hardware timer data
to
be filled in when such is available.
From this patch it looks like the
19 matches
Mail list logo
