From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:25:07 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 385ECC54 for ; Fri, 16 Jan 2015 16:25:07 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A6D995E for ; Fri, 16 Jan 2015 16:25:06 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YC9hp-000Pj3-FQ; Fri, 16 Jan 2015 16:25:05 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0GGP2MC001021; Fri, 16 Jan 2015 09:25:02 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+v50L+GLbjC1Exio5thOVW Message-ID: <1421425502.14601.294.camel@freebsd.org> Subject: Re: interrupt framework From: Ian Lepore To: Svatopluk Kraus Date: Fri, 16 Jan 2015 09:25:02 -0700 In-Reply-To: References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:25:07 -0000 On Fri, 2015-01-16 at 17:08 +0100, Svatopluk Kraus wrote: > On Fri, Jan 16, 2015 at 1:03 PM, Andrew Turner wrote: > > On Fri, 16 Jan 2015 12:44:22 +0100 > > Svatopluk Kraus wrote: > > ... > >> It's just a few things from quick look now which are different in our > >> design. However, my intention is not read our code on behalf of you. I > >> still think that our design is more general mainly and can serve for > >> interrupt controllers better. > > > > I was asking on the differences as I'm already in the process of > > importing the arm_intrng project branch as I need something like it on > > arm64. It is also based on the same code from Jakub and Ian, I haven't > > looked at changing the design, just cleaning up the code to import into > > head. > > > > I would be happy to merge your code instead, along with my existing > > cleanups, however I would need to know why I should spend time on it as > > opposed to the current development branch. If we do decide to with your > > change I would like to import it into the arm_intrng project branch > > first to assist the import into head. > > > > Andrew > > > Well, this is the main difference in our design: > > (1) We use one global table for all interrupt sources for framework > needs. Each interrupt source is allocated only once and has been > assigned to unique interrupt number from the beginning. > While we don't have any existing examples of it, interrupt controllers can actually come and go at runtime; they can be associated with hotplug hardware. An example would be something like an i2c-based gpio extender that can generate interrupts on its gpio pins. Does the single global table allow for hotplug things to be added? Even trickier, what about when those things disappear later? I don't think we need to support this right away, I'm just asking if supporting it some day will be impossible or not. -- Ian