drm/i915: Extract intel_plane_needs_low_address()

Extract the naked "gmch? -> need a low ggtt address" check into
a more descriptive helper (intel_plane_needs_low_address()).
The goal being to eliminate all display specific stuff from the
low level pinning code.

The actual implementation still abuses PIN_MAPPABLE to achieve
this goal. I'm not entire convinced that this whole thing even
needs to exist, and the original issue wasn't just caused by
some other bug. But no time to dig into it right now, so let's
keep going.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

diff --git a/drivers/gpu/drm/i915/display/intel_plane.c b/drivers/gpu/drm/i915/display/intel_plane.c
index f15dd9e91243a321dc009932b3e47d6a5ba91720..f41f4c2ac3202c429093f16c581a2d93e3c8450f 100644 (file)
--- a/drivers/gpu/drm/i915/display/intel_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_plane.c
@@ -171,6 +171,19 @@ intel_plane_destroy_state(struct drm_plane *plane,
        kfree(plane_state);
 }
 
+bool intel_plane_needs_low_address(struct intel_display *display)
+{
+       /*
+        * Valleyview is definitely limited to scanning out the first
+        * 512MiB. Lets presume this behaviour was inherited from the
+        * g4x display engine and that all earlier gen are similarly
+        * limited. Testing suggests that it is a little more
+        * complicated than this. For example, Cherryview appears quite
+        * happy to scanout from anywhere within its global aperture.
+        */
+       return HAS_GMCH(display);
+}
+
 bool intel_plane_needs_physical(struct intel_plane *plane)
 {
        struct intel_display *display = to_intel_display(plane);

diff --git a/drivers/gpu/drm/i915/display/intel_plane.h b/drivers/gpu/drm/i915/display/intel_plane.h
index 5a8f2f3baab5f1fe9bdf35bc040e261826d23d5f..7fa7fbbb58dc942ecd1b491093da8f5a9374b49b 100644 (file)
--- a/drivers/gpu/drm/i915/display/intel_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_plane.h
@@ -15,6 +15,7 @@ struct drm_rect;
 struct intel_atomic_state;
 struct intel_crtc;
 struct intel_crtc_state;
+struct intel_display;
 struct intel_dsb;
 struct intel_plane;
 struct intel_plane_state;
@@ -79,6 +80,7 @@ int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state);
 void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
                               struct intel_plane_state *plane_state);
 void intel_plane_helper_add(struct intel_plane *plane);
+bool intel_plane_needs_low_address(struct intel_display *display);
 bool intel_plane_needs_physical(struct intel_plane *plane);
 void intel_plane_init_cursor_vblank_work(struct intel_plane_state *old_plane_state,
                                         struct intel_plane_state *new_plane_state);

diff --git a/drivers/gpu/drm/i915/i915_fb_pin.c b/drivers/gpu/drm/i915/i915_fb_pin.c
index 96ffc4b0d809ad685c1a722918a7198c27d4ef30..a3e5107c12f02155267979ae3dfb1f804da1e1ed 100644 (file)
--- a/drivers/gpu/drm/i915/i915_fb_pin.c
+++ b/drivers/gpu/drm/i915/i915_fb_pin.c
@@ -140,16 +140,9 @@ intel_fb_pin_to_ggtt(const struct drm_framebuffer *fb,
 
        atomic_inc(&i915->pending_fb_pin);
 
-       /*
-        * Valleyview is definitely limited to scanning out the first
-        * 512MiB. Lets presume this behaviour was inherited from the
-        * g4x display engine and that all earlier gen are similarly
-        * limited. Testing suggests that it is a little more
-        * complicated than this. For example, Cherryview appears quite
-        * happy to scanout from anywhere within its global aperture.
-        */
        pinctl = 0;
-       if (HAS_GMCH(display))
+       /* PIN_MAPPABLE limits the address to GMADR size */
+       if (intel_plane_needs_low_address(display))
                pinctl |= PIN_MAPPABLE;
 
        i915_gem_ww_ctx_init(&ww, true);