PCI resources above 4GB

[Steven Newbury]

On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu <yinghai at kernel.org> wrote:

> On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury <steve at snewbury.org.uk>
> wrote:
> > > > 
> > > > 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-down allocation was reverted, I
> > > > guess I'm going to have to dig into the archive to find out why...
> 
> Please check attached patches that will find_resource with fit. It may
> leave space for your hotplug devices.
> 
>     PCI: Should add children device res to fail list
>     PCI: Try to allocate mem64 above 4G at first
>     intel-gtt: Read 64bit for gmar_bus_addr
>     PCI: Make sure assign same align with large size resource at first
>     resource: make find_resource could return just fit resource
>     PCI: Don't allocate small resource in big empty space.
>     resource: only return range with needed align
> 
> You can get them from
> 
>             
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-pci-res-alloc

I pulled this in on top of a branch with any of the prior PCI patches since they conflict anyway.

It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.)  I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing.  Could that be why..?

Also, when not docked GMA still isn't mapped high so there's no room for the 256M radeon pref mem.

Attached /proc/iomem output for docked and undocked.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iomem.undocked
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/312977dd/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: iomem.test
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120413/312977dd/attachment.asc>