Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754355Ab3CKXJO (ORCPT ); Mon, 11 Mar 2013 19:09:14 -0400 Received: from mga03.intel.com ([143.182.124.21]:20283 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753839Ab3CKXJK (ORCPT ); Mon, 11 Mar 2013 19:09:10 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,825,1355126400"; d="scan'208";a="268862727" Date: Mon, 11 Mar 2013 23:09:02 +0000 From: Chris Wilson To: "H. Peter Anvin" , Tejun Heo , Yinghai Lu , Thomas Gleixner , Ingo Molnar , Andrew Morton , Thomas Renninger , Tang Chen , linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , David Airlie , Jacob Shin , linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped Message-ID: <20130311230902.GC18499@cantiga.alporthouse.com> Mail-Followup-To: Chris Wilson , "H. Peter Anvin" , Tejun Heo , Yinghai Lu , Thomas Gleixner , Ingo Molnar , Andrew Morton , Thomas Renninger , Tang Chen , linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , David Airlie , Jacob Shin , linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org References: <1362718720-27048-1-git-send-email-yinghai@kernel.org> <1362718720-27048-2-git-send-email-yinghai@kernel.org> <20130308051059.GC14556@mtj.dyndns.org> <51398096.1060304@zytor.com> <20130311225048.GA3872@bremse> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130311225048.GA3872@bremse> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1557 Lines: 35 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/