From: Matthew Auld <matthew.auld@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
Maarten Lankhorst <dev@lankhorst.se>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH v3.1] drm/xe/display: Fix fbdev GGTT mapping handling.
Date: Thu, 20 Feb 2025 15:43:33 +0000 [thread overview]
Message-ID: <9b9afafc-74cf-4899-a655-4765c9fb8f9a@intel.com> (raw)
In-Reply-To: <dftpyfotba6vxp6pkiircxpm7ok7sowzx6x2fu52hdjug4rzfe@uc7e47olt7uv>
On 20/02/2025 14:22, Lucas De Marchi wrote:
> On Wed, Feb 19, 2025 at 04:34:40PM +0100, Maarten Lankhorst wrote:
>> The fbdev vma is a normal unrotated VMA, so add ane explicit check
>> before re-using.
>>
>> When re-using, we have to restore the GGTT mapping on resume, so add
>> some code to do that too.
>>
>> Fixes: 67a98f7e27ba ("drm/xe/display: Re-use display vmas when possible")
>> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
>> ---
>> drivers/gpu/drm/xe/display/xe_display.c | 6 +++++-
>> drivers/gpu/drm/xe/display/xe_fb_pin.c | 24 +++++++++++++++++++++++-
>> drivers/gpu/drm/xe/display/xe_fb_pin.h | 13 +++++++++++++
>> 3 files changed, 41 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/gpu/drm/xe/display/xe_fb_pin.h
>>
>> diff --git a/drivers/gpu/drm/xe/display/xe_display.c b/drivers/gpu/
>> drm/xe/display/xe_display.c
>> index 02a413a073824..999f25a562c19 100644
>> --- a/drivers/gpu/drm/xe/display/xe_display.c
>> +++ b/drivers/gpu/drm/xe/display/xe_display.c
>> @@ -30,6 +30,7 @@
>> #include "intel_hotplug.h"
>> #include "intel_opregion.h"
>> #include "skl_watermark.h"
>> +#include "xe_fb_pin.h"
>> #include "xe_module.h"
>>
>> /* Xe device functions */
>> @@ -492,8 +493,11 @@ void xe_display_pm_resume(struct xe_device *xe)
>> intel_display_driver_enable_user_access(display);
>> }
>>
>> - if (has_display(xe))
>> + if (has_display(xe)) {
>> + xe_fb_pin_resume(xe);
>
> this looks odd. I remember when we had issues with LNL about pages
> coming with garbage after a resume we talked about marking them as
> "needed" on suspend so they'd be saved by mm. The ggtt afair was one of
> them. Or did we go with a different approach and I'm misremembering?
Hmm, I thought for display fbs we don't use the same pin tracking so it
is rather skipped by the GGTT save/restore logic. But I thought
previously the display stuff ensured all fb are unpinned by the time we
do the suspend, so on resume we would just re-program the GGTT for fb
when re-pinning it (handled by display code). But I guess issue now
comes with re-using the vma and its GGTT mapping, since it will now also
skip re-programming the GGTT on re-pin? But wouldn't we have this same
issue for all fb, and not just this fbdev stuff or does reuse_vma()
somehow handle this?
>
> +Matthew Brost / +Matthew Auld
> I think this was about commit dd886a63d6e2 ("drm/xe: Restore system
> memory GGTT mappings")
>
> Lucas De Marchi
>
>> +
>> intel_hpd_poll_disable(xe);
>> + }
>>
>> intel_opregion_resume(display);
>>
>> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/
>> xe/display/xe_fb_pin.c
>> index 11a6b996d739b..dee1f6531c849 100644
>> --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
>> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
>> @@ -12,6 +12,7 @@
>> #include "intel_fbdev.h"
>> #include "xe_bo.h"
>> #include "xe_device.h"
>> +#include "xe_fb_pin.h"
>> #include "xe_ggtt.h"
>> #include "xe_pm.h"
>>
>> @@ -398,7 +399,8 @@ static bool reuse_vma(struct intel_plane_state
>> *new_plane_state,
>> goto found;
>> }
>>
>> - if (fb == intel_fbdev_framebuffer(xe->display.fbdev.fbdev)) {
>> + if (fb == intel_fbdev_framebuffer(xe->display.fbdev.fbdev) &&
>> + new_plane_state->view.gtt.type == I915_GTT_VIEW_NORMAL) {
>> vma = intel_fbdev_vma_pointer(xe->display.fbdev.fbdev);
>> if (vma)
>> goto found;
>> @@ -444,6 +446,26 @@ void intel_plane_unpin_fb(struct
>> intel_plane_state *old_plane_state)
>> old_plane_state->ggtt_vma = NULL;
>> }
>>
>> +void xe_fb_pin_resume(struct xe_device *xe)
>> +{
>> + struct xe_ggtt *ggtt = xe_device_get_root_tile(xe)->mem.ggtt;
>> + struct i915_vma *vma = intel_fbdev_vma_pointer(xe-
>> >display.fbdev.fbdev);
>> + struct xe_bo *bo;
>> +
>> + if (!vma)
>> + return;
>> +
>> + bo = vma->bo;
>> +
>> + mutex_lock(&ggtt->lock);
>> + for (u32 x = 0; x < bo->ttm.base.size; x += XE_PAGE_SIZE) {
>> + u64 pte = ggtt->pt_ops->pte_encode_bo(bo, x, xe-
>> >pat.idx[XE_CACHE_NONE]);
>> +
>> + ggtt->pt_ops->ggtt_set_pte(ggtt, vma->node->base.start + x,
>> pte);
>> + }
>> + mutex_unlock(&ggtt->lock);
>> +}
>> +
>> /*
>> * For Xe introduce dummy intel_dpt_create which just return NULL,
>> * intel_dpt_destroy which does nothing, and fake intel_dpt_ofsset
>> returning 0;
>> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.h b/drivers/gpu/drm/
>> xe/display/xe_fb_pin.h
>> new file mode 100644
>> index 0000000000000..39d48ff637002
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.h
>> @@ -0,0 +1,13 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2025 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_FB_PIN_H_
>> +#define _XE_FB_PIN_H_
>> +
>> +struct xe_device;
>> +
>> +void xe_fb_pin_resume(struct xe_device *xe);
>> +
>> +#endif /* _XE_FB_PIN_H_ */
>> --
>> 2.47.1
>>
next prev parent reply other threads:[~2025-02-20 15:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 15:34 [PATCH v3.1] drm/xe/display: Fix fbdev GGTT mapping handling Maarten Lankhorst
2025-02-19 15:39 ` ✓ CI.Patch_applied: success for drm/xe/display: Fix fbdev GGTT mapping handling. (rev5) Patchwork
2025-02-19 15:40 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-19 15:41 ` ✓ CI.KUnit: success " Patchwork
2025-02-19 15:58 ` ✓ CI.Build: " Patchwork
2025-02-19 16:00 ` ✓ CI.Hooks: " Patchwork
2025-02-19 16:02 ` ✓ CI.checksparse: " Patchwork
2025-02-19 16:23 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-20 13:58 ` ✗ Xe.CI.Full: failure " Patchwork
2025-02-20 14:22 ` [PATCH v3.1] drm/xe/display: Fix fbdev GGTT mapping handling Lucas De Marchi
2025-02-20 15:43 ` Matthew Auld [this message]
2025-02-20 17:17 ` Maarten Lankhorst
2025-03-04 23:09 ` Lucas De Marchi
2025-03-05 10:39 ` [PATCH v3.2] " Maarten Lankhorst
2025-03-05 13:53 ` Lucas De Marchi
2025-03-05 18:23 ` ✗ Xe.CI.Full: failure for drm/xe/display: Fix fbdev GGTT mapping handling. (rev6) 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=9b9afafc-74cf-4899-a655-4765c9fb8f9a@intel.com \
--to=matthew.auld@intel.com \
--cc=dev@lankhorst.se \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@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