Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
>>


  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