linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Cc: 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 <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] x86/gpu: add JSL stolen memory support
Date: Wed, 4 Nov 2020 11:35:56 -0600	[thread overview]
Message-ID: <20201104173556.GA359362@bjorn-Precision-5520> (raw)
In-Reply-To: <20201104120506.172447-1-tejaskumarx.surendrakumar.upadhyay@intel.com>

[+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 <lucas.demarchi@intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>

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.

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"?

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.

How is this *supposed* to work?  Is there something we can do in E820
or other resource management that would make this easier?

> ---
>  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")
  ...

  reply	other threads:[~2020-11-04 17:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-04 12:05 [PATCH] x86/gpu: add JSL stolen memory support Tejas Upadhyay
2020-11-04 17:35 ` Bjorn Helgaas [this message]
2020-11-05  9:46   ` Joonas Lahtinen
2020-11-05 14:17     ` Bjorn Helgaas
2020-11-06  9:39       ` Daniel Vetter
2020-11-18 12:10         ` Surendrakumar Upadhyay, TejaskumarX
2020-11-18 16:02         ` Bjorn Helgaas
2020-11-18 21:57           ` Daniel Vetter
2020-11-18 23:14             ` Bjorn Helgaas
2020-11-19  9:37               ` Daniel Vetter
2020-11-19 19:19                 ` Bjorn Helgaas
2020-11-19 22:01                   ` Jesse Barnes
2020-11-30 10:44                     ` Surendrakumar Upadhyay, TejaskumarX
2020-11-30 16:51                       ` Bjorn Helgaas
2020-12-02  5:21                         ` Surendrakumar Upadhyay, TejaskumarX
2020-12-02 20:22                           ` Bjorn Helgaas
2020-12-03  3:23                             ` Surendrakumar Upadhyay, TejaskumarX
2020-12-03  8:46                             ` Joonas Lahtinen
2020-12-03 15:25                               ` Bjorn Helgaas
2020-12-03 16:09                                 ` Surendrakumar Upadhyay, TejaskumarX
2021-01-20 10:04                                   ` Surendrakumar Upadhyay, TejaskumarX
2022-01-20  1:10                     ` Lucas De Marchi
2022-01-20  7:35                       ` Joonas Lahtinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201104173556.GA359362@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=airlied@linux.ie \
    --cc=bp@alien8.de \
    --cc=daniel@ffwll.ch \
    --cc=hariom.pandey@intel.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=tejaskumarx.surendrakumar.upadhyay@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).