diff options
author | Matt Roper <matthew.d.roper@intel.com> | 2022-11-28 15:30:12 -0800 |
---|---|---|
committer | Matt Roper <matthew.d.roper@intel.com> | 2022-11-30 09:06:34 -0800 |
commit | 4186e2185b4ffc9ce652566d4a4f249484841ff4 (patch) | |
tree | f6cbbfcb2a3ac2ed43f744ad88cf826e8db7d0e5 /drivers/edac | |
parent | 8d9f7d25d50ba55f6b3463d0b8085f62efc39ec4 (diff) |
drm/i915/gt: Add dedicated MCR lock
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). Let's create a dedicated MCR lock to protect the
steering control register over this critical section and stop relying on
the high-traffic uncore->lock.
For now the new lock is a software lock. However some platforms (MTL
and beyond) have a hardware-provided locking mechanism that can be used
to serialize not only software accesses, but also hardware/firmware
accesses as well; support for that hardware level lock will be added in
a future patch.
v2:
- Use irqsave/irqrestore spinlock calls; platforms using execlist
submission rather than GuC submission can perform MCR accesses in
interrupt context because reset -> errordump happens in a tasklet.
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221128233014.4000136-4-matthew.d.roper@intel.com
Diffstat (limited to 'drivers/edac')
0 files changed, 0 insertions, 0 deletions