Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: NbIDQHrMeHpwnnbKeXHwG4/gYzQu6pRG4pFL2EwFXBNGLReWmFjjYxqb7FzzDWhqvv7jhyggRe
 LUmsD0g04c3Q==
IronPort-SDR: LYM7I8+BojnjDsLO4N0coxQXHm/tmeSw9FJIrCIPDHcRbFJkxjZbCTPy/ZJ2pgQ8LZZV5pTSCo
 QW86oRPRFZww==
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
Thread-Topic: [PATCH] x86/gpu: add JSL stolen memory support
Thread-Index: AQHWstDzxN2Pwg+4lUqs/o8gwa6wpqm5S1QAgABL34CAAUSNAIATRwMAgABjNQCAABWMgIAArfUAgACitgCAAC1YAIAQi95ggABnAACAAmNxkIAA/FuAgADPwoCAAG9wAIAADA0w
Date:   Thu, 3 Dec 2020 16:09:50 +0000
Message-ID: <SN6PR11MB34212EA0A59FB5827D3D4C9DDFF20@SN6PR11MB3421.namprd11.prod.outlook.com>
References: <160698518967.3553.11319067086667823352@jlahtine-mobl.ger.corp.intel.com>
 <20201203152520.GA1554214@bjorn-Precision-5520>
In-Reply-To: <20201203152520.GA1554214@bjorn-Precision-5520>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e7a6f7be-ec02-4a84-bb1f-08d897a5dd09
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 16:09:50.5336
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rscKhzyS/ZDaX9ZfzD7oyNjjXQusua5DDJQSkyvSsq+6qMR9fXJvxfGY88rZajFvOhONgks0UHm+1sk2n+TXuE5qAST+9Jx0yeAtjQlXjFToCOSo0kszTCI3pDBI2o4Wq1vvFN4+hcVW0UfPR3W6UQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2573
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Okay then I will wait for someone to respond with "Reviewed-by". So this ca=
n 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>; Viv=
i,
> Rodrigo <rodrigo.vivi@intel.com>; David Airlie <airlied@linux.ie>
> Subject: Re: [PATCH] x86/gpu: add JSL stolen memory support
>=20
> 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?
>=20
> Like I said, I'm not objecting if somebody else wants to apply this.
>=20
> 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.
>=20
> Bjorn