[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

Chris Wilson chris at chris-wilson.co.uk
Mon Mar 11 16:09:02 PDT 2013


On Mon, Mar 11, 2013 at 11:50:48PM +0100, Daniel Vetter wrote:
> On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
> > On 03/07/2013 09:28 PM, Tejun Heo wrote:
> > > On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu <yinghai at kernel.org> wrote:
> > >> They are not using memblock_find_in_range(), so 1ULL<< will not help.
> > >>
> > >> Really hope i915 drm guys could clean that hacks.
> > > 
> > > The code isn't being used.  Just leave it alone.  Maybe add a comment.
> > >  The change is just making things more confusing.
> > > 
> > 
> > Indeed, but...
> > 
> > Daniel: can you guys clean this up or can we just remove the #if 0 clause?
> 
> I guess we could just put this into a comment explaining where stolen
> memory for the gfx devices is at on gen2. But tbh I don't mind if we just
> keep the #if 0 code around. For all newer platforms we can get at that
> offset through mch bar registers, so I don't really care.

If you want to keep the comment accurate
s/max_low_pfn_mapped/max_pfn_mapped/ as the machines in question don't
support more than 4GiB anyway. Or you can help address the underlying
issue of figuring out how we can derive the location of the stolen
memory which is reserved by the BIOS but not communicated to the OS.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list