From: Jonathan Frazin <frazinjonathan@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
kamlesh.gurudasani@gmail.com, lanzano.alex@gmail.com,
phil@raspberrypi.com, linux-kernel@vger.kernel.org,
Jonathan Frazin <frazinjonathan@gmail.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>
Subject: [PATCH v3 1/2] drm/mipi-dbi: honour the plane source offset when flushing
Date: Wed, 23 Sep 2026 15:58:33 -0500 [thread overview]
Message-ID: <20260923205835.3505-2-frazinjonathan@gmail.com> (raw)
In-Reply-To: <20260923205835.3505-1-frazinjonathan@gmail.com>
mipi_dbi_fb_dirty() takes the damage rectangle from
drm_atomic_helper_damage_merged(), which is expressed in framebuffer
coordinates and already clipped to the plane's source rectangle. It
then passed that rectangle straight to mipi_dbi_set_window_address(),
which is correct only while the source rectangle starts at (0,0) - i.e.
while the framebuffer is exactly panel-sized.
If a driver allows a framebuffer larger than the panel and the plane
selects a sub-region with a non-zero src_x/src_y, the controller was
still addressed in framebuffer coordinates, so the wrong part of the
panel was written and an out-of-range window could be programmed.
Pass the integer plane source origin down to mipi_dbi_fb_dirty() and
subtract it when programming the column/page address. The copy into the
transfer buffer still uses the framebuffer-coordinate rectangle, so it
keeps reading the correct pixels from an oversized source. With a
panel-sized framebuffer src_x/src_y are zero and behaviour is unchanged.
The rectangle from drm_atomic_helper_damage_merged() is clipped against
the src rectangle's exact 16.16 fixed-point bounds, while src_x/src_y
above are that same origin truncated to whole pixels. When the origin
has a fractional part, the truncation can leave the rectangle's far
edge up to a pixel past where a whole-pixel origin would place the
panel's own width/height - and tx_buf is sized for exactly the panel,
with no slack for that overshoot. Clamp the rectangle to the panel's
fixed mode before using it for the window address or the transfer
length.
A damage clip can also lie entirely within that one-pixel sliver past
the panel edge - the damage iterator clips only against the exact
fixed-point bound, not the whole-pixel one used here - collapsing the
clamped rectangle to zero width or height. Skip the flush in that case
rather than program an inverted (start past end) address window, which
is undefined behaviour per the MIPI DCS spec.
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Jonathan Frazin <frazinjonathan@gmail.com>
---
Changes since v2:
- A damage clip lying entirely within the one-pixel sliver the v2 clamp
cuts off collapses the clamped rectangle to zero width or height,
which was still reaching mipi_dbi_set_window_address() as an inverted
(start past end) address window ahead of a zero-length write - skip
the flush when the clamped rectangle is empty. Thanks again to the
automated review for catching this on v2.
Changes since v1:
- Clamp the damage rectangle to the panel's fixed mode before using it,
as described above. Thanks to the automated review for catching this.
drivers/gpu/drm/drm_mipi_dbi.c | 43 ++++++++++++++++++++++++++++++----
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 25cf04d02..bb557fab1 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -271,19 +271,45 @@ 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)
{
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
- unsigned int height = rect->y2 - rect->y1;
- unsigned int width = rect->x2 - rect->x1;
const struct drm_format_info *dst_format;
struct mipi_dbi *dbi = &dbidev->dbi;
bool swap = dbi->swap_bytes;
+ unsigned int height, width;
int ret = 0;
size_t len;
bool full;
void *tr;
+ /*
+ * @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.
+ *
+ * A damage clip can lie entirely in that one-pixel sliver past the
+ * panel edge -- the iterator above clips only against the exact
+ * fixed-point bound, not the whole-pixel one used here -- in which
+ * case the clamp collapses @rect to zero width or height. Nothing in
+ * it was ever visible on the panel, so skip the flush rather than
+ * program an inverted (start past end) address window.
+ */
+ rect->x2 = min_t(int, rect->x2, src_x + dbidev->mode.hdisplay);
+ rect->y2 = min_t(int, rect->y2, src_y + dbidev->mode.vdisplay);
+
+ if (rect->x2 <= rect->x1 || rect->y2 <= rect->y1)
+ return;
+
+ height = rect->y2 - rect->y1;
+ width = rect->x2 - rect->x1;
+
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 +324,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);
if (fb->format->format == DRM_FORMAT_XRGB8888)
dst_format = drm_format_info(dbidev->pixel_format);
@@ -390,6 +421,8 @@ void drm_mipi_dbi_plane_helper_atomic_update(struct drm_plane *plane,
if (drm_dev_enter(plane->dev, &idx)) {
if (drm_atomic_helper_damage_merged(old_plane_state, plane_state, &rect))
mipi_dbi_fb_dirty(&shadow_plane_state->data[0], fb, &rect,
+ plane_state->src_x >> 16,
+ plane_state->src_y >> 16,
&shadow_plane_state->fmtcnv_state);
drm_dev_exit(idx);
}
--
2.53.0
next prev parent reply other threads:[~2026-09-23 20:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 20:58 [PATCH v3 0/2] drm/mipi-dbi: display a cropped region of an oversized framebuffer Jonathan Frazin
2026-09-23 20:58 ` Jonathan Frazin [this message]
2026-09-23 20:58 ` [PATCH v3 2/2] drm/tiny: allow a framebuffer larger than the panel on MIPI DBI drivers Jonathan Frazin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923205835.3505-2-frazinjonathan@gmail.com \
--to=frazinjonathan@gmail.com \
--cc=airlied@gmail.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kamlesh.gurudasani@gmail.com \
--cc=lanzano.alex@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=phil@raspberrypi.com \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®