[gta04] Meeting minutes for GTA04 discussion 20080411

[Werner Almesberger]

Andy Green wrote:
> 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.

Oh, I see. Yes, we should leave room also for parts that we don't
plan to use this time but might use in a later product.

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

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

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

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.

> Generally, all buttons too.

Okay.

> 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, that would be good.

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

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

- Werner