nWAITing for Glamo

[Andy Green]

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

Somebody in the thread at some point said:

| we'd be much better off). this was the crux behind the DMA experiment
dodji
| did. the problem was that the DMA was on-soc and memory to memory and
would hold

This test tells you more that the DMA one.  There are two discrete
things going on that make Glamo access slow:

~ - we pace ourselves at the CPU with waitstates to be REALLY slow if we
touch Glamo.  If we don't do that we get unstable communication and
visual artefacts.

~ - the Glamo paces US according to its own private arbitration of the
internal DRAM between us and, eg, the video controller inside Glamo that
is also constantly needing access to same RAM to update the LCM

It's clear both of these are significant because when I reduce the CPU
waitstates things go faster, but the Glamo arbitration blocking is still
there.

| up the cpu in wait states anyway - so you don't win over using the
cpu. it was
| actually worse as you also have dma setup overhead etc. at best it
seemed to
| pull about half the throughput of copying with the cpu, and gained zero

Something funny there then, it shouldn't've been any worse.  If most of
the trouble is coming from Glamo just covering its ears it might not
have made much odds but should only have been the same or faster.

| benefits. :( unfortunately your example (the sliding top-bar) isn't
even the
| best example of cpu waitstates caused by the glamo. i have
manufactured much
| worse artificial ones :) you might want to try scrolling in exposure
as another
| test... :)

Exposure doesn't seem to start on the image I have from today.  Says it
is starting and then nothing.

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

iEYEARECAAYFAkh7XM4ACgkQOjLpvpq7dMrbrQCggkbHzaS5SkwQiDVVv1SfYEMR
J78AnRrxim1vEIAioy3TSss35xzeaojj
=lUPn
-----END PGP SIGNATURE-----