From patchwork Thu Apr 23 14:24:21 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gary Thomas X-Patchwork-Id: 26370 X-Patchwork-Delegate: galak@kernel.crashing.org Return-Path: X-Original-To: patchwork-incoming@bilbo.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id D1737B6F44 for ; Fri, 24 Apr 2009 00:26:27 +1000 (EST) Received: by ozlabs.org (Postfix) id D2B86DE6A3; Fri, 24 Apr 2009 00:25:10 +1000 (EST) Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [127.0.0.1]) by ozlabs.org (Postfix) with ESMTP id CEBEDDE6A2 for ; Fri, 24 Apr 2009 00:25:10 +1000 (EST) X-Original-To: linuxppc-dev@ozlabs.org Delivered-To: linuxppc-dev@ozlabs.org Received: from mail.chez-thomas.org (hermes.mlbassoc.com [76.76.67.137]) by ozlabs.org (Postfix) with ESMTP id 73FECDE14D for ; Fri, 24 Apr 2009 00:24:45 +1000 (EST) Received: by mail.chez-thomas.org (Postfix, from userid 999) id 974AD3B52A11; Thu, 23 Apr 2009 08:24:22 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from hermes.chez-thomas.org (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id C77EF3B52A05; Thu, 23 Apr 2009 08:24:21 -0600 (MDT) Message-ID: <49F07A15.9010006@mlbassoc.com> Date: Thu, 23 Apr 2009 08:24:21 -0600 From: Gary Thomas User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Kumar Gala Subject: Re: PCI changes 2.6.26 => 2.6.28 References: <49EDF333.4000200@mlbassoc.com> <49EE2CD8.7010700@mlbassoc.com> <29EEEBDE-B87C-4073-9967-E1DA7EFB0B0B@kernel.crashing.org> <49EE306D.3000401@mlbassoc.com> <49EE4729.3000100@mlbassoc.com> <612CEF05-3EFB-4947-B5FC-B35C1F9568D7@kernel.crashing.org> <46B035C0-624F-41E4-BFDD-C16479CF8FC8@kernel.crashing.org> <49EE5021.4020703@mlbassoc.com> <306F293D-44CD-4238-ADA9-BB7436C7004C@kernel.crashing.org> <49EE5A80.4030209@mlbassoc.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: linuxppc-dev@ozlabs.org X-BeenThere: linuxppc-dev@ozlabs.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@ozlabs.org Kumar Gala wrote: > > On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote: > >> Kumar Gala wrote: >>> >>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote: >>> >>>> >>>> I found the difference - in 2.6.28 the inbound/outbound windows >>>> don't seem to be set up at all. In 2.6.26, the function >>>> 'fsl_add_bridge' >>>> was common among architectures and ended up calling 'setup_pci_atmu' >>>> which created those mappings. In 2.6.28, the 83xx PCI setup code >>>> has been refactored. It uses 'mpc83xx_add_bridge' instead of >>>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-( >>>> >>>> I'm sure this is the problem. >>> >>> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code >>> calling setup_pci_atmu(). >> >> It did not directly; it called 'fsl_add_bridge' which in turn called >> 'setup_pci_atmu' > > Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx > only in 83xx. Sorry, you're correct. I got lost looking through the code :-( No matter, none of that code seems to be relevant to the change in behaviour. >> I modified the 2.6.28 driver to also call this function. Now the >> inbound/outbound windows are set up, but the bridge still has >> no allocations, so the problem remains. >> >> I need to move on; I may just live with sliding the PCI space >> up for now (doesn't really hurt anything, just seems like a hack) > > It is and you are glossing over a real bug. I have found the culprit - in arch/powerpc/kernel/pci_32.c static void fixup_hide_host_resource_fsl(struct pci_dev *dev) { int i, class = dev->class >> 8; #if 0 if ((class == PCI_CLASS_PROCESSOR_POWERPC || class == PCI_CLASS_BRIDGE_OTHER) && #else if ((class == PCI_CLASS_PROCESSOR_POWERPC) && #endif (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) && (dev->bus->parent == NULL)) { for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { dev->resource[i].start = 0; dev->resource[i].end = 0; dev->resource[i].flags = 0; } } } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, fixup_hide_host_resource_fsl); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, fixup_hide_host_resource_fsl); This function is now (the #if 0 case is in 2.6.28) tossing out the memory resources used by the PCI bridge itself. This makes everything fall over, at least on my 834x platform. This change was applied 2008-10-08, but it seems incorrect on the 834x. > Are you using u-boot to boot? If so is the board port public? My systems use RedBoot (I'm the original author of RedBoot, so one would expect that). At this moment, the code isn't public, sorry. diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c index 174b77e..a848c63 100644 --- a/arch/powerpc/kernel/pci_32.c +++ b/arch/powerpc/kernel/pci_32.c @@ -54,11 +54,12 @@ LIST_HEAD(hose_list); static int pci_bus_count; static void -fixup_hide_host_resource_fsl(struct pci_dev* dev) +fixup_hide_host_resource_fsl(struct pci_dev *dev) { int i, class = dev->class >> 8; - if ((class == PCI_CLASS_PROCESSOR_POWERPC) && + if ((class == PCI_CLASS_PROCESSOR_POWERPC || + class == PCI_CLASS_BRIDGE_OTHER) && (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) && (dev->bus->parent == NULL)) { for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {