White pixel "noise" corrupts display dynamically after some boots

[andy@…]

Willie explained that occasionally during boot when the display is
initialized, it suffers from white "noise" pixels that obscures the actual
display data and moves around randomly per frame.

This symptom sounds like memory bus bandwidth being used up and the video data
is not able to keep the display pixel pipeline full all the time. If he
manages to get a boot that exhibits this behaviour, it seems to persist for
the whole boot.

He reports seeing it something like once a day, but of course he reboots a
lot.

If it is due to starvation of the video pipeline then it's interesting that it
only happens sometimes. Maybe init of SDRAM timings or video chip timings is
not 100% reliable.

[andy@…]

Reassigned to willie, it's not a physical screen issue

[andy@…]

Willie found #1017 which sounds very similar in terms of unreliable IO between
the CPU and the display controller... going to try their U-Boot patch.

[andy@…]

Before we got to try the patch I experienced the problem here. I noticed that
when it is corrupting pixels, there is a "hum bar" kind of effect vertically
which somehow alters the colours of pixels in vertical ranks slowly, over a
couple of seconds in a vertical sweep. The pixels are rewritten behind
this "wave front" so the display is still pretty legible.

I also noticed some kind of interlace or interleave is visible making the
pixels "twinkle" where they differ between the two lines.

I wondered immediately if the problem was a slow pixel clock, and the "hum
bar" in that case was the capacitive decay of the TFT gate level over time.
Sure enough when Willie got a 'scope, we measured PCLK in the bad mode and
afterwards in the good mode: ~1.7MHz vs ~24.5MHz or ~15 times slower when it
is bad. So it seems likely this is to do with PLL settings or issue with wait
for lock.

[andy@…]

Roh asked to check 32kHz clock next time problem was seen -- is still a clean 32kHz.

In addition I have seen it start the kernel boot display clean, and then enter
this "slow" mode partway through the kernel boot, while it is showing jffs2
messages.

[andy@…]

Workaround for failed video init

[laforge@…]

as indicated by olv, this might have been solved by the patch to u-boot from
#1017. Can somebody please verify that the patch attached to this bug is still
required with that fix?

[andy]

Nobody has reported this for 6 months since cranking up the waitstates to access the Glamo.