From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Chris Wilson" <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH v4 5/5] Revert "drm/i915: Improve on suspend / resume time with VT-d enabled"
Date: Thu, 1 Dec 2022 09:02:23 +0000 [thread overview]
Message-ID: <6d43a21e-6699-e85f-3c5f-3855cbf5342e@linux.intel.com> (raw)
In-Reply-To: <20221130235805.221010-6-andi.shyti@linux.intel.com>
On 30/11/2022 23:58, Andi Shyti wrote:
> This reverts commit 2ef6efa79fecd5e3457b324155d35524d95f2b6b.
>
> Checking the presence if the IRST (Intel Rapid Start Technology)
> through the ACPI to decide whether to rebuild or not the GGTT
> puts us at the mercy of the boot firmware and we need to
> unnecessarily rely on third parties.
>
> Because now we avoid adding scratch pages to the entire GGTT we
> don't need this hack anymore.
>
> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 69 ++++++----------------------
> drivers/gpu/drm/i915/gt/intel_gtt.h | 24 ----------
> drivers/gpu/drm/i915/i915_driver.c | 16 -------
> 3 files changed, 13 insertions(+), 96 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index fa96d925c2596..5896ac44010b0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -27,13 +27,6 @@
> #include "intel_gtt.h"
> #include "gen8_ppgtt.h"
>
> -static inline bool suspend_retains_ptes(struct i915_address_space *vm)
> -{
> - return GRAPHICS_VER(vm->i915) >= 8 &&
> - !HAS_LMEM(vm->i915) &&
> - vm->is_ggtt;
> -}
> -
> static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
> unsigned long color,
> u64 *start,
> @@ -105,23 +98,6 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
> return 0;
> }
>
> -/*
> - * Return the value of the last GGTT pte cast to an u64, if
> - * the system is supposed to retain ptes across resume. 0 otherwise.
> - */
> -static u64 read_last_pte(struct i915_address_space *vm)
> -{
> - struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
> - gen8_pte_t __iomem *ptep;
> -
> - if (!suspend_retains_ptes(vm))
> - return 0;
> -
> - GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
> - ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
> - return readq(ptep);
> -}
> -
> /**
> * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
> * @vm: The VM to suspend the mappings for
> @@ -185,10 +161,7 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
> i915_gem_object_unlock(obj);
> }
>
> - if (!suspend_retains_ptes(vm))
> - vm->clear_range(vm, 0, vm->total);
> - else
> - i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
> + vm->clear_range(vm, 0, vm->total);
>
> vm->skip_pte_rewrite = save_skip_rewrite;
>
> @@ -545,8 +518,6 @@ static int init_ggtt(struct i915_ggtt *ggtt)
> struct drm_mm_node *entry;
> int ret;
>
> - ggtt->pte_lost = true;
> -
> /*
> * GuC requires all resources that we're sharing with it to be placed in
> * non-WOPCM memory. If GuC is not present or not in use we still need a
> @@ -1263,20 +1234,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
> {
> struct i915_vma *vma;
> bool write_domain_objs = false;
> - bool retained_ptes;
>
> drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
>
> - /*
> - * First fill our portion of the GTT with scratch pages if
> - * they were not retained across suspend.
> - */
> - retained_ptes = suspend_retains_ptes(vm) &&
> - !i915_vm_to_ggtt(vm)->pte_lost &&
> - !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte != read_last_pte(vm));
> -
> - if (!retained_ptes)
> - vm->clear_range(vm, 0, vm->total);
> + /* First fill our portion of the GTT with scratch pages */
> + vm->clear_range(vm, 0, vm->total);
>
> /* clflush objects bound into the GGTT and rebind them. */
> list_for_each_entry(vma, &vm->bound_list, vm_link) {
> @@ -1285,16 +1247,16 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
> atomic_read(&vma->flags) & I915_VMA_BIND_MASK;
>
> GEM_BUG_ON(!was_bound);
> - if (!retained_ptes) {
> - /*
> - * Clear the bound flags of the vma resource to allow
> - * ptes to be repopulated.
> - */
> - vma->resource->bound_flags = 0;
> - vma->ops->bind_vma(vm, NULL, vma->resource,
> - obj ? obj->cache_level : 0,
> - was_bound);
> - }
> +
> + /*
> + * Clear the bound flags of the vma resource to allow
> + * ptes to be repopulated.
> + */
> + vma->resource->bound_flags = 0;
> + vma->ops->bind_vma(vm, NULL, vma->resource,
> + obj ? obj->cache_level : 0,
> + was_bound);
> +
> if (obj) { /* only used during resume => exclusive access */
> write_domain_objs |= fetch_and_zero(&obj->write_domain);
> obj->read_domains |= I915_GEM_DOMAIN_GTT;
> @@ -1321,8 +1283,3 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
>
> intel_ggtt_restore_fences(ggtt);
> }
> -
> -void i915_ggtt_mark_pte_lost(struct drm_i915_private *i915, bool val)
> -{
> - to_gt(i915)->ggtt->pte_lost = val;
> -}
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index d1900fec6cd1f..a5a9f7640bd15 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -355,19 +355,6 @@ struct i915_ggtt {
>
> bool do_idle_maps;
>
> - /**
> - * @pte_lost: Are ptes lost on resume?
> - *
> - * Whether the system was recently restored from hibernate and
> - * thus may have lost pte content.
> - */
> - bool pte_lost;
> -
> - /**
> - * @probed_pte: Probed pte value on suspend. Re-checked on resume.
> - */
> - u64 probed_pte;
> -
> int mtrr;
>
> /** Bit 6 swizzling required for X tiling */
> @@ -604,17 +591,6 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm);
> void i915_ggtt_suspend(struct i915_ggtt *gtt);
> void i915_ggtt_resume(struct i915_ggtt *ggtt);
>
> -/**
> - * i915_ggtt_mark_pte_lost - Mark ggtt ptes as lost or clear such a marking
> - * @i915 The device private.
> - * @val whether the ptes should be marked as lost.
> - *
> - * In some cases pte content is retained across suspend, but typically lost
> - * across hibernate. Typically they should be marked as lost on
> - * hibernation restore and such marking cleared on suspend.
> - */
> -void i915_ggtt_mark_pte_lost(struct drm_i915_private *i915, bool val);
> -
> void
> fill_page_dma(struct drm_i915_gem_object *p, const u64 val, unsigned int count);
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
> index 4e1bb3c23c638..4cc3ced839595 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -102,9 +102,6 @@
> #include "intel_region_ttm.h"
> #include "vlv_suspend.h"
>
> -/* Intel Rapid Start Technology ACPI device name */
> -static const char irst_name[] = "INT3392";
> -
> static const struct drm_driver i915_drm_driver;
>
> static void i915_release_bridge_dev(struct drm_device *dev,
> @@ -1496,8 +1493,6 @@ static int i915_pm_suspend(struct device *kdev)
> return -ENODEV;
> }
>
> - i915_ggtt_mark_pte_lost(i915, false);
> -
> if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
> return 0;
>
> @@ -1550,14 +1545,6 @@ static int i915_pm_resume(struct device *kdev)
> if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
> return 0;
>
> - /*
> - * If IRST is enabled, or if we can't detect whether it's enabled,
> - * then we must assume we lost the GGTT page table entries, since
> - * they are not retained if IRST decided to enter S4.
> - */
> - if (!IS_ENABLED(CONFIG_ACPI) || acpi_dev_present(irst_name, NULL, -1))
> - i915_ggtt_mark_pte_lost(i915, true);
> -
> return i915_drm_resume(&i915->drm);
> }
>
> @@ -1617,9 +1604,6 @@ static int i915_pm_restore_early(struct device *kdev)
>
> static int i915_pm_restore(struct device *kdev)
> {
> - struct drm_i915_private *i915 = kdev_to_i915(kdev);
> -
> - i915_ggtt_mark_pte_lost(i915, true);
> return i915_pm_resume(kdev);
> }
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
next prev parent reply other threads:[~2022-12-01 9:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 23:58 [Intel-gfx] [PATCH v4 0/5] Add guard padding around i915_vma Andi Shyti
2022-11-30 23:58 ` [Intel-gfx] [PATCH v4 1/5] drm/i915: Limit the display memory alignment to 32 bit instead of 64 Andi Shyti
2022-11-30 23:58 ` [Intel-gfx] [PATCH v4 2/5] drm/i915: Wrap all access to i915_vma.node.start|size Andi Shyti
2022-11-30 23:58 ` [Intel-gfx] [PATCH v4 3/5] drm/i915: Introduce guard pages to i915_vma Andi Shyti
2022-12-01 8:59 ` Tvrtko Ursulin
2022-12-01 10:45 ` Andi Shyti
2022-12-01 10:50 ` Tvrtko Ursulin
2022-12-01 14:44 ` [Intel-gfx] [PATCH v5 " Andi Shyti
2022-12-01 14:51 ` Tvrtko Ursulin
2022-12-01 20:39 ` [Intel-gfx] [PATCH v6 " Andi Shyti
2022-12-02 10:20 ` Tvrtko Ursulin
2022-12-02 11:11 ` Andi Shyti
2022-12-02 12:38 ` Tvrtko Ursulin
2022-11-30 23:58 ` [Intel-gfx] [PATCH v4 4/5] drm/i915: Refine VT-d scanout workaround Andi Shyti
2022-12-01 9:00 ` Tvrtko Ursulin
2022-11-30 23:58 ` [Intel-gfx] [PATCH v4 5/5] Revert "drm/i915: Improve on suspend / resume time with VT-d enabled" Andi Shyti
2022-12-01 9:02 ` Tvrtko Ursulin [this message]
2022-12-01 0:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for add guard padding around i915_vma (rev4) Patchwork
2022-12-01 0:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-12-01 1:26 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-12-01 15:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for add guard padding around i915_vma (rev5) Patchwork
2022-12-01 15:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-12-01 16:07 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-12-01 21:05 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for add guard padding around i915_vma (rev6) Patchwork
2022-12-01 21:30 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-12-02 14:13 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for add guard padding around i915_vma (rev7) Patchwork
2022-12-02 14:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-12-02 14:43 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-03 2:27 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-12-05 14:47 ` Andi Shyti
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=6d43a21e-6699-e85f-3c5f-3855cbf5342e@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=thomas.hellstrom@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox