[gta04] Meeting minutes for GTA04 discussion 20080411

Harald Welte laforge at openmoko.org
Tue Apr 15 07:19:00 CEST 2008


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 <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 mailing list