[gta04] Meeting minutes for GTA04 discussion 20080411

[Andy Green]

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

Somebody in the thread at some point said:
| On Mon, Apr 14, 2008 at 08:36:53PM +0100, Andy Green wrote:
|
|> | please dont' try to design hardware fixes for something that sounds
like
|> | a software design or implementaiton problem (polling an UART for data)
|>
|> Could you elaborate a bit?  Polling the module at all during a call is
|> bad news?  If so, what is the better way to find out about other side
|> ending the call, etc.
|
| If the other side has ended the call, you should get a DICSONNECT
| message or similar.  IIRC you get a CONNECT after the call is
| established and some other message when the call is taken down.

OK thanks.  The guys were explaining they poll it for a watchdog type
action IIRC.

|> I'm asking from the point of view to see how to best keep the CPU down
|> during the call.
|
| AFAIK, anything that alters call state would generate some kidn of
| message on the AT command interface, which in turn should wake up the
| CPU.

The issue here is that the best power save results come from modes
Samsung call "STOP", "DEEP STOP", and "SLEEP" mode, in each of these the
PLLs are powered down so there is no peripheral clock to run the UART.
(In fact it looks like we can route EXTCLK to the UARTs even then, but
if that is 32kHz and UART may not be a wake source.)  So it means we can
only go to least saving IDLE powersave level where the PLLs are all up
but only clock to the core is gated.

It'd be interesting to know what the average current is in IDLE vs
SLEEP, where all PLLs and the core are unpowered and RAM is in
selfrefresh.  It's not impossible IDLE still has significant static
consumption.

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

iEYEARECAAYFAkgDy3kACgkQOjLpvpq7dMrCigCcDJ44RifxrLORI7GKnAh69b//
mugAn29ex5A0HJMV8pBdvLkadhd9yPzp
=R6on
-----END PGP SIGNATURE-----