From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752049AbcGGMms (ORCPT ); Thu, 7 Jul 2016 08:42:48 -0400 Received: from foss.arm.com ([217.140.101.70]:36114 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751087AbcGGMmk (ORCPT ); Thu, 7 Jul 2016 08:42:40 -0400 Subject: Re: [RFC PATCH v1] irqchip: add support for SMP irq router To: Sebastian Frias , 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> <577E4819.4010004@laposte.net> Cc: Mason , LKML , Thomas Gleixner From: Marc Zyngier Organization: ARM Ltd Message-ID: <577E4E3C.5010505@arm.com> Date: Thu, 7 Jul 2016 13:42:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <577E4819.4010004@laposte.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/07/16 13:16, Sebastian Frias wrote: > 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? The sensible thing would be to have one domain per output that muxes inputs, and a hierarchical domain for all the other inputs (which are mapped 1:1 with their output). Thanks, M. -- Jazz is not dead. It just smells funny...