I tried different kernel versions (mainline 4.4, mainline 4.9, Linux4SAM 3.10, Linux4SAM 3.18, Linux4SAM 4.4) and also "reference" image from http://www.at91.com/linux4sam/bin/view/ ... ekMainPage to make sure it is not our customized firmware or board that is a problem.

Disconnecting LCD from board does not help either (those signals are all just outputs, but still). Severely reducing dotclock frequency (to unusable levels) does however reduce number of errors (but not eliminate??). Using dri/drm instead of fbdev does not help.

Anyone has any idea what might be the problem as the whole thing just doesn't make any sense ? DMA arbitration problem in SoC ? Linux kernel problem ? Something else ?

Can anyone confirm and check on their board with this simple quick&dirty test:

1.connect to your board over ethernet using ssh and do continuous listings:

2.have another connection to board (serial or network) and turn on lcdc (if using fbdev emulation over dri, make sure you enable it (like cat /sys/class/graphics/fb0/modes > /sys/class/graphics/fb0/mode)
Close any application that might be writing to fb.
3.fill video memory with random pixels

Currently we use quick and dirty patch in user application to only use colors that have only one bit enabled per RGB component to avoid severe problems on field, but that heavily restricts application (reduces number of colors from 2^18 to 8^3).

Thanks to anyone spending time to at least try the test (please report findings: if the communication does not get stuck, which kernel are you using?)

I have very similar problem.
Some info: custom board based on sama5d3xek, linux-at91 4.4. Runs 1024x600 lcd and QT5 app using linuxfb(also tried drm). 166MHz system clock, 41MHz pixel clock and DE mode.

In my case the LCD starts to distort and finally enters blanking mode (I can reset it by writing 0 to /sys/class/graphics/fb0/blank). By distortion I mean jumping picture, like timing issue. The easiest way to reproduce this is to copy files from SD card using mass storage gadget and attach device to USB master (wifi dongle is the worst). Slight distortion can be seen under different bus loads. Loading CPU makes no difference. When LCD failing other operations are not effected.

Changing pixel or system clock makes situation worse. Trying to cp file from SD makes LCD go to blank instantly. Our Initial thought was the hw noise problem (we use parallel to LVDS converter) but how the frame buffer device switches to blanking without any feedback? Tried 4.9 kernel, looks a bit better, but distortion still visible.

My best guess this some kind of DMA or video memory problem. Maybe someone has any suggestion what I could try next to debug this problem? Thank you in advance.