From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 11:44:23 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34030BB4 for ; Fri, 16 Jan 2015 11:44:23 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (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 E27D75F3 for ; Fri, 16 Jan 2015 11:44:22 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id l6so12496035qcy.13 for ; Fri, 16 Jan 2015 03:44:22 -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=ik+b2NY+sZFhC+8oPWMdgaqK8cQhydHSnzLFetdY7rE=; b=D/NLhBQ2to3+hCLns10rKplT13z4qz+eOt9BgGnD7ERoLd7I5xc6rP0nF1zLailKlv 5NqBy3RWzuS7yn1bCXpS0fW3G+U5UXSpnHTIqJOLu7BIEJ++TDGpcLKy16nXZMcWMs/9 O7vUF6FkC7QHZZiXR4BiENBiHg3k5kmRy5H7CnxlEla9lyVh4jFWrRzHfxV7ar26TAUh TyrjWWs/9vnmmYvCKK4ujrgDdniw4Rs/sDbg9Mn0jcTmWspc/jRkBNAqK7Y7+jzfYzdt dBcDam9yxyeMw5p924K7v88vHlS722As1i3sYh5uBw/pVYjGYyANLLmFKWfCzRs1qMpN 1p8Q== MIME-Version: 1.0 X-Received: by 10.224.166.71 with SMTP id l7mr24370319qay.50.1421408662102; Fri, 16 Jan 2015 03:44:22 -0800 (PST) Received: by 10.140.82.180 with HTTP; Fri, 16 Jan 2015 03:44:22 -0800 (PST) In-Reply-To: <20150115192624.122066dd@bender.lan> References: <20150115192624.122066dd@bender.lan> Date: Fri, 16 Jan 2015 12:44:22 +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 11:44:23 -0000 On Thu, Jan 15, 2015 at 8:26 PM, Andrew Turner wrote: > On Thu, 15 Jan 2015 14:51:17 +0100 > Svatopluk Kraus wrote: > >> Hi community, >> >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. > > I haven't ad a chance to look though it yet, but how does this compare > with what is currently on the arm_intrng branch? I've also taken Ian's > WIP change and cleaned it up so it will build with the current > interrupt framework. I've also been working on allowing the simplebus > changes to work on architectures that aren't arm. > > I'm planning on importing the branch into head soon, after fixing the > last few cross-arch issues, to allow for wider testing. > > Andrew I looked at arm_intrng project this morning and more concrete remarks are here about difference between that and our design. (1) I do not think that nexus as root interrupt controller is good abstraction. All nexus PIC methods are empty. But mainly, an interrupt framework should be responsible of dispatching interrupts on first (root) level. Not nexus. In case of vector interrupts, again, it should be coded in framework not in nexus. And framework has no usage from knowing that nexus is root interrupt controller device. Thus in our design, nexus is not root interrupt controller. (2) Only root controller can do IPIs. In your design, nexus is root controller, so real root controller must claim that can do IPIs. (2) Unmasking IPI in init_secondary is useless as that is done in release_aps(). (3) In our design, we use separated IPI handlers as each of them needs different handling. See for example comments in smp_rendezvous_action(). (4) Using of critical_section() is not allowed for some IPIs. So using intr_event_handle() for IPIs is not wanted certainly in you design. (4) We do not use pic_ipi_read(). It's controller responsibility to serve IPIs interrupt, even if there could come more IPIs on one interrupt. (5) On GIC, EOI cannot be done in post_filter method as according to manual the register value used for EIO must correspond to most recent read value from active interrupt register. For example, in our design there is a possibility to save read value to ISRC and use it in post_filter method. However, we do not do that in GIC now. 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. Svata