[PATCH 0/2] drm/tiny: sharp-memory: fix TX buffer corruption on partial update

[PATCH 0/2] drm/tiny: sharp-memory: fix TX buffer corruption on partial update

[Tobias Johansson]

Users running applications that submit partial framebuffer updates
(such as LVGL with dirty-region tracking) can observe persistent
flickering on the display when using animations.

The flickering is caused by two bugs that corrupt the TX buffer on
partial updates. The first patch fixes incorrect line address
assignment in sharp_memory_set_tx_buffer_addresses(). The second
patch fixes stale data transmission in
sharp_memory_update_display(). Both patches are needed to fully
eliminate the flickering.

Signed-off-by: Tobias Johansson <tobias.johansson@axis.com>
---
Tobias Johansson (2):
      drm/tiny: sharp-memory: fix line address assignment on partial update
      drm/tiny: sharp-memory: avoid transmitting stale TX buffer data

 drivers/gpu/drm/tiny/sharp-memory.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
---
base-commit: ba683f774299d89d17cde03bb1bdb13f3513cd20
change-id: 20260316-flickering-f9df09243d2f

Best regards,
-- 
Tobias Johansson <tobias.johansson@axis.com>

[PATCH 1/2] drm/tiny: sharp-memory: fix line address assignment on partial update

[Tobias Johansson]

When only a subset of lines is dirty, the TX buffer sent to the
panel contains incorrect line addresses, resulting in visible
flickering on the display.

sharp_memory_set_tx_buffer_addresses() iterates from line 0 to the
last damaged line, assigning addresses sequentially from 1. When
only lines 10-20 are dirty, line 10's pixel data is written to the
slot with address 1 instead of address 11, corrupting the address-
to-data mapping.

Fix sharp_memory_set_tx_buffer_addresses() to iterate over only the
damaged line count and offset assigned addresses by the clip start,
so that addresses match the pixel data that follows.

Fixes: b8f9f21716fec ("drm/tiny: Add driver for Sharp Memory LCD")
Signed-off-by: Tobias Johansson <tobias.johansson@axis.com>
---
 drivers/gpu/drm/tiny/sharp-memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/sharp-memory.c b/drivers/gpu/drm/tiny/sharp-memory.c
