[gta04] Meeting minutes for GTA04 discussion 20080411

[Harald Welte]

On Mon, Apr 14, 2008 at 08:36:53PM +0100, Andy Green wrote:

> | please dont' try to design hardware fixes for something that sounds like
> | a software design or implementaiton problem (polling an UART for data)
>
> Could you elaborate a bit?  Polling the module at all during a call is
> bad news?  If so, what is the better way to find out about other side
> ending the call, etc.

If the other side has ended the call, you should get a DICSONNECT
message or similar.  IIRC you get a CONNECT after the call is
established and some other message when the call is taken down.

Also, if you have the AT%CPI call progress indications on, the call
progress (even the teardown progress) should be reported quite verbose
by unsolicited %CPI responses from the modem.

In any case, if there really is a need: FIC/OM does have the sources of
the AT command parsers inside the GSM firmware.  So additional
indication could most likely added without too much effort.  That would
still be a much cleaner solution than some kind of 'hardware fix'. 

> I'm asking from the point of view to see how to best keep the CPU down
> during the call.

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.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone