From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ruppert Subject: Re: [PATCH V3] irqchip: Add TB10x interrupt controller driver (2) Date: Mon, 3 Jun 2013 10:00:04 +0200 Message-ID: <20130603080001.GA31808@ab42.lan> References: <20130530211944.05F4D3E0A90@localhost> <1370014348-21121-1-git-send-email-christian.ruppert@abilis.com> <20130531221814.534DF3E08FE@localhost> <20130601110133.GA4051@ab42.lan> <51AC2A99.30709@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <51AC2A99.30709@synopsys.com> Sender: linux-doc-owner@vger.kernel.org To: Vineet Gupta Cc: Grant Likely , Thomas Gleixner , Rob Herring , Rob Landley , devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Pierrick Hascoet List-Id: devicetree@vger.kernel.org On Mon, Jun 03, 2013 at 11:03:13AM +0530, Vineet Gupta wrote: > On 06/01/2013 04:31 PM, Christian Ruppert wrote: > > On Fri, May 31, 2013 at 11:18:14PM +0100, Grant Likely wrote: > >> On Fri, 31 May 2013 19:32:34 +0200 (CEST), Thomas Gleixner wrote: > >>> On Fri, 31 May 2013, Christian Ruppert wrote: > [...] > >> The loop above is mapping each of the > >> interrupt inputs on the parent controller so that each child contr= oller > >> can be chained to it as an input. I can't think of how else it cou= ld be > >> set up with the current code if the drivers were kept separate. > > This is exactly the intention. I haven't found an easier way to do = this > > either but I'm open to suggestions. >=20 > But the child intc must only uplink to one parent intc IRQ line. In t= hat > case why do we need to enumerate the rest of them in code. Is that a > limitation of framework or the parent intc (with it's legacy domain > instantiation) is not doing something correct. You are right, it would have been possible to "merge" several interrupt sources onto the same ARC input. This is done (where required) further down the interrupt controller hierarchy, however, and the way our hardware is designed is that every input line of the tb10x-ictl control= s a separate output line. Every one of these output lines is connected to a different ARC interrupt input. tb10x-ictl does not "merge" several interrupts: ... | 3 --+ 3 | 4 --+ 4 +-----+ | 5 --+.....+-----+ 5 |tb10x| | ARC770 6 --+.....+-----+ 6 |-ictl| | 7 --+.....+-----+ 7 | | | 8 --+.....+-----+ 8 | | | ... ... > [...] > >> If I were working on this system I'd drop the > >> snps,arc700-intc node entirely and have a single abilis,tb10x-intc= that > >> encapsulated the properties of both (you would of course want to s= hare > >> handler functions for the 'normal' inputs without the custom featu= res). > >> That would eliminate the goofyness of listing 27 separate interrup= ts in > >> the abilis,tb10x-ictl interrupts property. > > To complicate things even further, some ARC CPU built-in peripheral= s > > (e.g. timers) generate interrupts directly to the ARC built-in inte= rrupt > > controller (without going through the TB10x front-end), hence the > > "goofy" list of interrupts in the TB10x DT node. >=20 > But I presume that this is common-place for cascaded intc setups - so= me > peripherals hooking up directly to topmost intc would be normal. But = it > seems I'm not as educated in area as I really should be. Yep, that's completely normal. But it forces us to tell the driver whic= h ones of the interrupts it must manage and which ones it should ignore. Greetings, Christian --=20 Christian Ruppert , /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pr=E9-F= leuri _// | bilis Systems CH-1228 Plan-les-Oua= tes