[PATCH 07/10] fix-glamo-suspend-resume-dram-and-engines.patch / MP4 engine

[andrzej zaborowski]

On 16/06/2008, Andy Green <andy at openmoko.com> wrote:
>  Somebody in the thread at some point said:
>  | On 16/06/2008, Andy Green <andy at openmoko.com> wrote:
>  |>  The result is no more corruption of display buffer in suspend, it
>  |>  comes back completely clean.
>  |
>  | IIRC previously we thought the corruption was a result of Glamo being
>  | powered down. Now that there's no corruption wouldn't it mean that
>  | video RAM is staying powered up needlessly? (Just wondering)
>
>  It was always staying powered up with the Glamo DRAM in "Deep Powerdown"
>  doing self-refresh.  In fact we can't switch the Glamo off on GTA02.

I see.  Probably a bit wasteful but we always get a chunk of RAM that
survives suspend/resume.

>
>  The differences are around taking care to disable the engines from the
>  clocks before we trash the PLL (which I think made the "lines" type
>  corruption) and reordering the steps to manage the memory private states
>  with selfrefresh and deep powerdown also before we kill the PLLs, which
>  removed the "noise" type corruption.
>
>  Hey while you're here well done about your MP4 / Glamo work stitching
>  the Harald / Olv stuff actually into mplayer.  I saw you had a little
>  trouble with the engine held in reset, it seems we should export
>  something that lets you do bring the engine up in the kernel, what do
>  you think?

We should export various things, if not everything we do on Glamo.
Currently the 2D engine is used at the same time by X and by mplayer
and in the future might be used by Linux fb for scrolling so we get
races - maybe we should have get_ / put_ style locking through
ioctl's, but then only one of the three can use 2D stuff.  So better
would be moving all of the 2D and other operations into kernel,
unfortunately there doesn't seem to exist a standard set of ioctl's
for that.  Also, the other hw drivers in mplayer seem to do the same
thing we do and not care about race conditions.  I'll see about moving
parts to kernel after the exams hounding me now.

One thing that needs to be in the kernel anyway because it can't be in
userspace, is copying data to VRAM with s3c2442's DMA.  I hear there's
a big overhead setting up DMA channels but I guess at some amount of
data there starts to be a benefit from employing it.

Funny observation, before the patch in my post to un-reset the MPEG
engine, the first read access to any MPEG register killed the CPU
dead.  So dead it didn't respond to JTAG anymore (everything would
time out when trying to use ocd).  But writes didn't do anything.

Cheers