From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:08:56 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 CB00A931 for ; Fri, 16 Jan 2015 16:08:56 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8380478D for ; Fri, 16 Jan 2015 16:08:56 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id x3so17644431qcv.8 for ; Fri, 16 Jan 2015 08:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xwoNLAkTH885SgVrZxwiE8VT7NUywz9J+UbiHxn3Fso=; b=dhUWQzrXE7fVyfps+JDs6hXmzuUchzKxy//QK9F1EWRH/iM3HV38OPzBiwODdyDp6a YHokMT+WEM8snq/Cp6r125kHByYwYWdt5EPHv5vTApjiXPvRXYNrI0hGMKLKO2gFcKbR DWLON7v5/PvpihChChmyrfGfWschTWinxJ3YGCeouAxNRzxeTs/0PMrvIR6/xWHI8ffv VYpxKhTVKIhS5GfrvCPrD0N8uSW39adSN4Ei/nHi+SkOqHNaN+4QN5iOuaXr4X91gE/n eVy7IFDmjwFVboXVvdhCyYb0kphSaijTFRyH8R0phonCSTwuD1AZCflGK8uH3YE5annT Glsw== MIME-Version: 1.0 X-Received: by 10.224.61.1 with SMTP id r1mr5555870qah.0.1421424534871; Fri, 16 Jan 2015 08:08:54 -0800 (PST) Received: by 10.140.82.180 with HTTP; Fri, 16 Jan 2015 08:08:54 -0800 (PST) In-Reply-To: <20150116120315.7f343f66@bender.lan> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> Date: Fri, 16 Jan 2015 17:08:54 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Andrew Turner Content-Type: text/plain; charset=UTF-8 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:08:57 -0000 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. (2) We do not use per controller tables for interrupt sources in framework. It's controller responsibility to keep interrupt sources inside itself according to mapping that is transparent for framework. Further, we assume that a controller can need an internal data for its interrupt sources, so it needs to keep it in some form anyhow. Thus why to have one table for controller's interrupt sources in framework and one table for controller's interrupt sources data in controller. (3) A controller sets names to its interrupt sources. Only controller knows how an interrupt sources should be named. (4) We have three interrupt dispatch function. The need for extra IPI dispatch function I already described in previous email. However, PPI interrupts are quite different of SPI interrupts too. Now, the handling is same but we assume that could change. For example, PPI can be different on each CPU. Anyhow, PPI should be discussed more. (5) We only enable used PPI on other CPUs. (6) We only need to keep track of controllers (except the root one) to have translation from phandle_t to device_t in FDT case. There are more small differencies, different optimalizations and hacks which works, but the main thing is how the interrupt sources are organized. If you deside to give our design a try, we have no problem to arrange it to get general satisfaction. Svata