NACK/Cmnt: [SRU][resolute][PATCH v2 1/1] UBUNTU: SAUCE: drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs

Jian Hui Lee jianhui.lee at canonical.com
Tue Jul 7 09:21:53 UTC 2026


hi chun an,

On Tue, Jul 7, 2026 at 4:14 PM ChunAn Wu via kernel-team
<kernel-team at lists.ubuntu.com> wrote:
>
> From: Matthew Auld <matthew.auld at intel.com>
>
> BugLink: https://bugs.launchpad.net/bugs/2158605
>
> Currently, xe_display_bo_framebuffer_init() unconditionally attempts to
> apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with
> -EINVAL if the BO is already VM_BINDed.
>
> However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem
> to make much sense since CPU caching policy is entirely controlled by
> the exporter. Plus there is no place to set this flag, in the first
> place. Also this is not rejected if not yet vm_binded, but that seems
> arbitrary since setting or not setting FORCE_WC should a noop either
> way, at this stage, and whether it is currently VM_BINDed makes no
> difference.
>
> Currently if we run an app and offload rendering to an external dGPU,
> like NV or another xe device, the dma-buf passed back to the compositor
> (igpu) will be an actual external import from xe pov, and it will be
> missing FORCE_WC, and if the compositor side did a VM_BIND before
> turning into it into an fb the whole thing gets rejected.
>
> So it looks like we either need to reject outright, no matter what, or
> this usecase is valid and we need to loosen the restriction for sg
> buffers. Proposing here to loosen the restriction.
>
> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
> Link: https://patchwork.freedesktop.org/patch/732636/
> Signed-off-by: Matthew Auld <matthew.auld at intel.com>
> Cc: Thomas Hellström <thomas.hellstrom at linux.intel.com>
> Cc: Matthew Brost <matthew.brost at intel.com>
> Cc: Maarten Lankhorst <dev at lankhorst.se>
> Reviewed-by: Maarten Lankhorst <dev at lankhorst.se>
> [anwu: Backported from Patchwork. Ubuntu trees still carry this code in
>  intel_fb_bo.c rather than xe_display_bo.c, and use SCANOUT flag names,
>  so apply the same ttm_bo_type_sg exemption to the local framebuffer
>  init and pin checks.]
>
> Signed-off-by: ChunAn Wu <an.wu at canonical.com>
> ---
>  drivers/gpu/drm/xe/display/intel_fb_bo.c | 3 ++-
>  drivers/gpu/drm/xe/display/xe_fb_pin.c   | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/display/intel_fb_bo.c b/drivers/gpu/drm/xe/display/intel_fb_bo.c
> index b21da7b745a5..4560825656db 100644
> --- a/drivers/gpu/drm/xe/display/intel_fb_bo.c
> +++ b/drivers/gpu/drm/xe/display/intel_fb_bo.c
> @@ -33,7 +33,8 @@ int intel_fb_bo_framebuffer_init(struct intel_framebuffer *intel_fb,
>         if (ret)
>                 return ret;
>
> -       if (!(bo->flags & XE_BO_SCANOUT_BIT)) {
> +       if (!(bo->flags & XE_BO_SCANOUT_BIT) &&
XE_BO_SCANOUT_BIT is not defined in resolute kernel.

> +           bo->ttm.type != ttm_bo_type_sg) {
>                 /*
>                  * XE_BO_SCANOUT_BIT should ideally be set at creation, or is
>                  * automatically set when creating FB. We cannot change caching
> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> index 722c84a56607..6ae98696a20d 100644
> --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
> @@ -353,7 +353,8 @@ int intel_plane_pin_fb(struct intel_plane_state *plane_state)
>         struct i915_vma *vma;
>
>         /* We reject creating !SCANOUT fb's, so this is weird.. */
> -       drm_WARN_ON(bo->ttm.base.dev, !(bo->flags & XE_BO_SCANOUT_BIT));
> +       drm_WARN_ON(bo->ttm.base.dev, !(bo->flags & XE_BO_SCANOUT_BIT) &&
same as above.

> +                   bo->ttm.type != ttm_bo_type_sg);
>
>         vma = __xe_pin_fb_vma(to_intel_framebuffer(fb), &plane_state->view.gtt);
>         if (IS_ERR(vma))
> --
> 2.34.1
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team



More information about the kernel-team mailing list