[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0911302216030.24119@localhost.localdomain>
Date: Mon, 30 Nov 2009 22:23:46 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
cc: LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
David Brownell <dbrownell@...rs.sourceforge.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...e.hu>, Nicolas Pitre <nico@...vell.com>,
Eric Miao <eric.y.miao@...il.com>,
John Stultz <johnstul@...ibm.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Remy Bohmer <linux@...mer.net>,
Hugh Dickins <hugh.dickins@...cali.co.uk>,
Andrea Gallo <andrea.gallo@...ricsson.com>,
Jamie Lokier <jamie@...reable.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: Get rid of IRQF_DISABLED - (was [PATCH] genirq: warn about
IRQF_SHARED|IRQF_DISABLED)
On Mon, 30 Nov 2009, Uwe Kleine-König wrote:
> I think there is
>
> 3) you can only benefit from decent priority hardware if irqs are
> processed while irqs are enabled.
>
> I think
>
> git grep handle_fasteoi_irq
>
> gives an overview here: some hits in arch/powerpc, arch/sparc and
> arch/x86/kernel/apic/io_apic.c. (There is handle_prio_irq in
No. That handler is not an indicator for prio hardware actively used
in the sense of allowing higher prio interrupts to interrupt a current
running lower priority one. It can be used when the irq controller
does not fire the interrupt again before the eoi acknowledge has been
done.
Thanks,
tglx
Powered by blists - more mailing lists