Re: [PATCH] x86/gpu: add JSL stolen memory support

[Bjorn Helgaas]

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