From owner-freebsd-mips@FreeBSD.ORG Sat Jan 4 14:19:29 2014 Return-Path: Delivered-To: freebsd-mips@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 8F4C5783 for ; Sat, 4 Jan 2014 14:19:29 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CDAF14E6 for ; Sat, 4 Jan 2014 14:19:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYV00J00RR3WC00@smtpauth3.wiscmail.wisc.edu> for freebsd-mips@freebsd.org; Sat, 04 Jan 2014 08:19:22 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.4.140914, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYV005EFRS81X10@smtpauth3.wiscmail.wisc.edu> for freebsd-mips@freebsd.org; Sat, 04 Jan 2014 08:19:22 -0600 (CST) Message-id: <52C81868.4050408@freebsd.org> Date: Sat, 04 Jan 2014 09:19:20 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: freebsd-mips@freebsd.org Subject: Re: mips_pic_if branch References: <52B997AF.70407@freebsd.org> In-reply-to: <52B997AF.70407@freebsd.org> X-Enigmail-Version: 1.6 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 14:19:29 -0000 Has anyone had a chance to try this out? I can't continue improvement work on dev/fdt without it and its blocking some patches to support some Microtik hardware, so testing would be really appreciated. -Nathan On 12/24/13 09:18, Nathan Whitehorn wrote: > I spent a little while trying to convert MIPS to use an interrupt domain > system that is orthogonal to the bus topology. The goal, from my end, is > to clean up some hacks in dev/fdt; the code is adapted with few changes > from PowerPC, which has supported this for a while. The changes should > provide a great deal more flexibility in terms of interrupt handling, in > particular by allowing discrete PIC drivers that handle their own > interrupt setup and configuration, while simultaneously reducing code > duplication. > > The wrinkle is that I don't have any MIPS hardware and can only test in > QEMU. So I'd appreciate any tests or comments. The branch can be found at: > svn://svn.freebsd.org/base/user/nwhitehorn/mips_pic_if > > The BERI kernels I suspect are broken due to some features I could not > figure out. Everything else should, in principle, work. > > The general layout of how this works is as follows: > - An individual PIC implements a set of KOBJ methods that map an IRQ > line to an opaque "vector" number and control masking/unmasking etc. > When an interrupt is taken, either through the PIC_DISPATCH method or a > cascaded interrupt via the PIC's IRQ line, the PIC calls > mips_dispatch_intr(vector, trapframe) to trigger interrupt processing. > - Interrupt domains are mapped using an interrupt domain identifier > number (usually the iparent phandle for FDT systems) and an IRQ line. > The function mips_get_irq() returns an opaque number that uniquely > describes this interrupt system-wide. > - Each PIC registers itself using mips_register_pic() in its attach > method with the system. Note that this can happen either before or after > its child interrupts are configured -- the code in intr_machdep.c delays > all interrupt configuration until the relevant PIC device attached. > -Nathan >