From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Paulo Zanoni <paulo.r.zanoni@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
intel-gfx@lists.freedesktop.org, x86@kernel.org,
Ingo Molnar <mingo@kernel.org>,
stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory
Date: Tue, 3 Jul 2018 12:11:35 -0700 [thread overview]
Message-ID: <20180703191135.GD734@intel.com> (raw)
In-Reply-To: <20180618174721.GC2236@intel.com>
On Mon, Jun 18, 2018 at 10:47:21AM -0700, Rodrigo Vivi wrote:
> On Fri, Jun 01, 2018 at 02:44:51PM -0700, Paulo Zanoni wrote:
> > Em Seg, 2018-05-07 �s 11:46 +0300, Joonas Lahtinen escreveu:
> > > Ingo, do you prefer to merge through our tree with your ack?
> >
> > Ping?
> >
> > >
> > > Quoting Paulo Zanoni (2018-05-04 23:32:51)
> > > > ICL changes the registers and addresses to 64 bits.
> > > >
> > > > I also briefly looked at implementing an u64 version of the PCI
> > > > config
> > > > read functions, but I concluded this wouldn't be trivial, so it's
> > > > not
> > > > worth doing it for a single user that can't have any racing
> > > > problems
> > > > while reading the register in two separate operations.
> > > >
> > > > v2:
> > > > - Scrub the development (non-public) changelog (Joonas).
> > > > - Remove the i915.ko bits so this can be easily backported in
> > > > order
> > > > to properly avoid stolen memory even on machines without i915.ko
> > > > (Joonas).
> > > > - CC stable for the reasons above.
> > > >
> > > > Issue: VIZ-9250
> > >
> > > Fixes: 412310019a20 ("drm/i915/icl: Add initial Icelake
> > > definitions.")
> > >
> > > > CC: stable@vger.kernel.org
> > >
> > > This should not be needed, it was introduced in v4.17-rc1 only.
> > >
> > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > >
> > > Regards, Joonas
> > >
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> > > > Cc: Ingo Molnar <mingo@kernel.org>
> > > > Cc: H. Peter Anvin <hpa@zytor.com>
> > > > Cc: x86@kernel.org
>
> guys, could we push this through drm-intel? ack?
> nack? comments?
Is there any concern with this patch?
any ack for push this through drm-intel?
or any nack with explanations please?
I'd like to push this for 4.19 because this is
one of the patches that blocks us on using drm-tip
on ICL.
Thanks in advance,
Rodrigo.
>
> > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > > > ---
> > > > arch/x86/kernel/early-quirks.c | 18 ++++++++++++++++++
> > > > include/drm/i915_drm.h | 4 +++-
> > > > 2 files changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/kernel/early-quirks.c
> > > > b/arch/x86/kernel/early-quirks.c
> > > > index bae0d32e327b..72c2cf961d44 100644
> > > > --- a/arch/x86/kernel/early-quirks.c
> > > > +++ b/arch/x86/kernel/early-quirks.c
> > > > @@ -340,6 +340,18 @@ static resource_size_t __init
> > > > gen3_stolen_base(int num, int slot, int func,
> > > > return bsm & INTEL_BSM_MASK;
> > > > }
> > > >
> > > > +static resource_size_t __init gen11_stolen_base(int num, int slot,
> > > > int func,
> > > > + resource_size_t
> > > > stolen_size)
> > > > +{
> > > > + u64 bsm;
> > > > +
> > > > + bsm = read_pci_config(num, slot, func,
> > > > INTEL_GEN11_BSM_DW0);
> > > > + bsm &= INTEL_BSM_MASK;
> > > > + bsm |= (u64)read_pci_config(num, slot, func,
> > > > INTEL_GEN11_BSM_DW1) << 32;
> > > > +
> > > > + return bsm;
> > > > +}
> > > > +
> > > > static resource_size_t __init i830_stolen_size(int num, int slot,
> > > > int func)
> > > > {
> > > > u16 gmch_ctrl;
> > > > @@ -500,6 +512,11 @@ static const struct intel_early_ops
> > > > chv_early_ops __initconst = {
> > > > .stolen_size = chv_stolen_size,
> > > > };
> > > >
> > > > +static const struct intel_early_ops gen11_early_ops __initconst =
> > > > {
> > > > + .stolen_base = gen11_stolen_base,
> > > > + .stolen_size = gen9_stolen_size,
> > > > +};
> > > > +
> > > > static const struct pci_device_id intel_early_ids[] __initconst =
> > > > {
> > > > INTEL_I830_IDS(&i830_early_ops),
> > > > INTEL_I845G_IDS(&i845_early_ops),
> > > > @@ -531,6 +548,7 @@ static const struct pci_device_id
> > > > intel_early_ids[] __initconst = {
> > > > INTEL_CFL_IDS(&gen9_early_ops),
> > > > INTEL_GLK_IDS(&gen9_early_ops),
> > > > INTEL_CNL_IDS(&gen9_early_ops),
> > > > + INTEL_ICL_11_IDS(&gen11_early_ops),
> > > > };
> > > >
> > > > struct resource intel_graphics_stolen_res __ro_after_init =
> > > > DEFINE_RES_MEM(0, 0);
> > > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > > > index c9e5a6621b95..c44703f471b3 100644
> > > > --- a/include/drm/i915_drm.h
> > > > +++ b/include/drm/i915_drm.h
> > > > @@ -95,7 +95,9 @@ extern struct resource intel_graphics_stolen_res;
> > > > #define I845_TSEG_SIZE_512K (2 << 1)
> > > > #define I845_TSEG_SIZE_1M (3 << 1)
> > > >
> > > > -#define INTEL_BSM 0x5c
> > > > +#define INTEL_BSM 0x5c
> > > > +#define INTEL_GEN11_BSM_DW0 0xc0
> > > > +#define INTEL_GEN11_BSM_DW1 0xc4
> > > > #define INTEL_BSM_MASK (-(1u << 20))
> > > >
> > > > #endif /* _I915_DRM_H_ */
> > > > --
> > > > 2.14.3
> > > >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-07-03 19:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180503002352.11951-1-paulo.r.zanoni@intel.com>
2018-05-04 20:32 ` [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory Paulo Zanoni
2018-05-07 8:46 ` Joonas Lahtinen
2018-06-01 21:44 ` Paulo Zanoni
2018-06-18 17:47 ` [Intel-gfx] " Rodrigo Vivi
2018-07-03 19:11 ` Rodrigo Vivi [this message]
2018-07-04 5:50 ` Ingo Molnar
2018-07-05 14:52 ` Rodrigo Vivi
2018-07-10 23:40 ` Rodrigo Vivi
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=20180703191135.GD734@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=hpa@zytor.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=paulo.r.zanoni@intel.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--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).