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

[Andy Green]

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

Somebody in the thread at some point said:

|>  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.

OK I leave it to you.

| 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.

Hm well ---->

| 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.

Glamo has an (IMO illegally) privileged position on the bus that it
controls main memory bus nWAIT back to CPU.  It means that if you asked
for data from Glamo, or you fill its write FIFO if it has one, and it
considers itself "busy" for internal RAM arbitration reasons, or unable
to comply (because the engine is held in reset and / or the engine HOST
register footprint is disabled maybe in your case) it will just jam down
nWAIT back to CPU how it likes.  That basically disables the external
memory bus, although the CPU should be able to go on with what it has in
caches for a while.

The kicker is that the Glamo internal RAM arbitration system is quite
coarse grained, things acquire the Glamo RAM for a chunk of time if you
gain it at all.  So if other internal things are using the internal RAM
and you are doing bus activity to Glamo, it will be normal AFAICT to
basically stall the processor for chunks of time each "first access for
a while" with high probability (and stall sequential accesses with lower
probability).

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

iEYEARECAAYFAkhWWkgACgkQOjLpvpq7dMqohwCfX35L31MXl+G/qMDL1MGUhORY
0CoAn39D2xABgpflFpN9eR4QYvnurHyv
=6YeM
-----END PGP SIGNATURE-----