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 <[email protected]> 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/[email protected]?part=1
