Hi Andy. On Mon, Apr 14, 2008 at 10:24:16PM +0100, Andy Green wrote: > | 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.
You can go way deeper in standby, that's why I've enhanced the UART RTS/CTS handshake with the wakeup-capable interrupt. See the old internal bugzilla entry (forgot the number) and lengthy discussions recently on the -kernel or -devel list about the GSM modem wakeup logic. It's also explained in the Wiki. I seriously doubt that you can live without any of that interrupt-generating logic support from the GSM/3G modem firmware. All of the smartphone designs that I've seen have this kind of functionality on some external GPIO/IRQ lines. As I have indicated before, I generally doubt that you can live with any GSM/3G modem where Openmoko is not able to at least do smaller firmware modifications, like the current situation with the TI firmware. Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone
