mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 11:18:45 +07:00
c7302f2044
As we need to acquire a mutex to serialise the final intel_wakeref_put, we need to ensure that we are in process context at that time. However, we want to allow operation on the intel_wakeref from inside timer and other hardirq context, which means that need to defer that final put to a workqueue. Inside the final wakeref puts, we are safe to operate in any context, as we are simply marking up the HW and state tracking for the potential sleep. It's only the serialisation with the potential sleeping getting that requires careful wait avoidance. This allows us to retain the immediate processing as before (we only need to sleep over the same races as the current mutex_lock). v2: Add a selftest to ensure we exercise the code while lockdep watches. v3: That test was extremely loud and complained about many things! v4: Not a whale! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111295 References: https://bugs.freedesktop.org/show_bug.cgi?id=111245 References: https://bugs.freedesktop.org/show_bug.cgi?id=111256 Fixes: |
||
|---|---|---|
| .. | ||
| selftests | ||
| i915_gem_busy.c | ||
| i915_gem_clflush.c | ||
| i915_gem_clflush.h | ||
| i915_gem_client_blt.c | ||
| i915_gem_client_blt.h | ||
| i915_gem_context_types.h | ||
| i915_gem_context.c | ||
| i915_gem_context.h | ||
| i915_gem_dmabuf.c | ||
| i915_gem_domain.c | ||
| i915_gem_execbuffer.c | ||
| i915_gem_fence.c | ||
| i915_gem_internal.c | ||
| i915_gem_ioctls.h | ||
| i915_gem_mman.c | ||
| i915_gem_object_blt.c | ||
| i915_gem_object_blt.h | ||
| i915_gem_object_types.h | ||
| i915_gem_object.c | ||
| i915_gem_object.h | ||
| i915_gem_pages.c | ||
| i915_gem_phys.c | ||
| i915_gem_pm.c | ||
| i915_gem_pm.h | ||
| i915_gem_shmem.c | ||
| i915_gem_shrinker.c | ||
| i915_gem_stolen.c | ||
| i915_gem_throttle.c | ||
| i915_gem_tiling.c | ||
| i915_gem_userptr.c | ||
| i915_gem_wait.c | ||
| i915_gemfs.c | ||
| i915_gemfs.h | ||
| Makefile | ||