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

andrzej zaborowski balrogg at gmail.com
Thu Jun 5 00:58:28 CEST 2008

On 04/06/2008, Andy Green <andy at openmoko.com> wrote:
>  Somebody in the thread at some point said:
>  | Wow screen fade to white must mean no pixel clock came any more, so when
>  | it blew up, it blew up really well.
>  |
>  | If you're ever interested to poke on it some more, the way forward would
>  | be to dump the Glamo LCD regs before and after the "whiteout" so we can
>  | see what is getting overwritten.  I had some nice code for that but I
>  | seem to have mislaid the patch, I'll look a bit more for it.

Oh, I hadn't thought about that.

>  It's enabled on the andy tree already, it's in glamo-core.c.  You can
>  get an LCD region register dump like this:

Thanks, I've just booted up a couple of times and here's what could be
seen from the dump:

 * after it dies the registers keep their values, but writes are
ignored (it seems), but VRAM still works as normal, i.e. can be
written with new values.
 * there are four 16bit status registers starting at 0x1180 that
constantly change values while Glamo lives and stop moving after the
blow up.  The first register has normally bit 15 set (meaning
CMD-queue empty (?)) and when Glamo dies it's cleared.  The second
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.

I'll have some more play another day.


More information about the openmoko-kernel mailing list