Hi
Am 13.08.26 um 06:27 schrieb Fabio Piparo:
The symptom
===========
I am working with a Raspberry Pi 5 driving a 128x32 SSD1306 over I2C
through ssd130x, brought up with dtoverlay=ssd1306, and a GLES client
rendering into it. The GPU renders straight into the panel's framebuffer.
The panel shows a blocky pattern that is affected by CPU load. The kernel
is 6.18.39.
A capture:
https://files.fabiopiparo.com/ssd130-line-glitch.webp
This is a simple trail traveling left to right, and the busier the Pi is,
the shorter the trail (link above). On an idle machine the leftovers build
up into a blocky fog. That was the clue that pointed me at the CPU cache,
since the lifetime of the artifact tracks memory pressure.
The trace
=========
I made a test program that flips between two alternating solid frames
while i2c_write payloads are traced. 15 of the 31 flushes carry bytes
from both frames in one payload, mixed at 64 byte granularity.
I assume you write these frames quickly one after the other? As i2c is
really slow, you might write to buffers that are still being transferred
in the background.
Do you read back the status of the page flips? DRM should tell you when
it has completed transferring a frame. See [1]
[1]
https://elixir.bootlin.com/linux/v7.2.5/source/drivers/gpu/drm/drm_file.c#L85
Best regards
Thomas
What appears to happen
======================
My reading: the driver's XRGB conversion reads the framebuffer through a
cached mapping while the GPU writes the same memory directly, so what
reaches the panel is whatever lines the CPU still holds. The 64 byte
granularity and the load dependence both fit that, and write-combining
the mapping makes it stop.
What stops it
=============
Setting shmem->map_wc in a .gem_create_object hook makes all the traced
payloads come out as expected.
Whether the exporter is the right place for this, I do not know.
I am happy to test anything on this hardware and report back.
Disclosure
==========
The panel, the symptom and the i2c trace come from my own hardware. The
analysis above and the change came out of a long debugging session with
an AI assistant.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
