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

[Surendrakumar Upadhyay, TejaskumarX]

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@xxxxxxxxxx>
> Sent: 03 December 2020 20:55
> To: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Surendrakumar Upadhyay, TejaskumarX
> <tejaskumarx.surendrakumar.upadhyay@xxxxxxxxx>; Jesse Barnes
> <jsbarnes@xxxxxxxxxx>; Daniel Vetter <daniel@xxxxxxxx>; Linux PCI <linux-
> pci@xxxxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>; X86 ML <x86@xxxxxxxxxx>; Borislav Petkov
> <bp@xxxxxxxxx>; De Marchi, Lucas <lucas.demarchi@xxxxxxxxx>; Roper,
> Matthew D <matthew.d.roper@xxxxxxxxx>; Pandey, Hariom
> <hariom.pandey@xxxxxxxxx>; Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>; Vivi,
> Rodrigo <rodrigo.vivi@xxxxxxxxx>; David Airlie <airlied@xxxxxxxx>
> 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