From owner-freebsd-ppc@FreeBSD.ORG Fri Sep 12 14:50:54 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 919B21065740; Fri, 12 Sep 2008 14:50:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 090708FC1A; Fri, 12 Sep 2008 14:50:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8CEoWj4046477; Fri, 12 Sep 2008 10:50:44 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nathan Whitehorn Date: Fri, 12 Sep 2008 10:33:24 -0400 User-Agent: KMail/1.9.7 References: <48C69864.3010208@freebsd.org> <200809111651.05462.jhb@freebsd.org> <48C9981B.2020808@freebsd.org> In-Reply-To: <48C9981B.2020808@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809121033.24809.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 12 Sep 2008 10:50:45 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8227/Fri Sep 12 07:48:22 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Peter Grehan , freebsd-ppc@freebsd.org Subject: Re: Call for testers: Apple ATA DMA 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: Fri, 12 Sep 2008 14:50:54 -0000 On Thursday 11 September 2008 06:13:47 pm Nathan Whitehorn wrote: > John Baldwin wrote: > > On Thursday 11 September 2008 02:32:10 pm Peter Grehan wrote: > > > >> Hi John, > >> > >> > >>> So when I did the MSI stuff I had assumed (apparently incorrectly), that > >>> > > PCI > > > >>> functions would only every have 1 non-MSI interrupt (since there is only a > >>> single INTLINE config register). Is the extra interrupt coming from OF? > >>> > > If > > > >>> so, does OF support MSI at all? You could always change the OF PCI bus > >>> driver to not do MSI and use rid 1 IRQ for the OF indicated IRQ for a PCI > >>> device by having custom alloc_resource/setup_intr/teardown_intr methods. > >>> > >> Int lines on the Mac go directly into the OpenPIC, allowing as many > >> int sources as desired. The intline config register isn't really used, > >> though there is code that attempts to read the OFW interrupt properties > >> and then program that register to avoid messing with the PCI common > >> code. Unfortunately, some Mac devices ignore writes to that register :( > >> The G5 does support MSI. > >> > >> I had sent a possible solution to Nathan (Nathan: check your junk :) > >> that in pci_setup_intr did something like: > >> > >> if (dinfo->cfg.msi.msi_addr > 0) { > >> ... > >> } else if (dinfo->cfg.msi.msix_alloc > 0) { > >> ... > >> } else { > >> #ifndef __powerpc__ > >> KASSERT("No MSI or MSI-X interrupts allocated") > >> #endif > >> } > >> > >> There's probably a bunch of other places that need fixing but this was > >> an obvious one. > >> > > > > OFW should already have its own PCI bus driver, so I'd rather you give it its > > own bus_setup_intr() method that DTRT for these interrupt resources (rid > 0 > > and !MSI) and then calls pci_setup_intr() for the rest. Then you don't have > > to add MD hacks to the generic PCI bus driver. > > > It doesn't on PowerPC. There are a bunch of hacks done at attach-time to > compensate for this (see ofw_pci_fixup()). It might be nice to import > sparc64's PCI OFW bus code, though. Ah, yeah, it certainly might be. Having separate PCI bus drivers for ACPI vs. not (and all the various PCI bridge drivers) helped detangle a bunch of mess in PCI and made ACPI support a lot easier. -- John Baldwin