We've been overloading uncore->lock to protect access to the MCR steering register. That's not really what uncore->lock is intended for, and it would be better if we didn't need to hold such a high-traffic spinlock for the whole sequence of (apply steering, access MCR register, restore steering). Switch to a dedicated MCR lock to protect the steering control register over this critical section and stop relying on the high-traffic uncore->lock. On pre-MTL platforms the dedicated MCR lock is just another software lock, but on MTL and beyond we also utilize the hardware-provided STEER_SEMAPHORE that allows us to synchronize with external hardware and firmware agents. v2: - Use irqsave/irqrestore locking; on platforms that use execlist submission instead of GuC, MCR accesses can happen in interrupt context (tasklet) during reset -> error dump. - Extend timeout for hardware semaphore and CI taint if we ever encounter it (this implies a hardware/firmware problem). (Mika) - Add an extra patch optimizing xehp_setup_private_ppat by holding forcewake & mcr lock over the sequence of register writes. (Bala) Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@xxxxxxxxx> Matt Roper (5): drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg() drm/i915/gt: Pass gt rather than uncore to lowest-level reads/writes drm/i915/gt: Add dedicated MCR lock drm/i915/mtl: Add hardware-level lock for steering drm/i915/mtl: Hold forcewake and MCR lock over PPAT setup drivers/gpu/drm/i915/gt/intel_gt.c | 7 +- drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 129 ++++++++++++++++++-- drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 2 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 8 ++ drivers/gpu/drm/i915/gt/intel_gtt.c | 27 ++-- drivers/gpu/drm/i915/gt/intel_mocs.c | 3 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +- 8 files changed, 162 insertions(+), 27 deletions(-) -- 2.38.1
