From owner-freebsd-arm@FreeBSD.ORG Mon Apr 14 16:39:47 2014 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9D8EC96 for ; Mon, 14 Apr 2014 16:39:47 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9349D1CBA for ; Mon, 14 Apr 2014 16:39:47 +0000 (UTC) Received: from zeppelin.tachypleus.net ([128.135.100.106]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s3EGdcYZ021636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Apr 2014 09:39:39 -0700 Message-ID: <534C0F48.2090302@freebsd.org> Date: Mon, 14 Apr 2014 09:39:36 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: [RFC] Refactored interrupt handling on ARM References: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> <53418D13.7030107@freebsd.org> In-Reply-To: <53418D13.7030107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;wofOXvPD4xGrq5xB+Bh/TQ== M;TOpoX/PD4xGrq5xB+Bh/TQ== X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:39:47 -0000 This is really nice! One quick question: why have you made FDT_MAP_IRQ() a public interface? Shouldn't calling the function it maps to just be a private implementation detail in nexus? -Nathan On 04/06/14 10:21, Jakub Klama wrote: > Hello all, > > It has been a long time since my SoC 2012 ended. However, I've finally > merged refactored interrupt handling framework to head and added SMP > support (IPIs). Let's start: > > What is this and how does it work? > > It's a refactored interrupt handling code for ARM which supports > multiple, stacked interrupt controllers. In particular, it creates a > clean way to support IRQ multiplexers such as GPIO controllers with > interrupt generation functionality. Approach used in this code is > somewhat similar to one usedin powerpc port. > > Every interrupt controller should implement methods from pic_if.m > interface - at least pic_config, pic_unmask, pic_mask and pic_eoi. It > should also install IRQ handler on parent interrupt controller > (specified by interrupt-parent in FDT, defaulting to nexus). > > The root interrupt controller is nexus - on ARM it has exactly one IRQ > line (typically nexus0:0) representing core IRQ signal (on MIPS, there > will be probably five of them). SoC interrupt controller, such as GIC > then installs handler on nexus0:0 IRQ and exposes itself as interrupt > controller by calling arm_register_pic(). When the interrupt arrives, > pic driver calls arm_dispatch_irq() function. > > So, for example, a typical SoC interrupt tree can look like that: > > nexus0 (provides 1 irq) > | > \-- gic0 (provides 160 irqs, uses irq nexus0:0) > | > \-- gpio0 (provides 8 irqs, uses irq gic0:42) > | | > | \-- mmcsd0 (uses irqs gpio0:1, gpio0:2) > | \-- spi0 (uses irq gpio0:3) > | ... > \-- gpio1 (provides 8 irqs, uses irq gic0:43) > \-- ehci0 (uses irq gic0:109) > ... > > Interrupt numbers used in rman are composed of two 8-bit fields: higher > 8 bits are the pic index and lower 8 bits are IRQ line number inside > particular pic (so there are 256 pics supported with maximum of 256 > irq lines on each). These numbers are generated using FDT_MAP_IRQ() > macro called from FDT code. > > As you can see from the provided dmesg logs, irq numbers are printed in > form of "pic_name:line_number", i.e: "nexus0:0" or "gic0:109". > > Of course there's still support for shared interrupt handlers - on > LPC3250 there are 3 pics attached to one in-core IRQ line. > > There's also support for IPIs. Calls to pic_ipi_get(), pic_ipi_clear(), > pic_ipi_send() and ..._init_secondary() are redirected to one interrupt > controller registered as capable to do IPIs. There can be only one > interrupt controller with IPI support registered (and certainly not the > root one). > > Code was tested on following platforms: > * EA3250 (arm/lpc) > * Pandaboard (arm/ti) (both with SMP enabled and disabled) > > Merging it would not require any changes in existing ARM ports (unless > they will be adopted to new framework and will have ARM_INTRNG option > enabled), except for adding arm/arm/intr.c to their file lists (as it's > now not compiled-in by default). That was tested too. > > dmesg outputs can be found there: > * http://people.freebsd.org/~jceel/intrng/pandaboard.dmesg.txt > * http://people.freebsd.org/~jceel/intrng/ea3250.dmesg.txt > > diff against head as of r264192: > * http://people.freebsd.org/~jceel/intrng/intrng.diff > > git branch containing the changes: > * https://github.com/jceel/freebsd-arm-intrng/tree/intrng > > What do you think about that? That code probably needs some > improvements, especially in IPI/SMP area, but I think it's a step > further in interrupt handling on ARM. > > I really appreciate any comments and opinions. > > Regards, > Jakub > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >