iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
This commit is contained in:
Rodrigo Vivi 2023-04-26 09:09:40 -04:00
parent a121594006
commit 052df73b9e
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
drivers/gpu/drm/xe/xe_pci.c
View File

@ -755,10 +755,15 @@ static int xe_pci_runtime_idle(struct device *dev)
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))
* however the change to the buddy allocator broke the
* xe_bo_restore_kernel when the pci device is disabled
* but maybe include some other conditions. So, before
* 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;