From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932325AbcGFQtQ (ORCPT <rfc822;w@1wt.eu>);
	Wed, 6 Jul 2016 12:49:16 -0400
Received: from outbound1.eu.mailhop.org ([52.28.251.132]:40105 "EHLO
	outbound1.eu.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932275AbcGFQtO (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 6 Jul 2016 12:49:14 -0400
X-MHO-User: 93af82a1-4399-11e6-ac92-3142cfe117f2
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 74.99.78.160
X-Mail-Handler: DuoCircle Outbound SMTP
X-DKIM: OpenDKIM Filter v2.6.8 io 95B5F80025
Date: Wed, 6 Jul 2016 16:49:04 +0000
From: Jason Cooper <jason@lakedaemon.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>, Sebastian Frias <sf84@laposte.net>,
        Mason <slash.tmp@free.fr>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router
Message-ID: <20160706164904.GK3348@io.lakedaemon.net>
References: <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>
 <alpine.DEB.2.11.1607052123060.4083@nanos>
 <577CC83E.5080203@arm.com>
 <alpine.DEB.2.11.1607061127380.4083@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1607061127380.4083@nanos>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jul 06, 2016 at 11:30:48AM +0200, Thomas Gleixner wrote:
> 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.

I could see a property

	irq,no-mux = <3 7 13 19 23 ...>;

Or "irq,fastpath".  It's describing an optimal configuration of the
system.  $driver for $OS can route those first individually.  The others
would be eligible for muxing.

thx,

Jason.