From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753478AbYIXVQi (ORCPT ); Wed, 24 Sep 2008 17:16:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751705AbYIXVQa (ORCPT ); Wed, 24 Sep 2008 17:16:30 -0400 Received: from gate.crashing.org ([63.228.1.57]:43497 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbYIXVQ3 (ORCPT ); Wed, 24 Sep 2008 17:16:29 -0400 Subject: Re: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption From: Benjamin Herrenschmidt Reply-To: benh@kernel.crashing.org To: Milton Miller Cc: Paul Mackerras , linux-kernel@vger.kernel.org, Christoph Raisch , linuxppc-dev@ozlabs.org, Jan-Bernd Themann , Sebastien Dugue In-Reply-To: References: <200809231743.23828.ossthema@de.ibm.com> , <20080915100406.342e027a@bull.net> <200809240958.m8O9wM7k010996@sullivan.realtime.net> <1222251467.8277.73.camel@pasglop> Content-Type: text/plain Date: Thu, 25 Sep 2008 07:14:07 +1000 Message-Id: <1222290847.8277.81.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > There may be some implicit assumption in that we expect the cpu > priority to be returned to normal by the EOI, but there is nothing in > the hardware that requires the EOI to come from the same cpu as > accepted the interrupt for processing, with the exception of the IPI > which is per-cpu (and the only interrupt that is per-cpu). Well, there is one fundamental one: The XIRR register we access is per-CPU, so if we are to return the right processor priority, we must make sure we write the right XIRR. Same with Cell, MPIC, actually and a few others. In general I'd say most fast_eoi type PICs have this requirement. > It would probably mean adding the concept of the current cpu priority > vs interrupts and making sure we write it to hardware at irq_exit() > time when deferring the actual irq handlers. I think we need something like a special -rt variant of the fast_eoi handler that masks & eoi's in ack() before the thread is spun off, and unmasks instead of eoi() when the irq processing is complete. Ben.