From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH V3] irqchip: Add TB10x interrupt controller driver Date: Tue, 25 Jun 2013 14:33:02 +0100 Message-ID: References: <20130530211944.05F4D3E0A90@localhost> <1370014348-21121-1-git-send-email-christian.ruppert@abilis.com> <20130531221814.534DF3E08FE@localhost> <51AC15FA.4060800@synopsys.com> <20130625132925.GC30827@ab42.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <20130625132925.GC30827@ab42.lan> Sender: linux-doc-owner@vger.kernel.org To: Christian Ruppert Cc: Vineet Gupta , Thomas Gleixner , Rob Herring , Rob Landley , devicetree-discuss , "linux-doc@vger.kernel.org" , Linux Kernel Mailing List , Pierrick Hascoet List-Id: devicetree@vger.kernel.org On Tue, Jun 25, 2013 at 2:29 PM, Christian Ruppert wrote: > On Mon, Jun 03, 2013 at 10:51:06AM +0100, Grant Likely wrote: >> On Mon, Jun 3, 2013 at 5:05 AM, Vineet Gupta wrote: >> > On 06/01/2013 03:48 AM, Grant Likely wrote: >> >> 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 share >> >> handler functions for the 'normal' inputs without the custom features). >> >> That would eliminate the goofyness of listing 27 separate interrupts in >> >> the abilis,tb10x-ictl interrupts property. >> > >> > But how is this different from other systems with a primary in-core intc and a >> > cascaded external intc. How do they do it. I guess I need to read up more on this. >> >> Usually cascaded irq controllers have multiple irqs multiplexed onto a >> single irq on the parent controller. It's the 1:1 situation that makes >> this controller odd. > > You're right, this might be a bit confusing. The controller was mainly > designed as a compatibility layer between ARC770 built-in interrupts and > the rest of the system. > > Do you see a better way to drive this kind of hardware? Do you have any > other comments on the driver? > > Without this driver, arch/arc/plat-tb10x and related drivers will not > work and it would thus be good to have this in the kernel as quickly as > possible if there are no more issues with it. No, I don't have any other issues with it. It is unconventional, but the framework handles it fine the way you've set it up. g.