[PATCH] SMedia-Glamo-fb hardware cursor and fixes.

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| blow up.  The first register has normally bit 15 set (meaning
| CMD-queue empty (?)) and when Glamo dies it's cleared.  The second

Command queue is some kind of mode thing for Glamo, we had trouble with
it before and I put locking around the stuff that uses it, trouble went
away.  I see you are using the lock (unfortunately :-) ).

| register seems to be the number of the line currently transferred by
| the DMA to LCD.  It's always 0x273 after death. 0x273 is the top row
| of the last line of text in console, where the cursor is usually. The
| next two registers are CRC count, it's interesting because the last
| register (at 0x1186) contains some kind of checksum of everything in
| the framebuffer, meaning that its value only changes when something
| changes on the screen, I wonder if it can be used for something.
|  * all the other registers have their usual values.
|  * the death is related directly to the number of cursor changes since
| bootup (not frequency) it seems.

If I understood it the hw cursor is coming in on an interrupt, I would
suspect a probability based problem where we blow up depending on what
the foreground was in the middle of when we came in.  But if it is a
fixed number of cursor actions that doesn't fit.

Also, these are just the LCD engine regs shown by default.  The kind of
issue you are seeing can be caused by crapping on the "General" set too,
which has the clock generation stuff, so worth a look there.

| I'll have some more play another day.

OK, appreciated.  This is more useful than it might appear because there
is at least one probability-based problem with Glamo addressing
corruption that is not understood.  Currently it is worked around by
maxxing out the waitstates to the Glamo which reduces its probability to
"I didn't see it lately".  But being able to not have to max out the
waitstates to the Glamo if we ever did understand the issue has "obvious
advantages".

If you have another attack on it, I would start by #if 0 -ing out chunks
of the hw cursor function and see if there is a point where removing
something specific (even if you can't see the cursor move any more)
stops the bad behaviour, then it can mayb make a clue.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhHmOEACgkQOjLpvpq7dMpymACgkHMxwVsnfpaS6kG2a1P+kFte
6QwAnRjoW5q2etblLQtVMy89xLLv0oxJ
=EmCJ
-----END PGP SIGNATURE-----