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
> 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 fr
* 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 no
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 e
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 unde
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 tha
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
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
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 thre
* 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
> ---
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 st
> 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 t
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 po
* 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 usin
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" aro
* 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 ha
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 effe
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 lik
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]>
---
warthog>diffstat -p1 frv-tickadj-2618rc5mm1.
19 matches
Mail list logo
