From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:19:23 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 7F655B51 for ; Fri, 16 Jan 2015 16:19:23 +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 51034895 for ; Fri, 16 Jan 2015 16:19:22 +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 1YC9cC-000LQL-8o; Fri, 16 Jan 2015 16:19:16 +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 t0GGJDbk000973; Fri, 16 Jan 2015 09:19:13 -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+gCpXHjQyvwtu4nuiqcBLy Message-ID: <1421425153.14601.289.camel@freebsd.org> Subject: Re: interrupt framework From: Ian Lepore To: Warner Losh Date: Fri, 16 Jan 2015 09:19:13 -0700 In-Reply-To: <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id t0GGJDbk000973 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:19:23 -0000 On Fri, 2015-01-16 at 08:34 -0700, Warner Losh wrote: > > On Jan 16, 2015, at 5:03 AM, Andrew Turner wro= te: > >=20 > > 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 ou= r > >> 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. > >=20 > > 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 o= n > > 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 in= to > > head. > >=20 > > 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 yo= ur > > change I would like to import it into the arm_intrng project branch > > first to assist the import into head. >=20 > My first look at Svatopluk=A2s code and summaries, on its surface it se= ems > to be a simpler, more generalized and more effective design than intern. > It avoids some additional overhead that=A2s always troubled me about in= tern > that I=A2ve not had the time to make good suggestions to overcome. It l= ooks > (again on its surface) easier to bring to all the architectures as well. >=20 > I haven=A2t tried to use the code so I can=A2t comment on its stability= . So of course > I can=A2t measure the differences in interrupt latencies between the tw= o. Both of > these factors would be the kind of data that would help drive the decis= ion of which > one to adapt. >=20 > Warner I haven't looked at Svata's work recently, but in general he started with the same sources that are now in the intrng branch and finished work I was in the middle of (redoing IPI stuff) when I had to set it aside. Based on other work done recently by Svata and Michal, I can only imagine that they've improved on Jakub's and my earlier effort. My main concern for importing anything (Svata's version or the current intrng branch) is for the Marvell code. It's the one that's a bit different than other modern arm systems, for example it's the reason we had the somewhat strange design for handling IPIs in the current code. Unfortunately, I think none of us have hardare for testing except the folks at Semihalf. -- Ian