Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp520389pxb; Thu, 5 Nov 2020 06:21:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJzwV9/XKA1ZNNZx8yKXWyYogDQgO1Vs/bh6t23uMtC8eK3NKJ9XDi3pPHRd91LUU5aDwJlj X-Received: by 2002:a17:906:9459:: with SMTP id z25mr2640485ejx.88.1604586107057; Thu, 05 Nov 2020 06:21:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604586107; cv=none; d=google.com; s=arc-20160816; b=mkWhdIo6p/8tUpAr7MXWnxwo/kqN54i+qKsSIiuSRnYleL+1KmghDhelSzMq+l4Ix3 co0t1PBVVlOVSh1pu7PrJJMM1ZoeYduiX0cAKBul61Tfp067YDrBPRr7FgjlsouTIp8c GtIgAu34wbE+Z/Lu9AnCxvfGV38IeS7XzJVDfTkClHvGo5tZ0H+vBZVtWgBkcUGOqwKt uE7SwQnw1CB2eCydTwtzsFNEMjPqJWLXEhuz5o9w0oqfJSDMbOKBuvEvIPB+ViL9aVHg z4lwDkq7agfUCuHT/0OMt4aS8jilx1XTVM7xCCQIjMiP0l1QLKpUCb/HqfWkVyLb4DTa XoYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=fXNFEBBDRrq6lMP6TKD++ovwfgQX9etpXQMLl+HNz0g=; b=Bl+WUKvsoKnJTgxbxmFTn/AqWa3N46DZusIbnWyQkRfhj8XeexMXVkVicTmQIkQ374 x+eVZ4rGQpxZx8yEY0EA++tDjd5Mn/aNcq0A0L+xNP2C7LPAWa56xiFhZzU5aKIMvKqU hBWaxlpDozPapYChDYcuJrzv5rwf20yKSLAE/aZh7RE1cmFFxMaXcLttgx/TASbsD/HM 2McZcQhGlO+M3gAMS6+6qBd0qxFZPDpSgONVAJsq2F8S6NN7bC8P2LaiT9su3rV8CYg3 T7BNS6Fe4SfmcBT5XydLyU5dJGGiiFqGit2lAF/cfJdjaOAwVlcHV5HFvuO5RoLOzXSA RHzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=w2vObp5x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp20si1046726ejc.620.2020.11.05.06.21.21; Thu, 05 Nov 2020 06:21:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=w2vObp5x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730870AbgKEORn (ORCPT + 99 others); Thu, 5 Nov 2020 09:17:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:40288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730775AbgKEORm (ORCPT ); Thu, 5 Nov 2020 09:17:42 -0500 Received: from localhost (230.sub-72-107-127.myvzw.com [72.107.127.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3B5052073A; Thu, 5 Nov 2020 14:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604585861; bh=UDvcaHDeHELwnGnyrjkWW1mbaEvMXe4JugAAo2sR0F4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=w2vObp5xH0DLOpaXZEb6+NvsINwM8w+Uar/SS+zqNrA1Q0cFtX5/ffgvGj4oLlwC8 r4lPR3vo69dRFY4CWXBMhPl5O6u5jY941QqwixESmMv51wWQBqUlw3qoB3+Ei0xNfV pgpep30eoY+eeYPyICUOg9QD5lXLlx9K3szrZio0= Date: Thu, 5 Nov 2020 08:17:39 -0600 From: Bjorn Helgaas To: Joonas Lahtinen Cc: Tejas Upadhyay , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, bp@alien8.de, lucas.demarchi@intel.com, matthew.d.roper@intel.com, hariom.pandey@intel.com, Jani Nikula , Rodrigo Vivi , David Airlie , Daniel Vetter Subject: Re: [PATCH] x86/gpu: add JSL stolen memory support Message-ID: <20201105141739.GA493962@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160456956585.5393.4540325192433934522@jlahtine-mobl.ger.corp.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 05, 2020 at 11:46:06AM +0200, Joonas Lahtinen wrote: > Quoting Bjorn Helgaas (2020-11-04 19:35:56) > > [+cc Jani, Joonas, Rodrigo, David, Daniel] > > > > On Wed, Nov 04, 2020 at 05:35:06PM +0530, Tejas Upadhyay wrote: > > > JSL re-uses the same stolen memory as ICL and EHL. > > > > > > Cc: Lucas De Marchi > > > Cc: Matt Roper > > > Signed-off-by: Tejas Upadhyay > > > > I don't plan to do anything with this since previous similar patches > > have gone through some other tree, so this is just kibitzing. > > > > But the fact that we have this long list of Intel devices [1] that > > constantly needs updates [2] is a hint that something is wrong. > > We add an entry for every new integrated graphics platform. Once the > platform is added, there have not been changes lately. > > > IIUC the general idea is that we need to discover Intel gfx memory by > > looking at device-dependent config space and add it to the E820 map. > > Apparently the quirks discover this via PCI config registers like > > I830_ESMRAMC, I845_ESMRAMC, etc, and tell the driver about it via the > > global "intel_graphics_stolen_res"? > > We discover what is called the graphics data stolen memory. It is regular > system memory range that is not CPU accessible. It is accessible by the > integrated graphics only. > > See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/early-quirks.c?h=v5.10-rc2&id=814c5f1f52a4beb3710317022acd6ad34fc0b6b9 > > > That's not the way this should work. There should some generic, non > > device-dependent PCI or ACPI method to discover the memory used, or at > > least some way to do it in the driver instead of early arch code. > > It's used by the early BIOS/UEFI code to set up initial framebuffer. > Even if i915 driver is never loaded, the memory ranges still need to > be fixed. They source of the problem is that the OEM BIOS which are > not under our control get the programming wrong. > > We used to detect the memory region size again at i915 initialization > but wanted to eliminate the code duplication and resulting subtle bugs > that caused. Conclusion back then was that storing the struct resource > in memory is the best trade-off. > > > How is this *supposed* to work? Is there something we can do in E820 > > or other resource management that would make this easier? > > The code was added around Haswell (HSW) device generation to mitigate > bugs in BIOS. It is traditionally hard to get all OEMs to fix their > BIOS when things work for Windows. It's only later years when some > laptop models are intended to be sold with Linux. > > The alternative would be to get all the OEM to fix their BIOS for Linux, > but that is not very realistic given past experiences. So it seems > a better choice to to add new line per platform generation to make > sure the users can boot to Linux. How does Windows do this? Do they have to add similar code for each new platform? > > > --- > > > arch/x86/kernel/early-quirks.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c > > > index a4b5af03dcc1..534cc3f78c6b 100644 > > > --- a/arch/x86/kernel/early-quirks.c > > > +++ b/arch/x86/kernel/early-quirks.c > > > @@ -549,6 +549,7 @@ static const struct pci_device_id intel_early_ids[] __initconst = { > > > INTEL_CNL_IDS(&gen9_early_ops), > > > INTEL_ICL_11_IDS(&gen11_early_ops), > > > INTEL_EHL_IDS(&gen11_early_ops), > > > + INTEL_JSL_IDS(&gen11_early_ops), > > > INTEL_TGL_12_IDS(&gen11_early_ops), > > > INTEL_RKL_IDS(&gen11_early_ops), > > > }; > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/early-quirks.c?h=v5.10-rc2#n518 > > > > [2] > > May 2020 efbee021ad02 ("x86/gpu: add RKL stolen memory support") > > Jul 2019 6b2436aeb945 ("x86/gpu: add TGL stolen memory support") > > Mar 2019 d53fef0be4a5 ("x86/gpu: add ElkhartLake to gen11 early quirks") > > May 2018 db0c8d8b031d ("x86/gpu: reserve ICL's graphics stolen memory") > > Dec 2017 33aa69ed8aac ("x86/gpu: add CFL to early quirks") > > Jul 2017 2e1e9d48939e ("x86/gpu: CNL uses the same GMS values as SKL") > > Jan 2017 bc384c77e3bb ("x86/gpu: GLK uses the same GMS values as SKL") > > Oct 2015 00ce5c8a66fb ("drm/i915/kbl: Kabylake uses the same GMS values as Skylake") > > Mar 2015 31d4dcf705c3 ("drm/i915/bxt: Broxton uses the same GMS values as Skylake") > > ...