summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gt/intel_reset.c
diff options
context:
space:
mode:
authorAlan Previn <alan.previn.teres.alexis@intel.com>2022-03-21 09:45:25 -0700
committerLucas De Marchi <lucas.demarchi@intel.com>2022-03-22 10:33:31 -0700
commit247f8071d589333cd0fc559c8802edd13e21e203 (patch)
tree64e47155b5d368f6ddc62eb517cf684676bf1269 /drivers/gpu/drm/i915/gt/intel_reset.c
parentf5718a7265a6f562dc706e0b610f060ded4c3739 (diff)
drm/i915/guc: Pre-allocate output nodes for extraction
In the rare but possible scenario where we are in the midst of multiple GuC error-capture (and engine reset) events and the user also triggers a forced full GT reset or the internal watchdog triggers the same, intel_guc_submission_reset_prepare's call to flush_work(&guc->ct.requests.worker) can cause the G2H message handler to trigger intel_guc_capture_store_snapshot upon receiving new G2H error-capture notifications. This can happen despite the prior call to disable_submission(guc);. However, there's no race-free way for intel_guc_capture_store_snapshot to know that we are in the midst of a reset. That said, we can never dynamically allocate the output nodes in this handler. Thus, we shall pre-allocate a fixed number of empty nodes up front (at the time of ADS registration) that we can consume from or return to an internal cached list of nodes. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321164527.2500062-12-alan.previn.teres.alexis@intel.com
Diffstat (limited to 'drivers/gpu/drm/i915/gt/intel_reset.c')
0 files changed, 0 insertions, 0 deletions