Re: [PATCH v2 1/2] drm/mipi-dbi: honour the plane source offset when flushing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/mipi-dbi: hardware protocol violation for 0-width damage rects
--

commit f18906cb9ed3368767cdf7495a3f7b34e33a50c0
Author: Jonathan Frazin <frazinjonathan@gmail.com>
Date:   Wed Sep 23 19:57:11 2026 +0000

    drm/mipi-dbi: honour the plane source offset when flushing

This commit updates mipi_dbi_fb_dirty() to account for the plane's source
origin when calculating the display window address. It also clamps the damage
rectangle to the panel's fixed mode to prevent overshoots caused by
fractional scaling.

> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 25cf04d029f77..1263dce91c80a 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
[ ... ]
> @@ -271,19 +271,35 @@ static void mipi_dbi_set_window_address(struct mipi_dbi_dev *dbidev,
>  }
>  
>  static void mipi_dbi_fb_dirty(struct iosys_map *src, struct drm_framebuffer *fb,
> -			      struct drm_rect *rect, struct drm_format_conv_state *fmtcnv_state)
> +			      struct drm_rect *rect, unsigned int src_x, unsigned int src_y,
> +			      struct drm_format_conv_state *fmtcnv_state)
>  {
[ ... ]
> +	/*
> +	 * @rect is in framebuffer coordinates, clipped to the plane's src
> +	 * rectangle by the damage iterator against that rectangle's exact
> +	 * 16.16 fixed-point bounds. @src_x/@src_y are that same origin
> +	 * truncated to whole pixels. When the origin has a fractional part,
> +	 * that truncation can leave @rect's far edge up to a pixel past
> +	 * where a whole-pixel @src_x/@src_y would place the panel's own
> +	 * width/height -- and tx_buf is sized for exactly the panel, with no
> +	 * slack for that overshoot. Clamp before using @rect for anything.
> +	 */
> +	rect->x2 = min_t(int, rect->x2, src_x + dbidev->mode.hdisplay);
> +	rect->y2 = min_t(int, rect->y2, src_y + dbidev->mode.vdisplay);
> +
> +	height = rect->y2 - rect->y1;
> +	width = rect->x2 - rect->x1;

[Severity: Medium]
If drm_atomic_helper_damage_merged() clips a damage rectangle entirely to the
fractional overshoot region (e.g., where x1 is at src_x + hdisplay and x2
extends 1 pixel beyond it), does clamping only the far edge result in
rect->x2 becoming equal to rect->x1, leaving width or height as 0?

>  
>  	full = width == fb->width && height == fb->height;
>  
>  	DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, DRM_RECT_ARG(rect));
> @@ -298,8 +314,13 @@ static void mipi_dbi_fb_dirty(struct iosys_map *src, struct drm_framebuffer *fb,
>  		tr = src->vaddr; /* TODO: Use mapping abstraction properly */
>  	}
>  
> -	mipi_dbi_set_window_address(dbidev, rect->x1, rect->x2 - 1, rect->y1,
> -				    rect->y2 - 1);
> +	/*
> +	 * @rect is in framebuffer coordinates and has been clipped to the plane
> +	 * src rectangle by the damage iterator. The panel is addressed relative
> +	 * to the src origin, so subtract it here.
> +	 */
> +	mipi_dbi_set_window_address(dbidev, rect->x1 - src_x, rect->x2 - 1 - src_x,
> +				    rect->y1 - src_y, rect->y2 - 1 - src_y);

[Severity: Medium]
If width or height evaluates to 0 (as questioned above), will this calculate
an underflowed end window coordinate where the end is strictly less than the
start (e.g. xe < xs, due to rect->x2 - 1)?

Since this is followed by a 0-length data transfer, does sending an inverted
window address violate the MIPI DCS specification and potentially cause the
display controller to lock up or corrupt the display state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923195713.88-1-frazinjonathan@gmail.com?part=1