From patchwork Sat Apr 14 18:42:27 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Newbury X-Patchwork-Id: 152544 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id BAB48B7003 for ; Sun, 15 Apr 2012 04:42:50 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755098Ab2DNSmt (ORCPT ); Sat, 14 Apr 2012 14:42:49 -0400 Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47]:17536 "EHLO mtaout01-winn.ispmail.ntl.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755041Ab2DNSmt (ORCPT ); Sat, 14 Apr 2012 14:42:49 -0400 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20120414184246.MJJB22007.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Sat, 14 Apr 2012 19:42:46 +0100 Received: from mail.snewbury.org.uk ([82.12.174.107]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20120414184246.WTBY13318.aamtaout03-winn.ispmail.ntl.com@mail.snewbury.org.uk>; Sat, 14 Apr 2012 19:42:46 +0100 X-Virus-Scanned: amavisd-new at snewbury.org.uk Received: from [IPv6:2a01:348:1e3:1::a91] ([IPv6:2a01:348:1e3:1::a91]) (authenticated bits=0) by mail.snewbury.org.uk (8.14.5/8.14.5) with ESMTP id q3EIgcwu009981 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 14 Apr 2012 19:42:38 +0100 Message-ID: <4F89C513.3000006@snewbury.org.uk> Date: Sat, 14 Apr 2012 19:42:27 +0100 From: Steven Newbury User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Steven Newbury CC: Yinghai Lu , "Barnes, Jesse" , Dave Airlie , Bjorn Helgaas , linux-pci@vger.kernel.org, DRI mailing list Subject: Re: PCI resources above 4GB References: <1333968563.5678.19.camel@infinity> <4F84110E.3000400@snewbury.org.uk> <4F8467AA.90305@snewbury.org.uk> <4F848357.3060007@snewbury.org.uk> <4F848E10.1090703@snewbury.org.uk> <1334089568.4083.2.camel@Nokia-N900> <4F84A3EC.6030903@snewbury.org.uk> <1334229754.30606.7.camel@Nokia-N900> <1334248841.2910.6.camel@Nokia-N900> <4F89B5E8.3040906@snewbury.org.uk> <4F89BC84.50308@snewbury.org.uk> In-Reply-To: <4F89BC84.50308@snewbury.org.uk> X-Enigmail-Version: 1.4 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=pqf2rKvVzeEA:10 a=xqWC_Br6kY4A:10 a=VwQbUJbxAAAA:8 a=N1CowNylAAAA:8 a=xe8BsctaAAAA:8 a=RVCnxxhd_gvFiuitfi4A:9 a=QEXdDO2ut3YA:10 a=LI9Vle30uBYA:10 a=bUinIyv6n-72GQvg:21 a=2eXR3gQjfTN3dnZT:21 a=RPFQhTo1uriB-Y_Qm-oA:9 a=mf4tOiICOQgohwIi5zsA:7 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/04/12 19:05, Steven Newbury wrote: > On 14/04/12 18:37, Steven Newbury wrote: >> On 12/04/12 17:40, Steven Newbury wrote: >>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu >>> wrote: > >>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury >>>> wrote: >>>>> Thanks, that fixed it! :) I had a similar patch I've been >>>>> working on but I had my fix in the wrong place! >>>>> >>>>> In the working case, initially the BIOS has set GMA to >>>>> within the low system DRAM 0xC0000000 obviously invalid. >>>>> This conflict is detected and it's relallocated to >>>>> 0x12000000. >>>>> >>>>> I've attempted to modify probe.c to disable 64-bit BARs not >>>>> allocated above 4G so they get reallocated above when >>>>> possible later. It seemed to work, but again broke GMA >>>>> despite the BAR originally containing an invalid address >>>>> as mentioned above, it seems for some reason something is >>>>> different when the conflict is detected and rellocated, >>>>> compared to disabling it early then allocating a valid >>>>> value..? >>>>> >> I've created a new quirk utilising an extra PCI resource flag to >> force reallocation of the resource. It's the first approach >> I've had any success at. It does work. Only "Intel Page Flush" >> now gets allocated @0xe0000000! > > > Hopefully this should fix "Intel Flush Page" Need to export pci_bus_alloc_resource_fit for intel-gtt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JxRMACgkQGcb56gMuC61LegCcCuANujog4iiIziKwFtcCla1s 7BEAoLfLEEXKT1WhboX/m8bMBP90QCgb =zwK6 -----END PGP SIGNATURE----- commit fe2ccc15c3cd75af2a582dc6e2b4deb544aca307 Author: Steven Newbury Date: Sat Apr 14 19:37:32 2012 +0100 PCI: Export pci_bus_alloc_resource_fit() diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 6d2b073..acb51bd 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -391,6 +391,7 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *), EXPORT_SYMBOL_GPL(pci_walk_bus); EXPORT_SYMBOL(pci_bus_alloc_resource); +EXPORT_SYMBOL(pci_bus_alloc_resource_fit); EXPORT_SYMBOL_GPL(pci_bus_add_device); EXPORT_SYMBOL(pci_bus_add_devices); EXPORT_SYMBOL(pci_enable_bridges);