From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: sujaritha.sundaresan@intel.com, intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v5 5/5] drm/xe/pm: Init pcode and restore vram on power lost
Date: Thu, 13 Jul 2023 16:41:26 -0400 [thread overview]
Message-ID: <ZLBhdvHV+JHIKYKy@intel.com> (raw)
In-Reply-To: <20230713143121.3901357-6-anshuman.gupta@intel.com>
On Thu, Jul 13, 2023 at 08:01:21PM +0530, Anshuman Gupta wrote:
> Don't init pcode and restore VRAM objects in vain.
> We can rely on primary GT GUC_STATUS to detect whether
> card has really lost power even when d3cold is allowed by xe.
> Adding d3cold.lost_power flag to avoid pcode init and vram
> restoration.
> Also cleaning up the TODO code comment.
>
> v2:
> - %s/xe_guc_has_lost_power()/xe_guc_in_reset().
> - Used existing gt instead of new variable. [Rodrigo]
> - Added kenrel-doc function comment. [Rodrigo]
> - xe_guc_in_reset() return true if failed to get fw.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
> drivers/gpu/drm/xe/xe_device_types.h | 3 +++
> drivers/gpu/drm/xe/xe_guc.c | 27 +++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_guc.h | 1 +
> drivers/gpu/drm/xe/xe_pci.c | 2 --
> drivers/gpu/drm/xe/xe_pm.c | 13 +++++++++++--
> 5 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
> index f2a6998e8873..89ac2bf482eb 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -355,6 +355,9 @@ struct xe_device {
> /** @allowed: Indicates if d3cold is a valid device state */
> bool allowed;
>
> + /** @power_lost: Indicates if card has really lost power. */
> + bool power_lost;
> +
> /**
> * @vram_threshold:
> *
> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index 8245bbc58770..d6ad1bb85a0e 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -844,3 +844,30 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)
> xe_guc_ct_print(&guc->ct, p, false);
> xe_guc_submit_print(guc, p);
> }
> +
> +/**
> + * xe_guc_in_reset() - Detect if GuC MIA is in reset.
> + * @guc: The GuC object
> + *
> + * This function detects runtime resume from d3cold by leveraging
> + * GUC_STATUS, GUC doesn't get reset during d3hot,
> + * it strictly to be called from RPM resume handler.
> + *
> + * Return: true if failed to get forcewake or GuC MIA is in Reset,
> + * otherwise false.
> + */
> +bool xe_guc_in_reset(struct xe_guc *guc)
> +{
> + struct xe_gt *gt = guc_to_gt(guc);
> + u32 status;
> + int err;
> +
> + err = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
> + if (err)
> + return true;
> +
> + status = xe_mmio_read32(gt, GUC_STATUS);
> + xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
> +
> + return status & GS_MIA_IN_RESET;
> +}
> diff --git a/drivers/gpu/drm/xe/xe_guc.h b/drivers/gpu/drm/xe/xe_guc.h
> index 74a74051f354..f64f22e97169 100644
> --- a/drivers/gpu/drm/xe/xe_guc.h
> +++ b/drivers/gpu/drm/xe/xe_guc.h
> @@ -35,6 +35,7 @@ void xe_guc_reset_wait(struct xe_guc *guc);
> void xe_guc_stop_prepare(struct xe_guc *guc);
> int xe_guc_stop(struct xe_guc *guc);
> int xe_guc_start(struct xe_guc *guc);
> +bool xe_guc_in_reset(struct xe_guc *guc);
>
> static inline u16 xe_engine_class_to_guc_class(enum xe_engine_class class)
> {
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 871868301838..7bb5330ab2db 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -846,8 +846,6 @@ static int xe_pci_runtime_idle(struct device *dev)
> * 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. at resume, detect if we really lost power and avoid memory
> - * restoration if we were only up to d3cold
> */
> xe->d3cold.allowed = false;
> }
> diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> index c732317b55cb..9a934674d470 100644
> --- a/drivers/gpu/drm/xe/xe_pm.c
> +++ b/drivers/gpu/drm/xe/xe_pm.c
> @@ -17,6 +17,7 @@
> #include "xe_display.h"
> #include "xe_ggtt.h"
> #include "xe_gt.h"
> +#include "xe_guc.h"
> #include "xe_irq.h"
> #include "xe_pcode.h"
>
> @@ -197,7 +198,15 @@ int xe_pm_runtime_resume(struct xe_device *xe)
> u8 id;
> int err;
>
> - if (xe->d3cold.allowed) {
> + /*
> + * It can be possible that xe has allowed d3cold but other pcie devices
> + * in gfx card soc would have blocked d3cold, therefore card has not
> + * really lost power. Detecting primary Gt power is sufficient.
> + */
> + gt = xe_device_get_gt(xe, 0);
> + xe->d3cold.power_lost = xe_guc_in_reset(>->uc.guc);
> +
> + if (xe->d3cold.allowed && xe->d3cold.power_lost) {
> for_each_gt(gt, xe, id) {
> err = xe_pcode_init(gt);
> if (err)
> @@ -218,7 +227,7 @@ int xe_pm_runtime_resume(struct xe_device *xe)
> for_each_gt(gt, xe, id)
> xe_gt_resume(gt);
>
> - if (xe->d3cold.allowed) {
> + if (xe->d3cold.allowed && xe->d3cold.power_lost) {
> err = xe_bo_restore_user(xe);
> if (err)
> return err;
> --
> 2.38.0
>
next prev parent reply other threads:[~2023-07-13 20:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 14:31 [Intel-xe] [PATCH v5 0/5] D3Cold Policy Anshuman Gupta
2023-07-13 14:31 ` [Intel-xe] [PATCH v5 1/5] drm/xe/pm: Add pci d3cold_capable support Anshuman Gupta
2023-07-13 14:31 ` [Intel-xe] [PATCH v5 2/5] drm/xe/pm: Refactor xe_pm_runtime_init Anshuman Gupta
2023-07-13 14:31 ` [Intel-xe] [PATCH v5 3/5] drm/xe/pm: Add vram_d3cold_threshold Sysfs Anshuman Gupta
2023-07-14 13:39 ` Rodrigo Vivi
2023-07-13 14:31 ` [Intel-xe] [PATCH v5 4/5] xe/drm/pm: Toggle d3cold_allowed using vram_usages Anshuman Gupta
2023-07-14 11:49 ` Nilawar, Badal
2023-07-14 12:02 ` Gupta, Anshuman
2023-07-14 12:20 ` Gupta, Anshuman
2023-07-13 14:31 ` [Intel-xe] [PATCH v5 5/5] drm/xe/pm: Init pcode and restore vram on power lost Anshuman Gupta
2023-07-13 20:41 ` Rodrigo Vivi [this message]
2023-07-14 11:06 ` Riana Tauro
2023-07-17 8:49 ` [Intel-xe] ✓ CI.Patch_applied: success for D3Cold Policy (rev6) Patchwork
2023-07-17 8:49 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-07-17 8:51 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-07-17 8:54 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-07-17 8:55 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-07-17 8:56 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-07-18 8:07 ` [Intel-xe] ✓ CI.Patch_applied: success for D3Cold Policy (rev7) Patchwork
2023-07-18 8:07 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-07-18 8:08 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-07-18 8:12 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-07-18 8:13 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-07-18 8:14 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-07-18 8:48 ` [Intel-xe] ○ CI.BAT: info " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZLBhdvHV+JHIKYKy@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=sujaritha.sundaresan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.