Commit 052df73b authored by Rodrigo Vivi's avatar Rodrigo Vivi

drm/xe: Update comment on why d3cold is still blocked.

The main issue with buddy allocator was fixed, but then
we ended up on other issues, so we need to step back and rethink
our strategy with D3cold. So, let's update the comment with a
todo list so we don't get tempted in removing it before we are
really ready.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Riana Tauro <riana.tauro@intel.com>
Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
parent a1215940
...@@ -755,10 +755,15 @@ static int xe_pci_runtime_idle(struct device *dev) ...@@ -755,10 +755,15 @@ static int xe_pci_runtime_idle(struct device *dev)
struct xe_device *xe = pdev_to_xe_device(pdev); struct xe_device *xe = pdev_to_xe_device(pdev);
/* /*
* FIXME: d3cold should be allowed (true) if * TODO: d3cold should be allowed (true) if
* (IS_DGFX(xe) && !xe_device_mem_access_ongoing(xe)) * (IS_DGFX(xe) && !xe_device_mem_access_ongoing(xe))
* however the change to the buddy allocator broke the * but maybe include some other conditions. So, before
* xe_bo_restore_kernel when the pci device is disabled * we can re-enable the D3cold, we need to:
* 1. rewrite the VRAM save / restore to avoid buffer object locks
* 2. block D3cold if we have a big amount of device memory in use
* in order to reduce the latency.
* 3. at resume, detect if we really lost power and avoid memory
* restoration if we were only up to d3cold
*/ */
xe->d3cold_allowed = false; xe->d3cold_allowed = false;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment