* [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing.
@ 2023-07-20 21:03 Rodrigo Vivi
2023-07-20 21:03 ` [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together Rodrigo Vivi
` (4 more replies)
0 siblings, 5 replies; 13+ messages in thread
From: Rodrigo Vivi @ 2023-07-20 21:03 UTC (permalink / raw)
To: intel-gfx; +Cc: Rodrigo Vivi
First of all it was strange to see:
if (allowed) {
...
} else {
D3COLD_ENABLE
}
But besides this misalignment, let's also use the pci
d3cold_allowed useful to us and know that we are not really
allowing d3cold.
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
---
drivers/gpu/drm/xe/xe_pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 78df43c20cd2..0c4051f4f746 100644
--- a/drivers/gpu/drm/xe/xe_pci.c
+++ b/drivers/gpu/drm/xe/xe_pci.c
@@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device *dev)
pci_save_state(pdev);
if (xe->d3cold.allowed) {
+ d3cold_toggle(pdev, D3COLD_ENABLE);
pci_disable_device(pdev);
pci_ignore_hotplug(pdev);
pci_set_power_state(pdev, PCI_D3cold);
@@ -823,8 +824,6 @@ static int xe_pci_runtime_resume(struct device *dev)
return err;
pci_set_master(pdev);
- } else {
- d3cold_toggle(pdev, D3COLD_ENABLE);
}
return xe_pm_runtime_resume(xe);
--
2.41.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together. 2023-07-20 21:03 [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Rodrigo Vivi @ 2023-07-20 21:03 ` Rodrigo Vivi 2023-07-21 7:42 ` Gupta, Anshuman 2023-07-20 21:03 ` [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision Rodrigo Vivi ` (3 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Rodrigo Vivi @ 2023-07-20 21:03 UTC (permalink / raw) To: intel-gfx; +Cc: Rodrigo Vivi And let's use the VRAM threshold to keep d3cold temporarily disabled. With this we have the ability to run D3Cold experiments just by touching the vram_d3cold_threshold sysfs entry. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> --- drivers/gpu/drm/xe/xe_pci.c | 15 +-------------- drivers/gpu/drm/xe/xe_pm.c | 5 +++++ drivers/gpu/drm/xe/xe_pm.h | 7 ++++++- 3 files changed, 12 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c index 0c4051f4f746..06759afb4224 100644 --- a/drivers/gpu/drm/xe/xe_pci.c +++ b/drivers/gpu/drm/xe/xe_pci.c @@ -834,20 +834,7 @@ static int xe_pci_runtime_idle(struct device *dev) struct pci_dev *pdev = to_pci_dev(dev); struct xe_device *xe = pdev_to_xe_device(pdev); - if (!xe->d3cold.capable) { - xe->d3cold.allowed = false; - } else { - xe_pm_d3cold_allowed_toggle(xe); - - /* - * TODO: d3cold should be allowed (true) if - * (IS_DGFX(xe) && !xe_device_mem_access_ongoing(xe)) - * 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 - */ - xe->d3cold.allowed = false; - } + xe_pm_d3cold_allowed_toggle(xe); return 0; } diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c index 17a69b7af155..a6459df2599e 100644 --- a/drivers/gpu/drm/xe/xe_pm.c +++ b/drivers/gpu/drm/xe/xe_pm.c @@ -326,6 +326,11 @@ void xe_pm_d3cold_allowed_toggle(struct xe_device *xe) u64 vram_used; int i; + if (!xe->d3cold.capable) { + xe->d3cold.allowed = false; + return; + } + for (i = XE_PL_VRAM0; i <= XE_PL_VRAM1; ++i) { man = ttm_manager_type(&xe->ttm, i); if (man) { diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h index 08a633ce5145..6b9031f7af24 100644 --- a/drivers/gpu/drm/xe/xe_pm.h +++ b/drivers/gpu/drm/xe/xe_pm.h @@ -8,7 +8,12 @@ #include <linux/pm_runtime.h> -#define DEFAULT_VRAM_THRESHOLD 300 /* in MB */ +/* + * TODO: Threshold = 0 will block D3Cold. + * Before we can move this to a higher value (like 300), we need to: + * 1. rewrite the VRAM save / restore to avoid buffer object locks + */ +#define DEFAULT_VRAM_THRESHOLD 0 /* in MB */ struct xe_device; -- 2.41.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together. 2023-07-20 21:03 ` [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together Rodrigo Vivi @ 2023-07-21 7:42 ` Gupta, Anshuman 0 siblings, 0 replies; 13+ messages in thread From: Gupta, Anshuman @ 2023-07-21 7:42 UTC (permalink / raw) To: Vivi, Rodrigo, intel-gfx@lists.freedesktop.org > -----Original Message----- > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > Sent: Friday, July 21, 2023 2:34 AM > To: intel-gfx@lists.freedesktop.org > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > <anshuman.gupta@intel.com> > Subject: [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together. > > And let's use the VRAM threshold to keep d3cold temporarily disabled. > > With this we have the ability to run D3Cold experiments just by touching the > vram_d3cold_threshold sysfs entry. > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> LGTM, Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> > --- > drivers/gpu/drm/xe/xe_pci.c | 15 +-------------- > drivers/gpu/drm/xe/xe_pm.c | 5 +++++ drivers/gpu/drm/xe/xe_pm.h | 7 > ++++++- > 3 files changed, 12 insertions(+), 15 deletions(-) > > diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c > index 0c4051f4f746..06759afb4224 100644 > --- a/drivers/gpu/drm/xe/xe_pci.c > +++ b/drivers/gpu/drm/xe/xe_pci.c > @@ -834,20 +834,7 @@ static int xe_pci_runtime_idle(struct device *dev) > struct pci_dev *pdev = to_pci_dev(dev); > struct xe_device *xe = pdev_to_xe_device(pdev); > > - if (!xe->d3cold.capable) { > - xe->d3cold.allowed = false; > - } else { > - xe_pm_d3cold_allowed_toggle(xe); > - > - /* > - * TODO: d3cold should be allowed (true) if > - * (IS_DGFX(xe) && !xe_device_mem_access_ongoing(xe)) > - * 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 > - */ > - xe->d3cold.allowed = false; > - } > + xe_pm_d3cold_allowed_toggle(xe); > > return 0; > } > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c > index 17a69b7af155..a6459df2599e 100644 > --- a/drivers/gpu/drm/xe/xe_pm.c > +++ b/drivers/gpu/drm/xe/xe_pm.c > @@ -326,6 +326,11 @@ void xe_pm_d3cold_allowed_toggle(struct > xe_device *xe) > u64 vram_used; > int i; > > + if (!xe->d3cold.capable) { > + xe->d3cold.allowed = false; > + return; > + } > + > for (i = XE_PL_VRAM0; i <= XE_PL_VRAM1; ++i) { > man = ttm_manager_type(&xe->ttm, i); > if (man) { > diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h > index 08a633ce5145..6b9031f7af24 100644 > --- a/drivers/gpu/drm/xe/xe_pm.h > +++ b/drivers/gpu/drm/xe/xe_pm.h > @@ -8,7 +8,12 @@ > > #include <linux/pm_runtime.h> > > -#define DEFAULT_VRAM_THRESHOLD 300 /* in MB */ > +/* > + * TODO: Threshold = 0 will block D3Cold. > + * Before we can move this to a higher value (like 300), we need to: > + * 1. rewrite the VRAM save / restore to avoid buffer object locks > + */ > +#define DEFAULT_VRAM_THRESHOLD 0 /* in MB */ > > struct xe_device; > > -- > 2.41.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision. 2023-07-20 21:03 [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Rodrigo Vivi 2023-07-20 21:03 ` [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together Rodrigo Vivi @ 2023-07-20 21:03 ` Rodrigo Vivi 2023-07-21 6:00 ` Gupta, Anshuman 2023-07-20 21:03 ` [Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place Rodrigo Vivi ` (2 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Rodrigo Vivi @ 2023-07-20 21:03 UTC (permalink / raw) To: intel-gfx; +Cc: Rodrigo Vivi According to Documentation/power/runtime_pm.txt: int pm_runtime_put(struct device *dev); - decrement the device's usage counter; if the result is 0 then run pm_request_idle(dev) and return its result int pm_runtime_put_autosuspend(struct device *dev); - decrement the device's usage counter; if the result is 0 then run pm_request_autosuspend(dev) and return its result We need to ensure that the idle function is called before suspending so we take the right d3cold.allowed decision and respect the values set on vram_d3cold_threshold sysfs. So we need pm_runtime_put() instead of pm_runtime_put_autosuspend(). Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> --- drivers/gpu/drm/xe/xe_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c index a6459df2599e..73bcb76c2d42 100644 --- a/drivers/gpu/drm/xe/xe_pm.c +++ b/drivers/gpu/drm/xe/xe_pm.c @@ -144,7 +144,7 @@ static void xe_pm_runtime_init(struct xe_device *xe) pm_runtime_set_active(dev); pm_runtime_allow(dev); pm_runtime_mark_last_busy(dev); - pm_runtime_put_autosuspend(dev); + pm_runtime_put(dev); } void xe_pm_init(struct xe_device *xe) @@ -273,7 +273,7 @@ int xe_pm_runtime_get(struct xe_device *xe) int xe_pm_runtime_put(struct xe_device *xe) { pm_runtime_mark_last_busy(xe->drm.dev); - return pm_runtime_put_autosuspend(xe->drm.dev); + return pm_runtime_put(xe->drm.dev); } int xe_pm_runtime_get_if_active(struct xe_device *xe) -- 2.41.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision. 2023-07-20 21:03 ` [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision Rodrigo Vivi @ 2023-07-21 6:00 ` Gupta, Anshuman 2023-07-21 19:07 ` Rodrigo Vivi 0 siblings, 1 reply; 13+ messages in thread From: Gupta, Anshuman @ 2023-07-21 6:00 UTC (permalink / raw) To: Vivi, Rodrigo, intel-gfx@lists.freedesktop.org > -----Original Message----- > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > Sent: Friday, July 21, 2023 2:34 AM > To: intel-gfx@lists.freedesktop.org > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > <anshuman.gupta@intel.com> > Subject: [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed > decision. > > According to Documentation/power/runtime_pm.txt: I tried to fix runtime idle https://patchwork.freedesktop.org/patch/543024/?series=119467&rev=1 But forgot to CC to you. Anyway some comment below, > > int pm_runtime_put(struct device *dev); > - decrement the device's usage counter; if the result is 0 then run > pm_request_idle(dev) and return its result > > int pm_runtime_put_autosuspend(struct device *dev); > - decrement the device's usage counter; if the result is 0 then run > pm_request_autosuspend(dev) and return its result > > We need to ensure that the idle function is called before suspending so we > take the right d3cold.allowed decision and respect the values set on > vram_d3cold_threshold sysfs. So we need pm_runtime_put() instead of > pm_runtime_put_autosuspend(). > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > --- > drivers/gpu/drm/xe/xe_pm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c > index a6459df2599e..73bcb76c2d42 100644 > --- a/drivers/gpu/drm/xe/xe_pm.c > +++ b/drivers/gpu/drm/xe/xe_pm.c > @@ -144,7 +144,7 @@ static void xe_pm_runtime_init(struct xe_device *xe) > pm_runtime_set_active(dev); > pm_runtime_allow(dev); > pm_runtime_mark_last_busy(dev); I have not thought of using last_busy() here in _put(). If we mark last_busy during _put then pm core auto-suspend timer will start ticking from _put(). Theoretically that can lead to idle() and runtime_suspend() call to race with each other ? [1] [1] Documentation/power/runtime_pm.txt (1) The callbacks are mutually exclusive (e.g. it is forbidden to execute ->runtime_suspend() in parallel with ->runtime_resume() or with another instance of ->runtime_suspend() for the same device) with the exception that ->runtime_suspend() or ->runtime_resume() can be executed in parallel with ->runtime_idle() (although ->runtime_idle() will not be started while any of the other callbacks is being executed for the same device). Thanks, Anshuman Gupta. > - pm_runtime_put_autosuspend(dev); > + pm_runtime_put(dev); We need to fix this in intel_runtime_pm_put() compat-i915-headers as well. > } > > void xe_pm_init(struct xe_device *xe) > @@ -273,7 +273,7 @@ int xe_pm_runtime_get(struct xe_device *xe) int > xe_pm_runtime_put(struct xe_device *xe) { > pm_runtime_mark_last_busy(xe->drm.dev); > - return pm_runtime_put_autosuspend(xe->drm.dev); > + return pm_runtime_put(xe->drm.dev); > } > > int xe_pm_runtime_get_if_active(struct xe_device *xe) > -- > 2.41.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision. 2023-07-21 6:00 ` Gupta, Anshuman @ 2023-07-21 19:07 ` Rodrigo Vivi 0 siblings, 0 replies; 13+ messages in thread From: Rodrigo Vivi @ 2023-07-21 19:07 UTC (permalink / raw) To: Gupta, Anshuman; +Cc: intel-gfx@lists.freedesktop.org On Fri, Jul 21, 2023 at 02:00:52AM -0400, Gupta, Anshuman wrote: > > > > -----Original Message----- > > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > > Sent: Friday, July 21, 2023 2:34 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > > <anshuman.gupta@intel.com> > > Subject: [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed > > decision. > > > > According to Documentation/power/runtime_pm.txt: > I tried to fix runtime idle https://patchwork.freedesktop.org/patch/543024/?series=119467&rev=1 > But forgot to CC to you. I'm really sorry for having missed that. 2 comments on your version: 1. it forgets to remove the autosuspend from the init, so on the very first entry at driver load it may miss the idle call. 2. I don't like the way other drivers are doing with idle. The rpm infra expects 0 return to then call the suspend. I really don't understand because I few drivers decided to workaround that and return 1 and call the autosuspend themselves from within the idle. > Anyway some comment below, > > > > > int pm_runtime_put(struct device *dev); > > - decrement the device's usage counter; if the result is 0 then run > > pm_request_idle(dev) and return its result > > > > int pm_runtime_put_autosuspend(struct device *dev); > > - decrement the device's usage counter; if the result is 0 then run > > pm_request_autosuspend(dev) and return its result > > > > We need to ensure that the idle function is called before suspending so we > > take the right d3cold.allowed decision and respect the values set on > > vram_d3cold_threshold sysfs. So we need pm_runtime_put() instead of > > pm_runtime_put_autosuspend(). > > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > --- > > drivers/gpu/drm/xe/xe_pm.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c > > index a6459df2599e..73bcb76c2d42 100644 > > --- a/drivers/gpu/drm/xe/xe_pm.c > > +++ b/drivers/gpu/drm/xe/xe_pm.c > > @@ -144,7 +144,7 @@ static void xe_pm_runtime_init(struct xe_device *xe) > > pm_runtime_set_active(dev); > > pm_runtime_allow(dev); > > pm_runtime_mark_last_busy(dev); > I have not thought of using last_busy() here in _put(). > If we mark last_busy during _put then pm core auto-suspend timer will start ticking from _put(). > Theoretically that can lead to idle() and runtime_suspend() call to race with each other ? [1] that shouldn't happen if you are using the rpm as designed and returning 0 from idle instead of 1 and autosuspend. > [1] Documentation/power/runtime_pm.txt > (1) The callbacks are mutually exclusive (e.g. it is forbidden to execute > ->runtime_suspend() in parallel with ->runtime_resume() or with another > instance of ->runtime_suspend() for the same device) with the exception that > ->runtime_suspend() or ->runtime_resume() can be executed in parallel with > ->runtime_idle() (although ->runtime_idle() will not be started while any > of the other callbacks is being executed for the same device). > Thanks, > Anshuman Gupta. > > - pm_runtime_put_autosuspend(dev); > > + pm_runtime_put(dev); > We need to fix this in intel_runtime_pm_put() compat-i915-headers as well. I can't see that... I see the compat headers calling the xe_ variants so we should be covered from here. what exactly am I missing? > > } > > > > void xe_pm_init(struct xe_device *xe) > > @@ -273,7 +273,7 @@ int xe_pm_runtime_get(struct xe_device *xe) int > > xe_pm_runtime_put(struct xe_device *xe) { > > pm_runtime_mark_last_busy(xe->drm.dev); > > - return pm_runtime_put_autosuspend(xe->drm.dev); > > + return pm_runtime_put(xe->drm.dev); > > } > > > > int xe_pm_runtime_get_if_active(struct xe_device *xe) > > -- > > 2.41.0 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place. 2023-07-20 21:03 [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Rodrigo Vivi 2023-07-20 21:03 ` [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together Rodrigo Vivi 2023-07-20 21:03 ` [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision Rodrigo Vivi @ 2023-07-20 21:03 ` Rodrigo Vivi 2023-07-21 7:27 ` Gupta, Anshuman 2023-07-20 21:13 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Patchwork 2023-07-21 7:39 ` [Intel-gfx] [PATCH 1/4] " Gupta, Anshuman 4 siblings, 1 reply; 13+ messages in thread From: Rodrigo Vivi @ 2023-07-20 21:03 UTC (permalink / raw) To: intel-gfx; +Cc: Rodrigo Vivi We cannot allow runtime pm suspend after we configured the d3cold capable and threshold. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> --- drivers/gpu/drm/xe/xe_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c index 73bcb76c2d42..366ee446af38 100644 --- a/drivers/gpu/drm/xe/xe_pm.c +++ b/drivers/gpu/drm/xe/xe_pm.c @@ -152,10 +152,12 @@ void xe_pm_init(struct xe_device *xe) struct pci_dev *pdev = to_pci_dev(xe->drm.dev); drmm_mutex_init(&xe->drm, &xe->d3cold.lock); - xe_pm_runtime_init(xe); + xe->d3cold.capable = xe_pm_pci_d3cold_capable(pdev); xe_device_sysfs_init(xe); xe_pm_set_vram_threshold(xe, DEFAULT_VRAM_THRESHOLD); + + xe_pm_runtime_init(xe); } void xe_pm_runtime_fini(struct xe_device *xe) -- 2.41.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place. 2023-07-20 21:03 ` [Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place Rodrigo Vivi @ 2023-07-21 7:27 ` Gupta, Anshuman 0 siblings, 0 replies; 13+ messages in thread From: Gupta, Anshuman @ 2023-07-21 7:27 UTC (permalink / raw) To: Vivi, Rodrigo, intel-gfx@lists.freedesktop.org > -----Original Message----- > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > Sent: Friday, July 21, 2023 2:34 AM > To: intel-gfx@lists.freedesktop.org > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > <anshuman.gupta@intel.com> > Subject: [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in > place. > > We cannot allow runtime pm suspend after we configured the d3cold > capable and threshold. > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > --- > drivers/gpu/drm/xe/xe_pm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c > index 73bcb76c2d42..366ee446af38 100644 > --- a/drivers/gpu/drm/xe/xe_pm.c > +++ b/drivers/gpu/drm/xe/xe_pm.c > @@ -152,10 +152,12 @@ void xe_pm_init(struct xe_device *xe) > struct pci_dev *pdev = to_pci_dev(xe->drm.dev); > > drmm_mutex_init(&xe->drm, &xe->d3cold.lock); > - xe_pm_runtime_init(xe); > + > xe->d3cold.capable = xe_pm_pci_d3cold_capable(pdev); > xe_device_sysfs_init(xe); > xe_pm_set_vram_threshold(xe, DEFAULT_VRAM_THRESHOLD); > + > + xe_pm_runtime_init(xe); LGTM. Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> > } > > void xe_pm_runtime_fini(struct xe_device *xe) > -- > 2.41.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing. 2023-07-20 21:03 [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Rodrigo Vivi ` (2 preceding siblings ...) 2023-07-20 21:03 ` [Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place Rodrigo Vivi @ 2023-07-20 21:13 ` Patchwork 2023-07-21 7:39 ` [Intel-gfx] [PATCH 1/4] " Gupta, Anshuman 4 siblings, 0 replies; 13+ messages in thread From: Patchwork @ 2023-07-20 21:13 UTC (permalink / raw) To: Rodrigo Vivi; +Cc: intel-gfx == Series Details == Series: series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing. URL : https://patchwork.freedesktop.org/series/121071/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/121071/revisions/1/mbox/ not applied Applying: drm/xe: Only set PCI d3cold_allowed when we are really allowing. error: sha1 information is lacking or useless (drivers/gpu/drm/xe/xe_pci.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/xe: Only set PCI d3cold_allowed when we are really allowing. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing. 2023-07-20 21:03 [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Rodrigo Vivi ` (3 preceding siblings ...) 2023-07-20 21:13 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Patchwork @ 2023-07-21 7:39 ` Gupta, Anshuman 2023-07-21 19:00 ` Rodrigo Vivi 4 siblings, 1 reply; 13+ messages in thread From: Gupta, Anshuman @ 2023-07-21 7:39 UTC (permalink / raw) To: Vivi, Rodrigo, intel-gfx@lists.freedesktop.org > -----Original Message----- > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > Sent: Friday, July 21, 2023 2:34 AM > To: intel-gfx@lists.freedesktop.org > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > <anshuman.gupta@intel.com> > Subject: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > really allowing. > > First of all it was strange to see: > if (allowed) { > ... > } else { > D3COLD_ENABLE > } > > But besides this misalignment, let's also use the pci d3cold_allowed useful to > us and know that we are not really allowing d3cold. > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > --- > drivers/gpu/drm/xe/xe_pci.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c > index 78df43c20cd2..0c4051f4f746 100644 > --- a/drivers/gpu/drm/xe/xe_pci.c > +++ b/drivers/gpu/drm/xe/xe_pci.c > @@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device > *dev) > pci_save_state(pdev); > > if (xe->d3cold.allowed) { > + d3cold_toggle(pdev, D3COLD_ENABLE); > pci_disable_device(pdev); > pci_ignore_hotplug(pdev); > pci_set_power_state(pdev, PCI_D3cold); @@ -823,8 +824,6 > @@ static int xe_pci_runtime_resume(struct device *dev) > return err; > > pci_set_master(pdev); > - } else { > - d3cold_toggle(pdev, D3COLD_ENABLE); > } During s2idle , d3cold may get disabled if won't restore it's state in runtime resume. Thanks, Anshuman Gupta. > > return xe_pm_runtime_resume(xe); > -- > 2.41.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing. 2023-07-21 7:39 ` [Intel-gfx] [PATCH 1/4] " Gupta, Anshuman @ 2023-07-21 19:00 ` Rodrigo Vivi 2023-07-25 5:08 ` Gupta, Anshuman 0 siblings, 1 reply; 13+ messages in thread From: Rodrigo Vivi @ 2023-07-21 19:00 UTC (permalink / raw) To: Gupta, Anshuman; +Cc: intel-gfx@lists.freedesktop.org On Fri, Jul 21, 2023 at 03:39:35AM -0400, Gupta, Anshuman wrote: > > > > -----Original Message----- > > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > > Sent: Friday, July 21, 2023 2:34 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > > <anshuman.gupta@intel.com> > > Subject: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > > really allowing. > > > > First of all it was strange to see: > > if (allowed) { > > ... > > } else { > > D3COLD_ENABLE > > } > > > > But besides this misalignment, let's also use the pci d3cold_allowed useful to > > us and know that we are not really allowing d3cold. > > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > --- > > drivers/gpu/drm/xe/xe_pci.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c > > index 78df43c20cd2..0c4051f4f746 100644 > > --- a/drivers/gpu/drm/xe/xe_pci.c > > +++ b/drivers/gpu/drm/xe/xe_pci.c > > @@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device > > *dev) > > pci_save_state(pdev); > > > > if (xe->d3cold.allowed) { > > + d3cold_toggle(pdev, D3COLD_ENABLE); > > pci_disable_device(pdev); > > pci_ignore_hotplug(pdev); > > pci_set_power_state(pdev, PCI_D3cold); @@ -823,8 +824,6 > > @@ static int xe_pci_runtime_resume(struct device *dev) > > return err; > > > > pci_set_master(pdev); > > - } else { > > - d3cold_toggle(pdev, D3COLD_ENABLE); > > } > During s2idle , d3cold may get disabled if won't restore it's state in runtime resume. I always forget about that case... please disregard this patch. > Thanks, > Anshuman Gupta. > > > > return xe_pm_runtime_resume(xe); > > -- > > 2.41.0 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing. 2023-07-21 19:00 ` Rodrigo Vivi @ 2023-07-25 5:08 ` Gupta, Anshuman 2023-07-25 21:18 ` Rodrigo Vivi 0 siblings, 1 reply; 13+ messages in thread From: Gupta, Anshuman @ 2023-07-25 5:08 UTC (permalink / raw) To: Vivi, Rodrigo; +Cc: intel-gfx@lists.freedesktop.org > -----Original Message----- > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > Sent: Saturday, July 22, 2023 12:30 AM > To: Gupta, Anshuman <anshuman.gupta@intel.com> > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > really allowing. > > On Fri, Jul 21, 2023 at 03:39:35AM -0400, Gupta, Anshuman wrote: > > > > > > > -----Original Message----- > > > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > Sent: Friday, July 21, 2023 2:34 AM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > > > <anshuman.gupta@intel.com> > > > Subject: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > > > really allowing. > > > > > > First of all it was strange to see: > > > if (allowed) { > > > ... > > > } else { > > > D3COLD_ENABLE > > > } > > > > > > But besides this misalignment, let's also use the pci d3cold_allowed > > > useful to us and know that we are not really allowing d3cold. > > > > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > --- > > > drivers/gpu/drm/xe/xe_pci.c | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/xe/xe_pci.c > > > b/drivers/gpu/drm/xe/xe_pci.c index 78df43c20cd2..0c4051f4f746 > > > 100644 > > > --- a/drivers/gpu/drm/xe/xe_pci.c > > > +++ b/drivers/gpu/drm/xe/xe_pci.c > > > @@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device > > > *dev) > > > pci_save_state(pdev); > > > > > > if (xe->d3cold.allowed) { > > > + d3cold_toggle(pdev, D3COLD_ENABLE); > > > pci_disable_device(pdev); > > > pci_ignore_hotplug(pdev); > > > pci_set_power_state(pdev, PCI_D3cold); @@ -823,8 +824,6 > @@ static > > > int xe_pci_runtime_resume(struct device *dev) > > > return err; > > > > > > pci_set_master(pdev); > > > - } else { > > > - d3cold_toggle(pdev, D3COLD_ENABLE); > > > } > > During s2idle , d3cold may get disabled if won't restore it's state in runtime > resume. > > I always forget about that case... please disregard this patch. I think , we can have this patch. I realized that system wide suspend/resume d3cold need some brainstorming. If device is already in runtime suspend state during system wide suspend, PM core may smartly skip device suspend/resume callback on Xe driver. This wasn't the case on I915 driver as it explicitly disables those smart optimization by dev_pm_set_driver_flags(kdev, DPM_FLAG_NO_DIRECT_COMPLETE). Thanks, Anshuman. Thanks, Anshuman Gupta. > > > Thanks, > > Anshuman Gupta. > > > > > > return xe_pm_runtime_resume(xe); > > > -- > > > 2.41.0 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing. 2023-07-25 5:08 ` Gupta, Anshuman @ 2023-07-25 21:18 ` Rodrigo Vivi 0 siblings, 0 replies; 13+ messages in thread From: Rodrigo Vivi @ 2023-07-25 21:18 UTC (permalink / raw) To: Gupta, Anshuman; +Cc: intel-gfx@lists.freedesktop.org On Tue, Jul 25, 2023 at 01:08:11AM -0400, Gupta, Anshuman wrote: > > > > -----Original Message----- > > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > > Sent: Saturday, July 22, 2023 12:30 AM > > To: Gupta, Anshuman <anshuman.gupta@intel.com> > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > > really allowing. > > > > On Fri, Jul 21, 2023 at 03:39:35AM -0400, Gupta, Anshuman wrote: > > > > > > > > > > -----Original Message----- > > > > From: Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > > Sent: Friday, July 21, 2023 2:34 AM > > > > To: intel-gfx@lists.freedesktop.org > > > > Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>; Gupta, Anshuman > > > > <anshuman.gupta@intel.com> > > > > Subject: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > > > > really allowing. > > > > > > > > First of all it was strange to see: > > > > if (allowed) { > > > > ... > > > > } else { > > > > D3COLD_ENABLE > > > > } > > > > > > > > But besides this misalignment, let's also use the pci d3cold_allowed > > > > useful to us and know that we are not really allowing d3cold. > > > > > > > > Cc: Anshuman Gupta <anshuman.gupta@intel.com> > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > --- > > > > drivers/gpu/drm/xe/xe_pci.c | 3 +-- > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_pci.c > > > > b/drivers/gpu/drm/xe/xe_pci.c index 78df43c20cd2..0c4051f4f746 > > > > 100644 > > > > --- a/drivers/gpu/drm/xe/xe_pci.c > > > > +++ b/drivers/gpu/drm/xe/xe_pci.c > > > > @@ -794,6 +794,7 @@ static int xe_pci_runtime_suspend(struct device > > > > *dev) > > > > pci_save_state(pdev); > > > > > > > > if (xe->d3cold.allowed) { > > > > + d3cold_toggle(pdev, D3COLD_ENABLE); > > > > pci_disable_device(pdev); > > > > pci_ignore_hotplug(pdev); > > > > pci_set_power_state(pdev, PCI_D3cold); @@ -823,8 +824,6 > > @@ static > > > > int xe_pci_runtime_resume(struct device *dev) > > > > return err; > > > > > > > > pci_set_master(pdev); > > > > - } else { > > > > - d3cold_toggle(pdev, D3COLD_ENABLE); > > > > } > > > During s2idle , d3cold may get disabled if won't restore it's state in runtime > > resume. > > > > I always forget about that case... please disregard this patch. > I think , we can have this patch. > I realized that system wide suspend/resume d3cold need some brainstorming. > If device is already in runtime suspend state during system wide suspend, PM core may smartly skip device suspend/resume callback on Xe driver. > This wasn't the case on I915 driver as it explicitly disables those smart optimization by > dev_pm_set_driver_flags(kdev, DPM_FLAG_NO_DIRECT_COMPLETE). so, it looks that we do need this as well anyway. 1. because we might not be in the runtime-d3cold, but on the system suspend we will lose power, hence the eviction/restore needs to happen. 2. because of the hda audio as documented in i915: "becaue the HDA driver may require us to enable the audio power domain during system suspend." then, on device suspend we enable the d3cold and disable again on device resume. > Thanks, > Anshuman. > Thanks, > Anshuman Gupta. > > > > > Thanks, > > > Anshuman Gupta. > > > > > > > > return xe_pm_runtime_resume(xe); > > > > -- > > > > 2.41.0 > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-07-25 21:18 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-07-20 21:03 [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Rodrigo Vivi 2023-07-20 21:03 ` [Intel-gfx] [PATCH 2/4] drm/xe: Move d3cold_allowed decision all together Rodrigo Vivi 2023-07-21 7:42 ` Gupta, Anshuman 2023-07-20 21:03 ` [Intel-gfx] [PATCH 3/4] drm/xe: Fix the runtime_idle call and d3cold.allowed decision Rodrigo Vivi 2023-07-21 6:00 ` Gupta, Anshuman 2023-07-21 19:07 ` Rodrigo Vivi 2023-07-20 21:03 ` [Intel-gfx] [PATCH 4/4] drm/xe: Only init runtime PM after all d3cold config is in place Rodrigo Vivi 2023-07-21 7:27 ` Gupta, Anshuman 2023-07-20 21:13 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing Patchwork 2023-07-21 7:39 ` [Intel-gfx] [PATCH 1/4] " Gupta, Anshuman 2023-07-21 19:00 ` Rodrigo Vivi 2023-07-25 5:08 ` Gupta, Anshuman 2023-07-25 21:18 ` Rodrigo Vivi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox