From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 36B77DDF54 for ; Wed, 30 Jul 2008 07:35:57 +1000 (EST) Subject: Re: Level IRQ handling on Xilinx INTC with ARCH=powerpc From: Benjamin Herrenschmidt To: David Howells In-Reply-To: <16359.1217340857@redhat.com> References: <360961217332693@webmail22.yandex.ru> <16359.1217340857@redhat.com> Content-Type: text/plain Date: Wed, 30 Jul 2008 07:35:23 +1000 Message-Id: <1217367323.11188.263.camel@pasglop> Mime-Version: 1.0 Cc: Ingo Molnar , Thomas Gleixner , linuxppc-dev@ozlabs.org Reply-To: benh@kernel.crashing.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2008-07-29 at 15:14 +0100, David Howells wrote: > Sergey Temerkhanov wrote: > > > And handle_level_irq() which is currently used as high-level IRQ handler for > > Xilinx INTC only tries to acknowledge IRQ before ISR call. So that the IRQ > > remains asserted in INTC and after the call to desc->chip->unmask() causes > > spurious attempt to process the same IRQ again. However, call to > > desc->chip->ack() this time finishes the required procedure of IRQ > > acknowledge. > > I think I'm seeing the same on the MN10300 arch with its builtin PIC. My > soultion was to make unmask() also clear the IRQ latch in the PIC for that > channel. We perhaps want an unmask_ack() op. I've heard about similar issues on other setups... I dislike having a separate op though, not sure what's the best approach. Another one is to write a different level handler for such PICs, though that somewhat sucks too. CC'ing Ingo and Thomas who may have a better idea. Ben.