From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753385AbcFLNul (ORCPT ); Sun, 12 Jun 2016 09:50:41 -0400 Received: from smtp4-g21.free.fr ([212.27.42.4]:27307 "EHLO smtp4-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752043AbcFLNuk (ORCPT ); Sun, 12 Jun 2016 09:50:40 -0400 Subject: Re: Using irq-crossbar.c To: Marc Zyngier Cc: Sebastian Frias , Thomas Gleixner , LKML , Grygorii Strashko , Mans Rullgard 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> From: Mason Message-ID: <575D689E.9080205@free.fr> Date: Sun, 12 Jun 2016 15:50:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <20160612110048.3dd5ea17@arm.com> 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/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.) > 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? >> Is this Doxygen format? Is there a make target to generate >> some documentation? > > Try "make help". Documentation targets: Linux kernel internal documentation in different formats: htmldocs - HTML pdfdocs - PDF psdocs - Postscript xmldocs - XML DocBook mandocs - man pages installmandocs - install man pages generated by mandocs cleandocs - clean all generated DocBook files >>> - 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) (Our previous intc had N=64 and M=3; the new one has N=128 and M=24) Regards.