From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965190AbcFMH6j (ORCPT ); Mon, 13 Jun 2016 03:58:39 -0400 Received: from foss.arm.com ([217.140.101.70]:49422 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965154AbcFMH6h (ORCPT ); Mon, 13 Jun 2016 03:58:37 -0400 Subject: Re: Using irq-crossbar.c To: Mason References: <575ADEBA.2030202@laposte.net> <575AE52E.9020005@arm.com> <575B16BD.50600@free.fr> <20160611105840.69324f8e@arm.com> <575C304F.2070303@free.fr> <20160612110048.3dd5ea17@arm.com> <575D689E.9080205@free.fr> Cc: Sebastian Frias , Thomas Gleixner , LKML , Grygorii Strashko , Mans Rullgard From: Marc Zyngier X-Enigmail-Draft-Status: N1110 Organization: ARM Ltd Message-ID: <575E67A9.9020003@arm.com> Date: Mon, 13 Jun 2016 08:58:33 +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: <575D689E.9080205@free.fr> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/06/16 14:50, Mason wrote: > On 12/06/2016 12:00, Marc Zyngier wrote: > >> Mason wrote: >> >>> The problem with some Linux APIs is that they're logical and obvious >>> to people who've been using them for years. For newcomers, it's not >>> always so obvious. >>> >>> In this specific instance, the problem statement seems rather simple, >>> on the surface. An interrupt controller, X=0..127 lines in, Y=0..23 >>> lines out (connected to GIC interrupt lines 0..23) and "all" we need >>> is a way to map Xs to Ys. >>> >>> As a first order approximation, it's enough to map all Xs to 0. >>> And provide a way for the kernel to check the registers containing >>> the bit-vectors indicating which interrupt(s) fired. >> >> If that's what your hardware is, then you are taking the wrong >> approach. The irq-crossbar driver does not do that at all: it has x >> inputs and y outputs, but connects exactly *one input to one output*. >> No multiplexing. > > Connecting one input to one output is possible iff x=y right? > (In other words, a bijection.) It is *always* possible to connect anything to anything else. You were assuming that this particular driver was fitting your particular case, and it is obvious that it is not (iow: the crossbar transformation cannot be surjective). >> And the hierarchical domain infrastructure enforces a similar property: >> a Linux interrupt is dealt with at each level of the hierarchy without >> multiplexing: the "irq" is the same, while the "hwirq" varies to >> reflect the "input pin" for a given interrupt controller. >> >> In your particular case, you have an evolved chained interrupt >> controller, and nothing else. > > Is it possible to support such an "evolved chained intc" through DT only, > or does it require a few function calls from driver code? There is no such thing as "DT only". You will have to do some actual irqchip development. >>>> - You've changed the default interrupt controller to be your crossbar. >>>> Which means that all the sub-nodes are inheriting it. Have you >>>> checked that this was valid for all of these nodes? >>> >>> I'm not sure I follow. All platform interrupts flow into the platform >>> controller. Maybe other platforms have more complex setups, with >>> several cascaded controllers? >> >> Most embedded platforms do. > > My imagination is lacking, I don't see why it needs to be more > complex than N platform input lines, and M output lines feeding > into the GIC (with M <= N) It is not more complex. It is different. M. -- Jazz is not dead. It just smells funny...