[gta04] Meeting minutes for GTA04 discussion 20080411

[Andy Green]

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

Somebody in the thread at some point said:

| I don't know how much of a conflict we should expect between GPIOs
| and function blocks, but if it's not much worse than in GTA02, I
| wouldn't worry.

No I mean if GPH7 is used for GPS in one design and Bluetooth in
another, we have a mess in the drivers when we make a design that has
GPS and Bluetooth.

|> ~ - smart bootloader ("show charging image for user")
|
| To complete the story, a charger insertion or such should just boot
| Linux, and then we can decide what to do about it there. "Policy"
| (i.e., decide how to respond to a situation) is best done in user
| space or at least as close to it as possible.

Absolutely.

|> ~ - CPU go to lower frequency.  I think we will find there is a big
|> difference in power consumption between lower frequency operation and
|> SLEEP mode in S3C6400.
|
| I think we should consider what the system consumes as a whole when in
| a particular state. If the modem is pumping out data at 7W a pop, 50%
| duty cycle, saving some 100mW in the CPU will scarcely matter.

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.

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.

We need by default to assume and allow for the CPU in SLEEP randomly, if
it finds itself doing something that it can't sleep on then we either
infer that from open sockets / device nodes or userspace has to signal
it as a special exception.

| Keeping the CPU as off as possible is certainly a good idea, but we
| should give things that smell too much like "heroic effort" a wide
| berth.

What we need to try to figure a way around is things that block us from
randomly suspending the CPU, unless it is truly needed that the CPU is up.

| - PMU bringup and care and feeding. We had no end of pain with this in
|   all our designs so far, with lots of guesswork with what we'd be able
|   to get away with, since the PMU just didn't give us exactly what we
|   need. This has to end, and I see the MPU as precisely the hero in
|   shining armor to slay that particular monster for us.

Great, it can do this easily.

| - anything that hammers the CPU too often to let it sleep when it could.
|   Corollary: anything that's not just a single bit signal and can wake
|   the CPU.

OK

|   Right now, that would be the acceleration sensors and possibly also
|   HDQ. If we want gesture recognition on the touch screen, that one
|   would also have to be part of it.

OK - HDQ is a must, one of the things we can do in production is measure
and report true suspend current using the MPU and HDQ from the device
itself.

Wake-on-touch can maybe be done easier than touch gesture recognition...
the ADCs in some of the MSP430 might not be that great.  Nobody defined
this as needed yet although I think it can be interesting.

| - anything that needs taking care of when the CPU is completely powered
|   down or in the middle of reset. An example for this would be the USB
|   pull-up. There's more stuff of the same kind hanging off PMU GP(I)Os.

Yeah but maybe consider resume period in that as well as we discussed
before.  We don't really know what that period will be yet.

| For the rest, I think we should look for low-hanging fruits, and avoid
| the temptingly juicy ones on the top branches. In fact getting the above
| list right should already be enough for anyone to be proud of :-)

Generally, all buttons too.  If we have I2C to PMU, I2C can be
multimaster in a neat way, maybe it can share an I2C bus to codec and
allow that possibility too from CPU and MPU.

|> Yes me either.  This is resolved for us anyway we got one choice in the
|> end apparently.  Using non-MCP and separate DDR is disallowed on space
|> grounds.
|
| So it seems ... I'm still not entirely convinced about that OneDRAM,
| though. I hope that wasting 16MB is the worst it will do to us, but

Well, they make these things for mobile phones.  I guess it will work out.

- -Andy

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

iEYEARECAAYFAkgEcZUACgkQOjLpvpq7dMqr8QCdEJwEUbZ0PffbWmHxAHS6BF19
wxwAoI03gcViNDNxzccNGNdNYnu4QrgB
=aJL6
-----END PGP SIGNATURE-----