gta02 framebuffer decay on suspend

Sean McNeil sean at mcneil.com
Sat May 31 22:14:49 CEST 2008


Andy Green wrote:
> Somebody in the thread at some point said:
> | Andy Green wrote:
> |> Somebody in the thread at some point said:
> |>
> |> | The longer I have a gta02 suspended to ram, the more decay I see 
> in the
> |> | framebuffer when I resume. Is there a way to force a refresh of 
> this in
> |> | hardware registers or at the device layer? Is this the glamo or 
> the 410
> |> | framebuffer?
> |>
> |> This is Glamo internal memory not getting refresh.
> |>
> |> On resume, X should redraw; for true framebuffer nobody takes
> |> responsibility for it.  We can dump the framebuffer to CPU RAM in
> |> suspend and spam it back on resume, but it will delay both actions.
> |>
> |> -Andy
> | I'm not using X. I'm using something else. So it must be the glamo with
> | video RAM from our comment as it looked like the 410 used ram for the
> | framebuffer already.
>
> What is it you mean by "410" here?  The GTA02 has s3c2442.
Yes, I understand. There is some confusion in the kernel, however, as 
the GTA02 seems to use several devices and things from the GTA01 that 
reference s3c2410. At one point, I think I couldn't even run the kernel 
unless I specified gta01 support. I wasn't sure if the s3c2410 
framebuffer was reused of if the glamo completely supersedes it. The 
fact that the glamo has video memory made it obvious to me and explained 
the decay.
>
> Yes if nothing understands it needs to render the framebuffer contents
> again after resume, you will see random decayed crap from internal Glamo
> memory that has not been refreshed.
>
> It's best that on resume you invalidate the whole graphical region and
> provoke a fresh redraw from whatever is responsible for framebuffer
> contents.
>
> -Andy
>
Thanks Andy. I will work on adding full screen refresh on resume to the 
video handler.

Sean





More information about the openmoko-kernel mailing list