index cbf69460ebf3..595926ed660e 100644
--- a/drivers/gpu/drm/tiny/sharp-memory.c
+++ b/drivers/gpu/drm/tiny/sharp-memory.c
@@ -120,8 +120,8 @@ static inline void sharp_memory_set_tx_buffer_addresses(u8 *buffer,
 							struct drm_rect clip,
 							u32 pitch)
 {
-	for (u32 line = 0; line < clip.y2; ++line)
-		buffer[line * pitch] = line + 1;
+	for (u32 line = 0; line < drm_rect_height(&clip); ++line)
+		buffer[line * pitch] = clip.y1 + line + 1;
 }
 
 static void sharp_memory_set_tx_buffer_data(u8 *buffer,

-- 
2.43.0

Claude review: drm/tiny: sharp-memory: fix line address assignment on partial update

[Claude Code Review Bot]

Patch Review

**Analysis:** The original code in `sharp_memory_set_tx_buffer_addresses()` was:

```c
for (u32 line = 0; line < clip.y2; ++line)
    buffer[line * pitch] = line + 1;
```

When the dirty region is e.g. lines 10–20 (`clip.y1=10, clip.y2=20`), this iterates 20 times (0..19) and writes addresses 1–20. But the pixel data populated by `sharp_memory_set_tx_buffer_data()` at `&tx_buffer[2]` only covers 10 lines (the dirty height). So the first 10 address slots (addresses 1–10) have no valid pixel data behind them, and addresses 11–20 point to the wrong pixel data positions in the buffer.

The fix correctly:
1. Iterates only `drm_rect_height(&clip)` times (10 lines, not `clip.y2`)
2. Assigns addresses starting from `clip.y1 + 1` (11), matching the 1-based line addressing the panel expects

```c
for (u32 line = 0; line < drm_rect_height(&clip); ++line)
    buffer[line * pitch] = clip.y1 + line + 1;
```

**No issues.** Correct fix, good commit message with proper Fixes tag.

---

---
Generated by Claude Code Patch Reviewer

[PATCH 2/2] drm/tiny: sharp-memory: avoid transmitting stale TX buffer data

[Tobias Johansson]

When only a subset of lines is dirty, the TX buffer sent to the
panel contains stale line data from previous updates, resulting
in visible flickering on the display.

sharp_memory_update_display() transmits the entire TX buffer
regardless of how many lines were updated. Entries written by a
previous larger update linger in the buffer and
are retransmitted on every subsequent smaller update, overwriting
the newly written data with stale content.

Fix sharp_memory_update_display() to transmit only the buffer
entries populated by the current update.

Fixes: b8f9f21716fec ("drm/tiny: Add driver for Sharp Memory LCD")
Signed-off-by: Tobias Johansson <tobias.johansson@axis.com>
---
 drivers/gpu/drm/tiny/sharp-memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/sharp-memory.c b/drivers/gpu/drm/tiny/sharp-memory.c
index 595926ed660e..e7521fc6a010 100644
--- a/drivers/gpu/drm/tiny/sharp-memory.c
+++ b/drivers/gpu/drm/tiny/sharp-memory.c
@@ -155,7 +155,7 @@ static int sharp_memory_update_display(struct sharp_memory_device *smd,
 	u32 pitch = smd->pitch;
 	u8 vcom = smd->vcom;
 	u8 *tx_buffer = smd->tx_buffer;
-	u32 tx_buffer_size = smd->tx_buffer_size;
+	u32 tx_len = 1 + (drm_rect_height(&clip) * pitch);
 
 	mutex_lock(&smd->tx_mutex);
 
@@ -165,7 +165,7 @@ static int sharp_memory_update_display(struct sharp_memory_device *smd,
 	sharp_memory_set_tx_buffer_addresses(&tx_buffer[1], clip, pitch);
 	sharp_memory_set_tx_buffer_data(&tx_buffer[2], fb, vmap, clip, pitch, fmtcnv_state);
 
-	ret = sharp_memory_spi_write(smd->spi, tx_buffer, tx_buffer_size);
+	ret = sharp_memory_spi_write(smd->spi, tx_buffer, tx_len);
 
 	mutex_unlock(&smd->tx_mutex);
 

-- 
2.43.0

Claude review: drm/tiny: sharp-memory: avoid transmitting stale TX buffer data

[Claude Code Review Bot]

Patch Review

**Analysis:** The original code always transmitted the full `smd->tx_buffer_size`:

```c
u32 tx_buffer_size = smd->tx_buffer_size;
// ...
ret = sharp_memory_spi_write(smd->spi, tx_buffer, tx_buffer_size);
```

Since `tx_buffer_size = 1 + pitch * vdisplay` (mode byte + all lines), and the buffer isn't zeroed between updates, a previous full-screen update leaves stale line entries in the buffer. When a subsequent partial update writes only a few lines, the old entries are still sent, causing the panel to overwrite correct content with stale data.

The fix computes the exact transfer length:

```c
u32 tx_len = 1 + (drm_rect_height(&clip) * pitch);
```

This is 1 byte (mode) + dirty_lines × pitch, which is correct. Each line's `pitch` already includes `SHARP_ADDR_PERIOD + hdisplay + SHARP_DUMMY_PERIOD` divided by 8, so the trailing dummy bits for the last transmitted line are included in the transfer, satisfying the Sharp Memory LCD protocol's requirement for a trailing dummy period.

The struct field `smd->tx_buffer_size` remains used for the `devm_kzalloc` allocation in `sharp_memory_probe()` (line 567), so it is not left dangling.

**No issues.** Correct fix, good commit message with proper Fixes tag.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/tiny: sharp-memory: fix TX buffer corruption on partial update

[Claude Code Review Bot]

Overall Series Review

Subject: drm/tiny: sharp-memory: fix TX buffer corruption on partial update
Author: Tobias Johansson <tobias.johansson@axis.com>
Patches: 3
Reviewed: 2026-03-31T17:34:58.629261

---

This is a clean, well-motivated 2-patch bugfix series for the Sharp Memory LCD driver. Both patches fix real bugs in the partial-update (dirty-region) path that cause the TX buffer's address-to-data mapping to be corrupted and stale data to be transmitted. The fixes are minimal, correct, and clearly explained. The series is suitable for stable backport given the Fixes tags.

**Verdict: Good to merge.** No correctness issues found.

---

---
Generated by Claude Code Patch Reviewer