nWAITing for Glamo

Andy Green andy at openmoko.com
Tue Jul 15 11:39:01 CEST 2008


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

Somebody in the thread at some point said:

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

Carsten are you sure you tested the same thing each time?  It sounds
like the first time you spammed Glamo memory with a constant, so the
memory bus was dedicated to Glamo access actions and the CPU ran from
cache (and had its constant from CPU register).

But when you did DMA, by definition it is a bitblit action where you
both read the bitmap from external RAM and then copy / write it to
Glamo.  Then it makes sense you only find half the throughput since the
external bus experiences twice the traffic, half getting the data from
our DRAM and half writing it to Glamo RAM and it can only do one at a time.

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

iEYEARECAAYFAkh8cDAACgkQOjLpvpq7dMoqLQCfelVRHKCHGY1A714JMpr2kzQ0
qAwAn1q7FbI2kwEPOP2hO651zmGCP3fJ
=F3jA
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list