[PATCH 1/2] drm/xe/pcode: Treat pcode as per-tile rather than per-GT

[Lucas De Marchi]

On Thu, Aug 29, 2024 at 03:06:21PM GMT, Matt Roper wrote:
>There's only one instance of the pcode per tile, and for GT-related
>accesses both the primary and media GT share the same register
>interface.  Since Xe was using per-GT locking, the pcode mutex wasn't
>actually protecting everything that it should since concurrent accesses
>related to a tile's primary GT and media GT were possible.
>
>Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
>Signed-off-by: Matt Roper <matthew.d.roper at intel.com>


Reviewed-by: Lucas De Marchi <lucas.demarchi at intel.com>

>---
>One somewhat worrying design that this highlights is that
>xe_pcode_init_min_freq_table is getting called from each GT's SLPC
>initialization with different frequency values.  But since there's
>really only a single shared pcode interface to the hardware, this
>effectively means the media GT values seem to be clobbering the values
>previously set by the primary GT.  We'll need to look closer at that as
>a followup; this patch doesn't attempt to change that (mis?)behavior.

and with a single pcode interface, would it need to do a min
and max for all GTs rather than simply considering pc->rp{0,n}_freq?

Lucas De Marchi