wireguard-linux/include/drm/intel/display_parent_interface.h, branch stable

drm/{i915,xe}: move framebuffer bo to parent interface

2026-03-16T09:00:21Z

Add .framebuffer_init, .framebuffer_fini and .framebuffer_lookup to the bo parent interface. While they're about framebuffers, they're specifically about framebuffer objects, so the bo interface is a good enough fit, and there's no need to add another interface struct. Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/848d32a44bf844cba3d66e44ba9f20bea4a8352d.1773238670.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/{i915, xe}/bo: move display bo calls to parent interface

2026-03-16T09:00:21Z

Continue i915 and xe separation from display by moving the bo calls to the display parent interface. Instead of adding all these functions to intel_parent.[ch], reuse the now vacated intel_bo.[ch], and avoid mass renames to calls of these functions. This is similar to intel_display_rpm.[ch]. Make many of the hooks optional to avoid having to implement dummy functions in xe. Indeed now we can remove many of the existing dummy functions. Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/7899eef2ccf0cd603df69099df065226a0df917b.1773238670.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/{i915, xe}/frontbuffer: move frontbuffer handling to parent interface

2026-03-11T09:32:10Z

Move the get/put/ref/flush_for_display calls to the display parent interface. For i915, move the hooks next to the other i915 core frontbuffer code in i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for the same. Note: The intel_frontbuffer_flush() calls from i915_gem_object_frontbuffer.c will partially route back to i915 core via the parent interface. This is less than stellar. Reviewed-by: Jouni Högander Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/intel: fix @dpt kernel-doc for parent interface

2026-03-11T09:32:10Z

Fix the copy-paste fail. Reviewed-by: Jouni Högander Link: https://patch.msgid.link/0209e128312520ca1c6a0c39f9dfb0184125322a.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915: add VMA to parent interface

2026-03-03T14:05:58Z

It's unclear what the direction of the VMA abstraction in the parent interface should be, but convert i915_vma_fence_id() to parent interface for starters. This paves the way for making struct i915_vma opaque towards display. Reviewed-by: Michał Grzelak Link: https://patch.msgid.link/036f4b2d20cc1b0a7ab814beb5bb914c53b6eb53.1772212579.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/overlay: Convert overlay to parent interface

2026-02-27T08:41:35Z

Convert the direct i915_overlay_*() calls from the display side to go over a new parent interface instead. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) v3: Rebase due to the NULL check in intel_overlay_cleanup() Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260226130150.16816-1-ville.syrjala@linux.intel.com

drm/i915/dpt: pass opaque struct intel_dpt around instead of i915_address_space

2026-02-26T21:28:57Z

struct i915_address_space is used in an opaque fashion in the display parent interface, but it's just one include away from being non-opaque. And anyway the name is rather specific. Switch to using the struct intel_dpt instead, which embeds struct i915_address_space anyway. With the definition hidden in i915_dpt.c, this can't be accidentally made non-opaque, and the type seems rather more generic anyway. We do have to add a new helper i915_dpt_to_vm(), as there's one case in intel_fb_pin_to_dpt() that requires direct access to struct i915_address_space. But this just underlines the point about opacity. Reviewed-by: Juha-Pekka Heikkila Link: https://patch.msgid.link/daa39178c0b0305b010564952d691f06e3cd63ca.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/dpt: move suspend/resume to parent interface

2026-02-26T21:28:57Z

Add per-vm DPT suspend/resume calls to the display parent interface, and lift the generic code away from i915 specific code. Reviewed-by: Juha-Pekka Heikkila Link: https://patch.msgid.link/080945a49559ec1f5183ad409e1526736e828d90.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/dpt: move create/destroy to parent interface

2026-02-26T21:28:57Z

Move the DPT create/destroy calls to the display parent interface. With this, we can remove the dummy xe implementation. Reviewed-by: Juha-Pekka Heikkila Link: https://patch.msgid.link/9753b21466c668872f468ccff827eab7be034b0c.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/{i915, xe}/pcode: move display pcode calls to parent interface

2026-01-27T14:45:53Z

Call the parent driver pcode functions through the parent interface function pointers instead of expecting both to have functions of the same name. In i915, add the interface to existing intel_pcode.[ch], while in xe move them to new display/xe_display_pcode.[ch] and build it only for CONFIG_DRM_XE_DISPLAY=y. Do not add separate write and write_timeout calls in the interface. Instead, handle the default 1 ms timeout in the intel_parent.c glue layer. This drops the last intel_pcode.h includes from display, and allows us to remove the corresponding xe compat header. v2: initialize .pcode in i915 Reviewed-by: Michał Grzelak Link: https://patch.msgid.link/20260126112925.2452171-1-jani.nikula@intel.com Signed-off-by: Jani Nikula