mirror of
https://github.com/torvalds/linux.git
synced 2026-08-01 12:11:59 +02:00
drm/i915: Make sure wm block/lines are non-decreasing
The watermark algorithm sometimes produces results where higher watermark levels have smaller blocks/lines watermarks than the lower levels. That doesn't really make sense as the corresponding latencies are supposed to be non-decreasing. It's unclear how the hardware responds to such watermark values, so it seems better to avoid that case and just make sure the values are always non-decreasing. Here's an example how things change for such a case on a GLK NUC: [PLANE:70:cursor A] level wm0, wm1, wm2, wm3, wm4, wm5, wm6, wm7, twm, swm, stwm -> *wm0,*wm1,*wm2,*wm3,*wm4,*wm5,*wm6,*wm7,*twm, swm, stwm [PLANE:70:cursor A] lines 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 -> 4, 4, 4, 2, 2, 2, 2, 2, 0, 0, 0 [PLANE:70:cursor A] blocks 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 -> 11, 11, 12, 7, 7, 7, 7, 7, 25, 0, 0 [PLANE:70:cursor A] min_ddb 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 -> 12, 12, 13, 8, 8, 8, 8, 8, 26, 0, 0 -> [PLANE:70:cursor A] level wm0, wm1, wm2, wm3, wm4, wm5, wm6, wm7, twm, swm, stwm -> *wm0,*wm1,*wm2,*wm3,*wm4,*wm5,*wm6,*wm7,*twm, swm, stwm [PLANE:70:cursor A] lines 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 -> 4, 4, 4, 4, 4, 4, 4, 4, 0, 0, 0 [PLANE:70:cursor A] blocks 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 -> 11, 11, 12, 12, 12, 12, 12, 12, 25, 0, 0 [PLANE:70:cursor A] min_ddb 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 -> 12, 12, 13, 13, 13, 13, 13, 13, 26, 0, 0 Whether this actually helps on any display blinking issues is unclear. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8683 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919193000.17665-14-ville.syrjala@linux.intel.com
This commit is contained in:
parent
b86cb7beed
commit
840f6b9e48
|
|
@ -1878,18 +1878,21 @@ static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
|
|||
} else {
|
||||
blocks++;
|
||||
}
|
||||
|
||||
/*
|
||||
* Make sure result blocks for higher latency levels are
|
||||
* at least as high as level below the current level.
|
||||
* Assumption in DDB algorithm optimization for special
|
||||
* cases. Also covers Display WA #1125 for RC.
|
||||
*/
|
||||
if (result_prev->blocks > blocks)
|
||||
blocks = result_prev->blocks;
|
||||
}
|
||||
}
|
||||
|
||||
/*
|
||||
* Make sure result blocks for higher latency levels are
|
||||
* at least as high as level below the current level.
|
||||
* Assumption in DDB algorithm optimization for special
|
||||
* cases. Also covers Display WA #1125 for RC.
|
||||
*
|
||||
* Let's always do this as the algorithm can give non
|
||||
* monotonic results on any platform.
|
||||
*/
|
||||
blocks = max_t(u32, blocks, result_prev->blocks);
|
||||
lines = max_t(u32, lines, result_prev->lines);
|
||||
|
||||
if (DISPLAY_VER(display) >= 11) {
|
||||
if (wp->y_tiled) {
|
||||
int extra_lines;
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user