From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Newbury Subject: Re: PCI resources above 4GB Date: Sat, 14 Apr 2012 19:05:56 +0100 Message-ID: <4F89BC84.50308@snewbury.org.uk> 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050500040706060609040608" Return-path: In-Reply-To: <4F89B5E8.3040906@snewbury.org.uk> Sender: linux-pci-owner@vger.kernel.org To: Steven Newbury Cc: Yinghai Lu , "Barnes, Jesse" , Dave Airlie , Bjorn Helgaas , linux-pci@vger.kernel.org, DRI mailing list List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --------------050500040706060609040608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+JvIQACgkQGcb56gMuC63G3ACgma4pUxuwjAAJ0ACS5A32xFwa k1MAn21y2w6m+Ar+3DwH4Swy1IlicHmN =nBpy -----END PGP SIGNATURE----- --------------050500040706060609040608 Content-Type: text/x-patch; name="intel-flush-page-fit.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intel-flush-page-fit.diff" commit ccc1099a1474815f4094e8689ca0b518de464230 Author: Steven Newbury Date: Sat Apr 14 19:02:47 2012 +0100 intel-gtt: Use pci_bus_alloc_resource_fit() to allocate "Intel Flush Page". diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index 77e150e..30b1ea2 100644 --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -1036,9 +1036,9 @@ static struct agp_memory *intel_fake_agp_alloc_by_type(size_t pg_count, static int intel_alloc_chipset_flush_resource(void) { int ret; - ret = pci_bus_alloc_resource(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE, + ret = pci_bus_alloc_resource_fit(intel_private.bridge_dev->bus, &intel_private.ifp_resource, PAGE_SIZE, PAGE_SIZE, PCIBIOS_MIN_MEM, 0, - pcibios_align_resource, intel_private.bridge_dev); + pcibios_align_resource, intel_private.bridge_dev, 1); return ret; } --------------050500040706060609040608--