From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754050AbcGFKtb (ORCPT ); Wed, 6 Jul 2016 06:49:31 -0400 Received: from smtpoutz27.laposte.net ([194.117.213.102]:59654 "EHLO smtp.laposte.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751712AbcGFKt3 (ORCPT ); Wed, 6 Jul 2016 06:49:29 -0400 Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router To: Thomas Gleixner , Marc Zyngier 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> Cc: Jason Cooper , Mason , LKML From: Sebastian Frias Message-ID: <577CE234.3020405@laposte.net> Date: Wed, 6 Jul 2016 12:49:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-VR-SrcIP: 83.142.147.193 X-VR-FullState: 0 X-VR-Score: -100 X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrfeeltddrvdeigddvlecutefuodetggdotefrodftvfcurfhrohhf X-VR-Cause-2: ihhlvgemucfntefrqffuvffgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhs X-VR-Cause-3: ucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjegrtddtfeehnecuhfhrohhmpefu X-VR-Cause-4: vggsrghsthhirghnucfhrhhirghsuceoshhfkeegsehlrghpohhsthgvrdhnvghtqeenucfkphepkeef X-VR-Cause-5: rddugedvrddugeejrdduleefnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtpdhhvghloheplgdu X-VR-Cause-6: jedvrddvjedrtddrvddugegnpdhinhgvthepkeefrddugedvrddugeejrdduleefpdhmrghilhhfrhho X-VR-Cause-7: mhepshhfkeegsehlrghpohhsthgvrdhnvghtpdhrtghpthhtohepthhglhigsehlihhnuhhtrhhonhhi X-VR-Cause-8: gidruggv X-VR-AvState: No X-VR-State: 0 X-VR-State: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 07/06/2016 11:30 AM, 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. > >> - 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. > What about using 3 values for the interrupt description like the GIC does? When connecting to the GIC we say "interrupts = ;" If devices using this driver (the one from the RFC) requested the interrupt like: "interrupts = <0 38 IRQ_TYPE_LEVEL_HIGH>;" "interrupts = <2 27 IRQ_TYPE_LEVEL_HIGH>;" etc. with the first field being the "group", then the driver could create a domain for the device's IRQ (or associate it to an existing one if it has already been created). It would thus serve as a hint on how to create domains and how to share IRQs into the same line (domain). I guess I can get such information from the .translate and .alloc callbacks from a newly created domain hierarchy attached to the GIC, right? What do you think? Best regards, Sebastian