[PATCH v4 04/16] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

[Paz Zcharya]

On Thu, Jan 25, 2024 at 12:27:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> On MTL accessing stolen memory via the BARs is somehow borked,
> and it can hang the machine. As a workaround let's bypass the
> BARs and just go straight to DSMBASE/GSMBASE instead.
> 
> Note that on every other platform this itself would hang the
> machine, but on MTL the system firmware is expected to relax
> the access permission guarding stolen memory to enable this
> workaround, and thus direct CPU accesses should be fine.
> 
> The raw stolen memory areas won't be passed to VMs so we'll
> need to risk using the BAR there for the initial setup. Once
> command submission is up we should switch to MI_UPDATE_GTT
> which at least shouldn't hang the whole machine.
> 
> v2: Don't use direct GSM/DSM access on guests
>     Add w/a number
> v3: Check register 0x138914 to see if pcode did its job
>     Add some debug prints
> 
> Cc: Paz Zcharya <pazz at chromium.org>
> Cc: Nirmoy Das <nirmoy.das at intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Reviewed-by: Andrzej Hajda <andrzej.hajda at intel.com>
> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada at intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

Hi Ville,

Thank you so much for this incredible series.
It solves the issue regarding MTL initial plane readout
that Andrzej Hajda and I worked on in
https://patchwork.freedesktop.org/patch/570811/?series=127130&rev=2
In addition, it solved the issue with the new GOP.

I tested it on two different devices with Meteor Lake and it worked perfectly:
no i915 errors, no flickers or observable issues.

Tested-by: Paz Zcharya <pazz at chromium.org>