kernel/linux.git/drivers/gpu/drm/i915/display/intel_fbdev.c, branch v7.2-rc6

drm/i915/display: pass struct intel_display to all for_each_intel_crtc*() macros

2026-05-26T22:08:01+00:00

Now that the for_each_intel_crtc*() iterator macros primarily use display->pipe_list for iteration, it's more convenient to pass struct intel_display to them directly instead of struct drm_device. Make it so. Reviewed-by: Ville Syrjälä Link: https://patch.msgid.link/90ec6b84d772a4842d4816efc10042ec4403e996.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula

drm/i915/fbdev: Use intel_parent_fb_pin_ggtt_(un)pin()

2026-05-11T14:43:25+00:00

Replace the intel_fb_pin_to_ggtt() and intel_fb_unpin_vma() with the new abstract parent interface (intel_parent_fb_pin_ggtt_(un)pin()). xe no longer needs intel_fb_unpin_vma(), and in i915 it now becomes and internal function to i915_fb_pin. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260508143426.26504-15-ville.syrjala@linux.intel.com

drm/xe: Kill the fbdev vma reuse hack

2026-05-11T14:43:25+00:00

This fbdev vma reuse hacks is a massive layering violation. It really does not belong in the fb pinning code. And it's in the way of properly abstracting this stuff, so kill it. I don't think this hack even does anything useful because the normal view will just use bo->ggtt_node when present, and the fbdev bo will be permanenly pinned with xe_bo_create_pin_map_at_novm() which does set up bo->ggtt_node. So we should never end up rebuilding the PTEs for the fbdev bo, even without the reuse hack. v2: Pimp the commit message a a bit (Jani) v3: Also nuke intel_fbdev_vma_pointer() Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260508143426.26504-9-ville.syrjala@linux.intel.com

drm/i915: Move intel_fb_pin_params to the parent interface

2026-05-11T14:43:24+00:00

strut intel_fb_pin_params will be an important part of the fb_pin interface, so move the definition to the parent interface file. Or maybe we should have a separate header for this kind of stuff since the users of the parent interface will need the struct definition but not the parent interface vfunc struct definitions? Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260508143426.26504-3-ville.syrjala@linux.intel.com

drm/i915: Introduce intel_parent_fb_pin_get_map()

2026-05-11T14:43:24+00:00

Introduce the "fb_pin" parent interface, as the first trivial step move the *_get_map() stuff there. The whole "fb_pin" as an interface might not really make sense, and perhaps this (and other stuff) should just be collected into some kind of "bo" interface. But let's go with "fb_pin" for now to match where things are implemented, and possibly restructure it later. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260508143426.26504-2-ville.syrjala@linux.intel.com

drm/i915: Don't pass the framebuffer to low level pinning functions

2026-04-21T10:13:35+00:00

Now that we have the pin_params the low level pinning code no longer needs the entire framebuffer structure. The gem object alone (along with the pin_params) is enough. Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260416174448.28264-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915: Introduce pin_params.needs_low_address

2026-04-21T10:10:56+00:00

Add a new flag pin_params.needs_low_address to inform the pinning code that the display needs a low ggtt address. The goal is to eliminate all display specific stuff from the low level pinning code (the direct intel_plane_needs_low_addres()) call in this case). Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260416174448.28264-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915: Introduce struct intel_fb_pin_params

2026-04-21T10:07:38+00:00

We need to pass a lot of information between the display driver and the core driver to get framebuffers mapped into GGTT/DPT correctly. Rather than passing around a swarm of integers and boolean as function arguments, let's collect it all into a structure (struct intel_fb_pin_params). Start by moving the gtt view, alignment, phys_alignment, and vtd_guard there. Going forward additional things need to added as well (mainly various boolean flags). Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260416174448.28264-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915: Track fence region ID in plane state

2026-04-15T16:04:41+00:00

Get rid of the needlessly complicated PLANE_HAS_FENCE + intel_parent_vma_fence_id() dance by simply tracking the fence_id directly in the plane state. v2: Don't request the redundant fence for fbdev (Jani) Assign *out_fence_id with '=' instead of '|=' (Sashiko,Jani) Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patch.msgid.link/20260407170942.16515-1-ville.syrjala@linux.intel.com

drm/{i915, xe}: move fbdev fb calls to parent interface

2026-04-02T07:45:59+00:00

Move the driver specific fbdev fb calls to the display parent interface. Reuse the existing struct intel_display_bo_interface, as this is mostly about gem objects. Put everything behind IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) to catch configuration issues at build or link time. v2: Rebase Reviewed-by: Michał Grzelak # v1 Link: https://patch.msgid.link/a6bb24909a58181cfc41b91a4c6538a181d27158.1774950508.git.jani.nikula@intel.com Signed-off-by: Jani Nikula