From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Subject: [PATCH 10/11] drm/xe: Eliminate intel_fb_uses_dpt() call from __xe_pin_fb_vma()
Date: Thu, 16 Apr 2026 20:44:46 +0300 [thread overview]
Message-ID: <20260416174448.28264-11-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20260416174448.28264-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Move the intel_fb_uses_dpt() out from __xe_pin_fb_vma() into
intel_plane_pin_fb() so the we don't any display stuff that deep
in the pinning code.
And intel_fb_pin_to_ggtt() can just say "this does not need DPT"
always since it's specifically about pinning the fb into GGTT.
The previous logic here was kinda insane with the high level code
assuming GGTT, and low level code potentially deciding otherwise.
In practice it should have been fine because intel_fb_pin_to_ggtt()
only gets used from the intiial_palne code, and there we are
not supposed to be have a framebuffer that needs DPT.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
index a4eb06cfa769..44562769fbc9 100644
--- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
+++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
@@ -318,7 +318,7 @@ static int __xe_pin_fb_vma_ggtt(const struct intel_framebuffer *fb,
return ret;
}
-static struct i915_vma *__xe_pin_fb_vma(const struct intel_framebuffer *fb,
+static struct i915_vma *__xe_pin_fb_vma(const struct intel_framebuffer *fb, bool is_dpt,
const struct intel_fb_pin_params *pin_params)
{
struct drm_device *dev = fb->base.dev;
@@ -375,7 +375,7 @@ static struct i915_vma *__xe_pin_fb_vma(const struct intel_framebuffer *fb,
goto err;
vma->bo = bo;
- if (intel_fb_uses_dpt(&fb->base))
+ if (is_dpt)
ret = __xe_pin_fb_vma_dpt(fb, pin_params, vma);
else
ret = __xe_pin_fb_vma_ggtt(fb, pin_params, vma);
@@ -419,7 +419,7 @@ intel_fb_pin_to_ggtt(const struct drm_framebuffer *fb,
if (out_fence_id)
*out_fence_id = -1;
- return __xe_pin_fb_vma(to_intel_framebuffer(fb), pin_params);
+ return __xe_pin_fb_vma(to_intel_framebuffer(fb), false, pin_params);
}
void intel_fb_unpin_vma(struct i915_vma *vma, int fence_id)
@@ -483,7 +483,8 @@ int intel_plane_pin_fb(struct intel_plane_state *new_plane_state,
/* We reject creating !SCANOUT fb's, so this is weird.. */
drm_WARN_ON(bo->ttm.base.dev, !(bo->flags & XE_BO_FLAG_FORCE_WC));
- vma = __xe_pin_fb_vma(intel_fb, &pin_params);
+ vma = __xe_pin_fb_vma(intel_fb, intel_fb_uses_dpt(&intel_fb->base),
+ &pin_params);
if (IS_ERR(vma))
return PTR_ERR(vma);
--
2.52.0
next prev parent reply other threads:[~2026-04-16 17:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 17:44 [PATCH 00/11] drm/i915: Eliminate FB usage from low level pinning code Ville Syrjala
2026-04-16 17:44 ` [PATCH 01/11] drm/xe/fb: Use the correct gtt view for remapped FBs Ville Syrjala
2026-04-16 17:44 ` [PATCH 02/11] drm/i915: Introduce struct intel_fb_pin_params Ville Syrjala
2026-04-17 9:40 ` Jani Nikula
2026-04-16 17:44 ` [PATCH 03/11] drm/i915: Extract intel_fb_needs_cpu_access() Ville Syrjala
2026-04-17 9:40 ` Jani Nikula
2026-04-16 17:44 ` [PATCH 04/11] drm/i915: Introduce pin_params.needs_cpu_lmem_access Ville Syrjala
2026-04-17 9:39 ` Jani Nikula
2026-04-17 11:33 ` Ville Syrjälä
2026-04-17 16:19 ` Ville Syrjälä
2026-04-16 17:44 ` [PATCH 05/11] drm/i915: Extract intel_plane_needs_low_address() Ville Syrjala
2026-04-17 9:43 ` Jani Nikula
2026-04-16 17:44 ` [PATCH 06/11] drm/i915: Introduce pin_params.needs_low_address Ville Syrjala
2026-04-17 9:48 ` Jani Nikula
2026-04-16 17:44 ` [PATCH 07/11] drm/i915: Introduce pin_params.needs_physical Ville Syrjala
2026-04-17 9:50 ` Jani Nikula
2026-04-16 17:44 ` [PATCH 08/11] drm/i915: Extract intel_plane_needs_fence() Ville Syrjala
2026-04-17 9:53 ` Jani Nikula
2026-04-16 17:44 ` [PATCH 09/11] drm/i915: Introduce pin_params.needs_fence Ville Syrjala
2026-04-17 9:58 ` Jani Nikula
2026-04-17 12:25 ` Ville Syrjälä
2026-04-16 17:44 ` Ville Syrjala [this message]
2026-04-17 10:19 ` [PATCH 10/11] drm/xe: Eliminate intel_fb_uses_dpt() call from __xe_pin_fb_vma() Jani Nikula
2026-04-16 17:44 ` [PATCH 11/11] drm/i915: Don't pass the framebuffer to low level pinning functions Ville Syrjala
2026-04-17 10:25 ` Jani Nikula
2026-04-16 17:52 ` ✓ CI.KUnit: success for drm/i915: Eliminate FB usage from low level pinning code Patchwork
2026-04-16 18:51 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-16 20:43 ` ✗ Xe.CI.FULL: failure " 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=20260416174448.28264-11-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
/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