From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 721EEDDDFE for ; Thu, 22 Feb 2007 18:01:42 +1100 (EST) In-Reply-To: <20070222011811.GA18364@localhost.localdomain> References: <200702212325.l1LNPBwL007793@ld0164-tx32.am.freescale.net> <20070222011811.GA18364@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <45b623f395654fc4f4920b9553794def@kernel.crashing.org> From: Segher Boessenkool Subject: Re: [PATCH] powerpc: document new interrupt-array property Date: Thu, 22 Feb 2007 08:01:31 +0100 To: David Gibson Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, Stuart Yoder List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >> what problem is this trying to solve? > > As he says, it's for devices with interrupts routed to multiple > controllers. The normal interrupts property assumes a single > interrupt parent for a device. This is needed on most 4xx boards, > where the MAL has 5 interrupts, some of which are on UIC0 and some of > which are on UIC1. At the moment the Ebony port deals with this using > an "interesting" hack, treating the MAL as an interrupt nexus for > itself, using an interrupt-map to remap its interrupts to the two > controllers. Not really a hack, this is documented in the interrupt binding: > 3.3. "interrupt-map" property > At any level in the interrupt tree, a mapping may need to take > place between the child interrupt domain and the parent=92s. This > is represented by a new property called "interrupt-map". Note it says "*any* level". > The interrupt-array proposal does the same thing much > more neatly and compactly. Sure, for every specific case one can envision a more neat and compact device tree ;-P If in a certain tree you have this "problem" with not only the MAL but with lots of devices, you could introduce a "fake" interrupt nexus that doesn't represent a physical device as such, but that represents the combined cascaded interrupt controllers, and maps the interrupts to the nodes for the "physical" interrupt controllers. Just don't make the mistake of putting an "interrupt-controller" property in there and all is just fine. As an added bonus you end up with one single namespace for the interrupts (one interrupt domain in interrupt-mapping speak), which is probably what the chip documentation does as well. Segher