[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1164053230.8073.22.camel@localhost.localdomain>
Date: Tue, 21 Nov 2006 07:07:10 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Sergei Shtylyov <sshtylyov@...mvista.com>, linuxppc-dev@...abs.org,
linux-kernel@...r.kernel.org, dwalker@...sta.com
Subject: Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi
type IRQ handlers
On Mon, 2006-11-20 at 11:01 +0100, Ingo Molnar wrote:
> so the question is not 'is there an ACK' (all non-MSI-type-of IRQ
> delivery mechanisms have some sort of ACK mechanism), but what is the
> precise structure of ACK-ing an IRQ that the host recieves.
>
> on PPC64, 'get the vector' initiates an ACK as well - is that done
> before handle_irq() is done?
Yes.
> > So by doing a mask followed by an eoi, you essentially mask the
> > interrupt preventing further delivery of that interrupt and lower the
> > CPU priority in the PIC thus allowing processing of further
> > interrupts.
>
> correct, that's what should happen.
>
> > Are there other fasteoi controllers than the ones I have on powerpc
> > anyway ?
>
> well, if you mean the x86 APICs, there you get the vector 'for free' as
> part of the IRQ entry call sequence, and there's an EOI register in the
> local APIC that notifies the IRQ hardware, lowers the CPU priority, etc.
> We have that as an ->eoi handler right now.
Ok, so that's like me. Which means that what you need is a specific thre
aded_fasteoi flow handler that does mask & eoi, not ack.
Note that I still think it would work in the absence of mask too if the
controller only does edge interrupts, as it is the case for the cell.
Cheers,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists