From owner-freebsd-ppc@FreeBSD.ORG Thu Apr 3 13:43:34 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 743561065673 for ; Thu, 3 Apr 2008 13:43:34 +0000 (UTC) (envelope-from nathanw@uchicago.edu) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 3F66F8FC26 for ; Thu, 3 Apr 2008 13:43:34 +0000 (UTC) (envelope-from nathanw@uchicago.edu) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) id <0JYR00M004SLU000@smtpauth1.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Thu, 03 Apr 2008 08:43:33 -0500 (CDT) Received: from trantor.tachypleus.net ([76.201.152.232]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPSA id <0JYR00HEZ4SKZ130@smtpauth1.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Thu, 03 Apr 2008 08:43:33 -0500 (CDT) Date: Thu, 03 Apr 2008 08:47:51 -0500 From: Nathan Whitehorn In-reply-to: To: freebsd-ppc@freebsd.org Message-id: <47F4E007.90802@uchicago.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.201.152.232 X-Spam-PmxInfo: Server=avs-10, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.4.3.63359, SenderIP=76.201.152.232 References: <47E06B23.7060400@uchicago.edu> <20080325023040.ab0daa19.stas@FreeBSD.org> <47E8527B.2050002@uchicago.edu> <47F39EF4.8040800@uchicago.edu> <47F3D2BC.7060001@uchicago.edu> <47F422A0.9080907@uchicago.edu> User-Agent: Thunderbird 2.0.0.12 (X11/20080322) Subject: Re: BMAC Ethernet Driver X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2008 13:43:34 -0000 Marcel Moolenaar wrote: > > On Apr 2, 2008, at 8:07 PM, Nathan Whitehorn wrote: > >>> "ofwdump -aP interrupts" gives: >>> ... >>> Node 0xff95fd30: escc >>> Node 0xff95ffb8: ch-a >>> interrupts: >>> 00 00 00 16 00 00 00 01 00 00 00 05 00 00 00 00 00 00 00 06 >>> 00 00 00 00 >>> Node 0xff960a08: ch-b >>> interrupts: >>> 00 00 00 17 00 00 00 01 00 00 00 07 00 00 00 00 00 00 00 08 >>> 00 00 00 00 >>> ... >>> Node 0xff970618: ata-4 >>> interrupts: >>> 00 00 00 13 00 00 00 01 00 00 00 0b 00 00 00 00 >>> Node 0xff973358: disk >>> >>> >>> Can you send me the output of ofwdump on your machine? >> >> So it looks like that corresponds to the OF output, to within the >> macio limit of 5 interrupts per device. Two of the interrupts for each >> channel (probably the first two after the main one) are the DBDMA >> interrupts for transmit and receive DMA on each UART. The others, I >> don't know. G4 machines seem to have a lot of 0 interrupts listed in >> OF. Maybe we should >> remove them? I somehow doubt that 0 is a valid IRQ. > > OpenPIC uses 2 cells per interrupt. The first being the interrupt line; > the second being the interrupt trigger properties. As such, there are > 3 interrupts per SCC channels and 2 for ATA: > SCC-A: 0x16, 0x05, 0x06 > SCC-B: 0x17, 0x07, 0x08 > ATA: 0x13, 0x0b > > It seems that the DMA interrupts are edge triggered, so we can easily > filter them out to preserve the old behaviour. Ah, ok. I wan't aware OpenPIC behaved that way -- that explains the 0 interrupts. I suppose as an alternative to filtering them out, you could make SCC use nintr/nchannels as the increment into the array of interrupts, instead of incrementing by one. Since bm depends on those DBDMA interrupts, like any DBDMA device, we shouldn't filter them out globally, and I'm hesitant to add a bunch of SCC-specific hacks to macio. We will also need them if we want to support DMA on the onboard ATA controller or want to support the AWACS sound chip. > I guess on your machine, interrupts use only 1 cell. This means we need > to fix macio(4) to interpret the "#interrupt-cells" property of the > interrupt controller in the "interrupt-parent" property... So it would seem: Node 0xff860a58: mac-io Node 0xff861220: interrupt-controller #interrupt-cells: 00 00 00 01 This sounds like a good solution. Do you want to make the patch, or do you want me to give it a try? -Nathan