github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-07-28 01:55:51 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

drm/i915: Extract intel_plane_needs_low_address()

Browse Source 
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>
This commit is contained in:
Ville Syrjälä 2026-04-16 20:44:41 +03:00
parent 2423bd7e73
commit 41ff682e42
3 changed files with 17 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
drivers/gpu/drm/i915/display/intel_plane.c
View File

@ -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);

2
drivers/gpu/drm/i915/display/intel_plane.h
View File

@ -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);

11
drivers/gpu/drm/i915/i915_fb_pin.c
View File

@ -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);