[Openchrome-devel] accel with VX855 causes screen flicker

[Daniel Drake]

On Wed, 2009-06-24 at 12:05 +0100, Daniel Drake wrote:
> I find this issue surprising, because both of these codepaths involve
> calling viaAccelCopyHelper(). This function seems to behave very
> similarly for all supported hardware, and is also called in other
> acceleration paths. It seems unlikely that the real bug is in this
> function, since there don't seem to be other reports of this issue.
> 
> Any thoughts on how we can continue investigating this issue?

I dug deeper.

viaFlushPCI() has this code:

                offset = (*bp++ & 0x0FFFFFFF) << 2;
                value = *bp++;
                VIASETREG(offset, value);

It is that VIASETREG call that causes the flicker.
I confirmed this with gdb breakpoints. That is, I put breakpoints here:

	offset = (*bp++ & 0x0FFFFFFF) << 2;
	value = *bp++;
	// breakpoint 1
	VIASETREG(offset, value);
	// breakpoint 2

Breakpoint 1 triggers and I respond with "c".
The screen flickers, temporarily with one area of the screen in
dislodged state. The screen then returns to it's "good" un-dislodged
state. *Then* breakpoint 2 triggers.

This is interesting as a single register write caused both the
dislodging of the screen *and* the correction, returning back to normal.


Also, *most* of the time when that particular line of code executes,
there is no flicker. I needed a lot of patience to track it down to
there.


I also investigated exactly which register write causes the flicker
(i.e. the values of "offset" and "value" above). It always seems to be
offset=0x0 and value=0xf0002001

My decoding of these: it's writing to the GECMD register, a value of:
GEC_BLT | GEC_FIXCOLOUR_PAT with the high byte set as 0xf0 thanks to
VIAACCELPATTERNROP().


I now adjusted my breakpoints so that they would only trigger before and
after a write of this specific (offset, value) pair. I discovered that
this particular register write does not *always* cause the flicker, it
is perhaps 1 in 3 times.

This VIASETREG call is made in a loop, it looks like GECMD is the last
register written as part of a "transaction." So I logged some of the
other registers written leading up to that.

Here are some register write sequences which caused the flicker (all
values in hex):

setreg 48=0
setreg 4=300
setreg 14=7daf0
setreg 8=2580000
setreg 10=4b
setreg c=2903ce
setreg 58=282828
setreg 0=f0002001

setreg 4=300
setreg 14=afc8
setreg 8=2580000
setreg 10=2a
setreg c=2ed0001
setreg 58=282828
setreg 0=f0002001

setreg 48=0
setreg 4=300
setreg 14=7f008
setreg 8=2580000
setreg 10=4b
setreg c=2003ce
setreg 58=282828
setreg 0=f0002001


Here are some register write sequences, involving the same f0002001
GECMD, but which did not cause a flicker (or at least I did not see one,
there is a chance that there was a smaller flicker that I did not
perceive):

setreg 4=300
setreg 14=78d98
setreg 8=2580000
setreg 10=0
setreg c=4a002b
setreg 58=282828
setreg 0=f0002001

setreg 48=0
setreg 4=300
setreg 14=afc8
setreg 8=2580000
setreg 10=0
setreg c=2ed0029
setreg 58=282828
setreg 0=f0002001

setreg 4=300
setreg 14=78d98
setreg 8=2580000
setreg 10=484
setreg c=4a002b
setreg 58=282828
setreg 0=f0002001


Does this mean anything to anyone?

I think this suggests a hardware bug. Does anyone agree/disagree with
that conclusion at least?

Thanks,
Daniel