From 052df73b9e90305487ad9349d0fc8b59ddb6007b Mon Sep 17 00:00:00 2001 From: Rodrigo Vivi Date: Wed, 26 Apr 2023 09:09:40 -0400 Subject: [PATCH] drm/xe: Update comment on why d3cold is still blocked. MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 Cc: Thomas Hellström Cc: Riana Tauro Signed-off-by: Rodrigo Vivi Reviewed-by: Matthew Auld --- drivers/gpu/drm/xe/xe_pci.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c index 5f750edce5427..c1f2f63548d3d 100644 --- a/drivers/gpu/drm/xe/xe_pci.c +++ b/drivers/gpu/drm/xe/xe_pci.c @@ -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; -- 2.30.2