Color patterns on LCD disturb ETH or USB

[johanc]

Hi !

I encountered very weird issue (also easy repeatable on demo SAMA5D3x-MB board, ATSAMA5D31 SoC):

Writing some patterns in "video" memory (and having LCDC enabled) causes packet errors (CRC, bad signals) on USB on our custom board, but when tried on demo board, they cause packet stalls?? on ethernet.

These errors do not occur when pixels only have 1 bit per RGB component changing or all pixels are of the same color.

e.g.:
BGR = 0x808080, 0x020202, ... pattern does not produce errors, neither does 0xFFFFFF, 0xFFFFFF, ...
however BGR = 0xFFFFFF, 0x000000, ... produces errors

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:

Code: Select all

while true; do dmesg; done

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

Code: Select all

 cat /dev/urandom > /dev/fb0 

4.observe listings on ssh connection -> stalling
5.fill video memory with black pixels

Code: Select all

 cat /dev/zero > /dev/fb0 

6.observe listings on ssh connection: smooth again

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?)

Best regards

[blue_z]

Cannot replicate any problem on a SAMA5D36-EK, running
Linux buildroot 3.10.60+at91 or
Linux sama5d3xek 4.1.0-linux4sam_5.2-00025-g1028912

Regards

[justas]

Hi,

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.

[justas]

Investigated some more. Lowering pixel clock to eye visible levels solves this problems. Also with higher lines count USB starts to fail. Seems like memory isn't fast enough and LCDC don't have the highest priority.