From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751898AbcGFJdG (ORCPT ); Wed, 6 Jul 2016 05:33:06 -0400 Received: from www.linutronix.de ([62.245.132.108]:39066 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751024AbcGFJdB (ORCPT ); Wed, 6 Jul 2016 05:33:01 -0400 Date: Wed, 6 Jul 2016 11:30:48 +0200 (CEST) From: Thomas Gleixner To: Marc Zyngier cc: Sebastian Frias , Jason Cooper , Mason , LKML Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router In-Reply-To: <577CC83E.5080203@arm.com> Message-ID: References: <577542D1.4070307@laposte.net> <577A5260.3070001@free.fr> <577BA854.6090503@laposte.net> <20160705144151.GE3348@io.lakedaemon.net> <577BCFD2.8060203@laposte.net> <20160705155306.GG3348@io.lakedaemon.net> <577BE288.70200@laposte.net> <577BE4D8.2040601@arm.com> <577BE75B.4070109@laposte.net> <577BEABE.2010204@arm.com> <577CC83E.5080203@arm.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 6 Jul 2016, Marc Zyngier wrote: > On 05/07/16 20:24, Thomas Gleixner wrote: > > On Tue, 5 Jul 2016, Marc Zyngier wrote: > >> Hardcoded? No way. You simply implement a route allocator in your > >> driver, assigning them as needed. And yes, if you have more than 24 > >> interrupts, they get muxed. > > > > There is one caveat though. Under some circumstances (think RT) you want to > > configure which interrupts get muxed and which not. We really should have that > > option, but yes for anything which has less than 24 autorouting is the way to > > go. > > Good point. I can see two possibilities for that: > > - either we describe this DT with some form of hint, indicating what are > the inputs that can be muxed to a single output. Easy, but the DT guys > are going to throw rocks at me for being Linux-specific. That's not necessarily Linux specific. The problem arises with any other OS as well. > - or we have a way to express QoS in the irq subsystem, and a driver can > request an interrupt with a "make it fast" flag. Of course, everybody > and his dog are going to ask for it, and we're back to square one. That and the driver does not know about the particular application scenario/system configuration. > Do we have a way to detect which interrupt is more likely to be > sensitive to muxing? My hunch is that if it is requested with > IRQF_SHARED, then it is effectively muxable. Thoughts? That's too late. request_irq happens _after_ the interrupt is set up and the routing established. Thanks, tglx