[gta04] Meeting minutes for GTA04 discussion 20080411

[Werner Almesberger]

Andy Green wrote:
> ~ - excessive GPIO to CPU.

One issue we ran into a number of times is also that GPIOs can
create sneak current path from battery power through the supposedly
powered-down CPU, and the CPU can use this power also to twitch on
such GPIOs. So it's a good idea to at least connect everything to
the MPU that isn't completely dead when the CPU is.

I wouldn't be too concerned about GPIOs that are only "live" while
the CPU is powered up (running or asleep) though. We have plenty of
GPIOs on the CPU "for free", while running lots of things to the MPU
will make it big.

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.

By the way, I like the idea of MPU and CPU sharing signals, so that
either one can take care of them.

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

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

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.

By the way, I think one of the main challenges will be to find the
courage to actually turn the display off when there's nothing
interesting to show ;-)

For the MPU, my "must do" tasks would be:

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

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

  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.

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

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 :-)

> 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
I want to be sure. Wouldn't be the first time we've been patting our
shoulders for escaping Scylla, just to be swallowed by Charybids a
moment later :-)

- Werner