aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorGustavo Sousa <gustavo.sousa@intel.com>2024-11-08 09:57:09 -0300
committerMatt Roper <matthew.d.roper@intel.com>2024-11-08 09:53:59 -0800
commitf7b12bf2968ca6a27d879e1781b28eb1036dc5e6 (patch)
treeabff481cb8c110192c99708f6bb59a0ac071b23d /tools/perf/scripts/python/task-analyzer.py
parentdrm/i915/dmc_wl: Use non-sleeping variant of MMIO wait (diff)
downloadlinux-f7b12bf2968ca6a27d879e1781b28eb1036dc5e6.tar.gz
linux-f7b12bf2968ca6a27d879e1781b28eb1036dc5e6.zip
drm/i915/dmc_wl: Check for non-zero refcount in release work
When the DMC wakelock refcount reaches zero, we know that there are no users and that we can do the actual release operation on the hardware, which is queued with a delayed work. The idea of the delayed work is to avoid performing the release if a new lock user appears (i.e. refcount gets incremented) in a very short period of time. Based on the above, the release work should bail out if refcount is non-zero (meaning new lock users appeared in the meantime), but our current code actually does the opposite: it bails when refcount is zero. That means that the wakelock is not released when it should be; and that, when the work is not canceled in time, it ends up being releasing when it should not. Fix that by inverting the condition. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108130218.24125-5-gustavo.sousa@intel.com
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions