[gta04] Meeting minutes for GTA04 discussion 20080411
laforge at openmoko.org
Tue Apr 15 07:19:00 CEST 2008
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
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.
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-kernel