From: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jesse Barnes <jsbarnes@google.com>,
Daniel Vetter <daniel@ffwll.ch>,
"Linux PCI" <linux-pci@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
X86 ML <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"Roper, Matthew D" <matthew.d.roper@intel.com>,
"Pandey, Hariom" <hariom.pandey@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
David Airlie <airlied@linux.ie>
Subject: RE: [PATCH] x86/gpu: add JSL stolen memory support
Date: Wed, 20 Jan 2021 10:04:26 +0000 [thread overview]
Message-ID: <SN6PR11MB34215740DC23DEB73D85B016DFA20@SN6PR11MB3421.namprd11.prod.outlook.com> (raw)
In-Reply-To: <SN6PR11MB34212EA0A59FB5827D3D4C9DDFF20@SN6PR11MB3421.namprd11.prod.outlook.com>
Hello,
Have we decided anything on this patch?
Thanks,
Tejas
> -----Original Message-----
> From: Surendrakumar Upadhyay, TejaskumarX
> Sent: 03 December 2020 21:40
> To: Bjorn Helgaas <helgaas@kernel.org>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>
> Cc: Jesse Barnes <jsbarnes@google.com>; Daniel Vetter <daniel@ffwll.ch>;
> Linux PCI <linux-pci@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; X86 ML <x86@kernel.org>; Borislav Petkov
> <bp@alien8.de>; De Marchi, Lucas <lucas.demarchi@intel.com>; Roper,
> Matthew D <matthew.d.roper@intel.com>; Pandey, Hariom
> <hariom.pandey@intel.com>; Jani Nikula <jani.nikula@linux.intel.com>; Vivi,
> Rodrigo <rodrigo.vivi@intel.com>; David Airlie <airlied@linux.ie>
> Subject: RE: [PATCH] x86/gpu: add JSL stolen memory support
>
> Okay then I will wait for someone to respond with "Reviewed-by". So this can
> be merged.
>
> Thanks,
> Tejas
>
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> > Sent: 03 December 2020 20:55
> > To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: Surendrakumar Upadhyay, TejaskumarX
> > <tejaskumarx.surendrakumar.upadhyay@intel.com>; Jesse Barnes
> > <jsbarnes@google.com>; Daniel Vetter <daniel@ffwll.ch>; Linux PCI
> > <linux- pci@vger.kernel.org>; Linux Kernel Mailing List <linux-
> > kernel@vger.kernel.org>; X86 ML <x86@kernel.org>; Borislav Petkov
> > <bp@alien8.de>; De Marchi, Lucas <lucas.demarchi@intel.com>; Roper,
> > Matthew D <matthew.d.roper@intel.com>; Pandey, Hariom
> > <hariom.pandey@intel.com>; Jani Nikula <jani.nikula@linux.intel.com>;
> > Vivi, Rodrigo <rodrigo.vivi@intel.com>; David Airlie
> > <airlied@linux.ie>
> > Subject: Re: [PATCH] x86/gpu: add JSL stolen memory support
> >
> > On Thu, Dec 03, 2020 at 10:46:29AM +0200, Joonas Lahtinen wrote:
> > > Quoting Bjorn Helgaas (2020-12-02 22:22:53)
> > > > On Wed, Dec 02, 2020 at 05:21:58AM +0000, Surendrakumar Upadhyay,
> > TejaskumarX wrote:
> > > > > Yes it fails all the tests which are allocating from this stolen
> > > > > memory bunch. For example IGT tests like "
> > > > > igt@kms_frontbuffer_tracking@-[fbc|fbcpsr].* |
> > > > > igt@kms_fbcon_fbt@fbc.* " are failing as they totally depend to
> > > > > work on stolen memory.
> > >
> > > That's just because we have de-duped the stolen memory detection code.
> > > If it's not detected at the early quirks, it's not detected by the
> > > driver at all.
> > >
> > > So if the patch is not merged to early quirks, we'd have to refactor
> > > the code to add alternative detection path to i915. Before that is
> > > done, the failures are expected.
> > >
> > > > I'm sure that means something to graphics developers, but I have
> > > > no idea! Do you have URLs for the test case source, outputs,
> > > > dmesg log, lspci info, bug reports, etc?
> > >
> > > The thing is, the bug reports for stuff like this would only start
> > > to flow after Jasperlake systems are shipping widely and the less
> > > common OEMs start integrating it to into strangely behaving BIOSes.
> > > Or that is the assumption.
> > >
> > > If it's fine to merge this through i915 for now with an Acked-by,
> > > like the previous patches, that'd be great. We can start a
> > > discussion on if the new platforms are affected anymore. But I'd
> > > rather not drop it before we have that understanding, as the
> > > previous problems have included boot time memory corruption.
> > >
> > > Would that work?
> >
> > Like I said, I'm not objecting if somebody else wants to apply this.
> >
> > I'm just pointing out that there's a little bit of voodoo here because
> > it's not clear what makes a BIOS strangely behaving or what causes
> > boot-time memory corruption, and that means we don't really have any
> > hope of resolving this stream of quirk updates.
> >
> > Bjorn
next prev parent reply other threads:[~2021-01-20 11:30 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
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 [this message]
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=SN6PR11MB34215740DC23DEB73D85B016DFA20@SN6PR11MB3421.namprd11.prod.outlook.com \
--to=tejaskumarx.surendrakumar.upadhyay@intel.com \
--cc=airlied@linux.ie \
--cc=bp@alien8.de \
--cc=daniel@ffwll.ch \
--cc=hariom.pandey@intel.com \
--cc=helgaas@kernel.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=jsbarnes@google.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=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).