From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751212AbcGGMQd (ORCPT ); Thu, 7 Jul 2016 08:16:33 -0400 Received: from smtpoutz29.laposte.net ([194.117.213.104]:48320 "EHLO smtp.laposte.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750922AbcGGMQa (ORCPT ); Thu, 7 Jul 2016 08:16:30 -0400 Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router To: Marc Zyngier , Jason Cooper 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> <577CE1DE.6080502@laposte.net> <577D0C95.2000703@arm.com> Cc: Mason , LKML , Thomas Gleixner From: Sebastian Frias Message-ID: <577E4819.4010004@laposte.net> Date: Thu, 7 Jul 2016 14:16:25 +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: <577D0C95.2000703@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-VR-SrcIP: 78.31.43.6 X-VR-FullState: 0 X-VR-Score: -100 X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrfeeltddrvdekgdehtdcutefuodetggdotefrodftvfcurfhrohhf X-VR-Cause-2: ihhlvgemucfntefrqffuvffgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhs X-VR-Cause-3: ucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjegrtddtfeehnecuhfhrohhmpefu X-VR-Cause-4: vggsrghsthhirghnucfhrhhirghsuceoshhfkeegsehlrghpohhsthgvrdhnvghtqeenucfkphepjeek X-VR-Cause-5: rdefuddrgeefrdeinecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtpdhhvghloheplgdujedvrddv X-VR-Cause-6: jedrtddrvddugegnpdhinhgvthepjeekrdefuddrgeefrdeipdhmrghilhhfrhhomhepshhfkeegsehl X-VR-Cause-7: rghpohhsthgvrdhnvghtpdhrtghpthhtohepmhgrrhgtrdiihihnghhivghrsegrrhhmrdgtohhm 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 Marc, On 07/06/2016 03:50 PM, Marc Zyngier wrote: >> I think that's where part the misunderstanding comes from. >> IMHO the output line is not a direct function of the input line. >> Any of the 64 IRQ lines entering the "old controller" (irq-tango.c) can be >> routed to any of its 3 outputs. > > Then the current DT binding isn't properly describing the HW. Ok, thanks, so it is not a good example then. >> In a nutshell: >> - "old controller": routes [0...N] => GIC inputs [2...4] >> - "new controller": routes [0...M] => GIC inputs [0...23] >> >> So, when we think about it, if the "new DT" specified 24 domains, it would >> be equivalent of the "old DT" with 3 domains, right? > > Indeed, but I consider the "old" binding to be rather misleading. It > should have been described as a router too, rather than hardcoding > things in DT. Granted, it doesn't matter much when you only have 3 > possible output lines. But with 24 outputs, that becomes much more relevant. I see. >> So, putting aside routing considerations and the discussion above, I think >> a simpler question is: if the domains should not be described in the DT, >> how can we define the IRQ sharing in the DT? > > You could have a set of sub-nodes saying something like this: > > mux-hint0 { > inputs = <1 45 127>; > } > > mux-hint1 { > inputs = <2 33>; > } > > (or maybe you can have that as direct properties, but you get the idea). > Here, you have two output pins dedicated to muxed interrupts (assuming > they are all level interrupts), and the last 22 can be freely allocated > as direct routes. > Ok, I'll try to do that. So, aside from the DT issues (that is, that it is describing domains), would it be ok to create a domain for each of the outputs? Because I was looking at: - Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt - drivers/irqchip/exynos-combiner.c - arch/arm/boot/dts/exynos4210.dtsi and what I see is that the DT basically list all outputs [0...15] connected to the parent interrupt controller, although the driver does not creates separate domains, just one. Then it attaches a chained handler for each of the outputs. On the .map callback it attaches a irqchip to the domain. There is also: - Documentation/devicetree/bindings/arm/omap/crossbar.txt - drivers/irqchip/irq-crossbar.c - arch/arm/boot/dts/dra7.dtsi This one creates a domain hierarchy linked to the parent domain and uses irq_domain_alloc_irqs_parent() and irq_domain_set_hwirq_and_chip() to attach a irqchip to the domain on the .alloc callback. Both use a single domain, as opposed to irq-tango.c which creates 3 domains. Right now irq-tango_v2.c is supposed to create one domain per output (if so the DT says) Are there guidelines regarding that? Thanks in advance. Best regards, Sebastian