The LCDIF controller expects framebuffer pitch to be aligned to a
64 byte boundary for reliable scanout. While byte-granular pitches are
supported by the interface, the i.MX8MP reference manual
recommends 64-byte alignment for optimal operation.

Corrupted output was observed with XR24 framebuffers where a pitch of
4320 bytes caused visible corruption and choppy display, while an aligned
pitch of 4352 bytes worked correctly.

Ensure that only framebuffers with properly aligned pitch are accepted
by rejecting invalid configurations in lcdif_plane_atomic_check().
This allows userspace to fall back to a compatible allocation.

Signed-off-by: Advait Dhamorikar <advaitd@mechasystems.com>
---
 drivers/gpu/drm/mxsfb/lcdif_kms.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 72eb0de46b54..8e574e9a591a 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
@@ -674,6 +674,18 @@ static int lcdif_plane_atomic_check(struct drm_plane *plane,
 	crtc_state = drm_atomic_get_new_crtc_state(state,
 						   &lcdif->crtc);
 
+	/*
+	 * While byte granularity is supported, LCDIF requires
+	 * that framebuffer pitch be aligned to 64 bytes.
+	 */
+	if (plane_state->fb &&
+	    !IS_ALIGNED(plane_state->fb->pitches[0], 64)) {
+		DRM_DEV_DEBUG_DRIVER(plane->dev->dev,
+							"Framebuffer pitch (%u bytes) must be aligned to 64 bytes\n",
+							plane_state->fb->pitches[0]);
+		return -EINVAL;
+	}
+
 	return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
 						   DRM_PLANE_NO_SCALING,
 						   DRM_PLANE_NO_SCALING,
-- 
2.43.0

Hi,

On Mo, 2026-04-13 at 17:14 +0530, Advait Dhamorikar wrote:
> The LCDIF controller expects framebuffer pitch to be aligned to a
> 64 byte boundary for reliable scanout.
>
> While byte-granular pitches are
> supported by the interface, the i.MX8MP reference manual
> recommends 64-byte alignment for optimal operation.
>
> Corrupted output was observed with XR24 framebuffers where a pitch of
> 4320 bytes caused visible corruption and choppy display, while an aligned
> pitch of 4352 bytes worked correctly.

This happens to be divisible by 256, which is is the burst size
currently set in the undocumented CTRLDESCL0_3 register fields,
according to the comment in lcdif_set_mode().

I wonder if setting 4320 bytes stride works if you reduce the burst
size, for example by reverting commit 2215cb3be5c2 ("drm: lcdif: change
burst size to 256B") to test.

If that is the case, it might be better to allow unaligned pitches but
configure the burst size depending on pitch alignment.

regards
Philipp

Hello Philipp,

> I wonder if setting 4320 bytes stride works if you reduce the burst
> size, for example by reverting commit 2215cb3be5c2 ("drm: lcdif: change
> burst size to 256B") to test.

Unfortunately, reverting the commit doesn't seem to fix the issue.
I tested with the reduced/default burst size as well as explicitly
setting it to 128 bytes, but a pitch of 4320 bytes still results in a
corrupted output(stretched and choppy display).

However, using a 64 byte aligned pitch works in all cases without having
to alter the burst size.

Best regards,
Advait

On Mon, Apr 13, 2026 at 7:16 PM Philipp Zabel <p.zabel@pengutronix.de> wrote:
>
> Hi,
>
> On Mo, 2026-04-13 at 17:14 +0530, Advait Dhamorikar wrote:
> > The LCDIF controller expects framebuffer pitch to be aligned to a
> > 64 byte boundary for reliable scanout.
> >
> > While byte-granular pitches are
> > supported by the interface, the i.MX8MP reference manual
> > recommends 64-byte alignment for optimal operation.
> >
> > Corrupted output was observed with XR24 framebuffers where a pitch of
> > 4320 bytes caused visible corruption and choppy display, while an aligned
> > pitch of 4352 bytes worked correctly.
>
> This happens to be divisible by 256, which is is the burst size
> currently set in the undocumented CTRLDESCL0_3 register fields,
> according to the comment in lcdif_set_mode().
>
> I wonder if setting 4320 bytes stride works if you reduce the burst
> size, for example by reverting commit 2215cb3be5c2 ("drm: lcdif: change
> burst size to 256B") to test.
>
> If that is the case, it might be better to allow unaligned pitches but
> configure the burst size depending on pitch alignment.
>
> regards
> Philipp