From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Newbury Subject: Re: PCI resources above 4GB Date: Thu, 12 Apr 2012 12:22:34 +0100 Message-ID: <1334229754.30606.7.camel@Nokia-N900> 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> Reply-To: Steven Newbury Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Content-ID: <1334229753.30606.6.camel@Nokia-N900> Sender: linux-pci-owner@vger.kernel.org To: Yinghai Lu , "Barnes, Jesse" , Dave Airlie Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, DRI mailing list List-Id: dri-devel@lists.freedesktop.org On Thu, 12 Apr 2012, 01:57:17 BST, Yinghai Lu wrot= e: > On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury > wrote: > > Another thought, normally the integrated graphics has an "AGP" > > aperture of 256M @0xe0000000, which is detected by agpgart-intel, t= his > > will need to be moved up above 4G to free up 0xe0000000 for the > > radeon, assuming the "agp_bridge" has a 64bit base register... =C2=A0= I > > noticed in my docked dmesg, "AGP aperture is 256M @ 0x20000000", bu= t > > the PCI base: "120000000-12fffffff : 0000:00:02.0" so only 32bits h= ave > > been set in agpgart-intel. =C2=A0Explains why i915 wasn't initialis= ed. >=20 > Attached patch should fix that high 32bit missing problem. Thanks, that fixed it! :) I had a similar patch I've been working on bu= t I had my fix in the wrong place! In the working case, initially the BIOS has set GMA to within the low s= ystem 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 a= bove 4G so they get reallocated above when possible later. It seemed t= o work, but again broke GMA despite the BAR originally containing an in= valid address as mentioned above, it seems for some reason something is= different when the conflict is detected and rellocated, compared to di= sabling it early then allocating a valid value..? It would be useful to preserve as much low PCI memory address space as = possible for hotplug devices (like my Radeon), but the other problem is= small regions get allocated at the bottom, resulting in the inability = to find large aligned regions later on. I see code to default to top-d= own allocation was reverted, I guess I'm going to have to dig into the = archive to find out why... Thanks for all your help so far, I've been learning a lot over the last= few days.