[gta04] Meeting minutes for GTA04 discussion 20080411

[Andy Green]

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

Somebody in the thread at some point said:

|> It's not really the point.  This high current "transmission" mode is
|> something the phone only does for a relatively short time if you think
|> about what the phone is doing from one battery charge to the next.
|
| Sure. What I meant was during a call. E.g., if we have to watch, say,
| USB for some unsolicited status updates, we're better off with the
| CPU doing it in crawl mode than the MPU somehow trying to figure out
| what's happening and then kicking the CPU. Might be similar even for
| UART as well.

Yeah we are better off if it gets that involved, I don't think it is
that involved for normal case he picks up standard phone and calls out.

What I would like to see is SLEEP is the default when backlight goes
down, but we watch what sockets or device nodes are open and infer from
that we must not SLEEP.  If we didn't SLEEP, cpufreq is also running and
it will kick in according to its usual rules and crank us RIGHT down,
again by default.  In this way we didn't make a mess for ourselves but
we get the most aggressive powersaving possible according to the situation.

|> In addition, our core design may find itself deployed in very different
|> scenarios, the call goes out via bluetooth or Wifi or morse-protocol LED
|> and the current from the CPU is not at all lost in the general
|> light-dimming drain.
|
| Yup, we'll have to look into these scenarios to make sure the MPU
| can cope with those it needs to deal with. I could imagine that at
| least WLAN may be a bit on the tricky side.

Yes if we're pushing packets around the CPU will have to be up if very
slowly and backlight off.  There's not much else possible because even
STOP mode gates the peripheral clocks, and we need ongoing DMA on SDIO
and to Codec in and out.

|> We need by default to assume and allow for the CPU in SLEEP randomly,
|
| Yeah, the more it sleeps, the better.
|
|> Wake-on-touch can maybe be done easier than touch gesture recognition...
|
| Hmm, that may work. I guess we'll have to measure how much time it
| actually takes to make some gesture, and how much of it we've lost
| by the time the CPU has finished rubbing the sleep off its eyes.

We would have to give up on seeing the wake gesture if we did this.  The
alternative is to manage TS fully in MSP430 and buffer or assess the
gesture in there too, it's possible but we need to check the ADC is good
enough on the variant that is chosen.

| I think the bottom line is that we have to look into making resume
| really fast, clean out paranoia mdelays/msleeps, wake only the things
| we actually need, etc. Then we have more freedom to chose where and
| how to do these things.

Yeah that is good whatever we do.  If the MSP430 is set up for the
possibility to provide cover for this too, if we need less latency for
whatever reason, we are in a good position either way.

| Yeah, I hope too. Just seems to be designed for phones quite different
| from ours. What really needs a shared memory interface ? Some GPU ?
| Gigabit WLAN ? :-)

Naah, our phone doesn't have those either ;-)

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

iEYEARECAAYFAkgEhfsACgkQOjLpvpq7dMox1wCeMD3m6XEkci93OcOZnp0qKnv9
CowAn0QXWbNKtEbMnHW9+ZHLduAhaVJe
=wiDg
-----END PGP SIGNATURE-----