Okay then I will wait for someone to respond with "Reviewed-by". So this can be merged.
Thanks, Tejas > -----Original Message----- > From: Bjorn Helgaas <[email protected]> > Sent: 03 December 2020 20:55 > To: Joonas Lahtinen <[email protected]> > Cc: Surendrakumar Upadhyay, TejaskumarX > <[email protected]>; Jesse Barnes > <[email protected]>; Daniel Vetter <[email protected]>; Linux PCI <linux- > [email protected]>; Linux Kernel Mailing List <linux- > [email protected]>; X86 ML <[email protected]>; Borislav Petkov > <[email protected]>; De Marchi, Lucas <[email protected]>; Roper, > Matthew D <[email protected]>; Pandey, Hariom > <[email protected]>; Jani Nikula <[email protected]>; Vivi, > Rodrigo <[email protected]>; David Airlie <[email protected]> > 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
