Questions regarding the wakeup interrupt

[Harald Welte]

On Wed, Mar 26, 2008 at 10:15:36PM +0100, Holger Freyther wrote:
> Hey,
> 
> I have started to look into suspend and resume and wonder how the modem wake 
> up is supposed to work in the big plot.
> 
> Current State:
> 	- Enable the modem, enter pin, register with network
> 	- Enable unsolicited messages (signal strength, registration...)
> 	- echo "mem" > /sys/power/state at any point in time
> 
> 	=> the device will wake up shortly afterwards due the modem wakeup interrupt.
> 
> What I would like to know:
> 	- How is the modem wakeup pin supposed to work (what makes the modem do the 
> interrupt, what happens in regard to flow control)?

see my other mail.

> 	- Should the GSM stack disable unsolicited messages before going to sleep?

This entirely depends on what the GSM stack wants, it's a matter of
power-management and/or product specification, I would say.

> 	- This would require the GSM stack to know about suspend/resume, so the 
> command queue could be frozen, the last commit submitted, unsolicited 
> messages disabled... but we do not want to go this way.

I disagree.  Inevitably, the amount of unsolicited messages that the GSM
stack is interested during power-on and suspend is different.

While the phone is not suspended, you e.g. might want to receive details
that show up on the screen immediately (such as changes in Rx signal
strength).  However, when suspended, that information is of no use.
Before suspending, you want to disable that level of detail (while
keeping others, such as loss of network which you want to signal to the
user).  After resume, you want to inquire the current signal strength
(if possible) and re-enable the signal strength solicited messages.

This is at least how I thought of the design earlier.  This, however,
asserts that there is some kind of userspace framework to signalize
"system wants to suspend" kind of messages to gsmd, and which then
triggers the actual suspend via /sys/power/state.

> 	- How to make the modem wakeup pin usable?

That's a good question.  I have verified the logic of the wakeup signal
from the GSM modem together with Sean Chiang something like may last
year.  At least when using electrical probes and/or controlling the pins
by IO read/write to the GPIO registers of the s3c2410, the state engine
inside the GSM firmware seemed to work just according to the spec that I
wrote.

If it doesn't work during actual CPU suspend, then probably the suspend
code doesn't switch the UART RTS/CTS lines to GPIO at a fixed voltage
before suspending.  If it keeps them in UART function mode, they might
be in undefined state and thus the entire high-level logic left
inoperable.


> Ideally:
> 	- The modem would wake us up on incoming call and SMS

It's basically gsmd (or whatever the software is called these days) task
to configure the GSM modem in a way that it only passes those events
that are important while the CPU is suspended.  This is most flexible
and works transparently on top of the regular 07.05/07.07 command set.

The only problem that we have is that the S3C24xx cannot wake up from
suspend when a flow control line changes state, or when a character is
detected on the UART.  This is why the additional GPIO for wakeup was
added to the circuit.

> 	- It will return the last command result (or ERROR)

what do you mean by this?

> 	- It will send the USC for the SMS or call.

The GSM firmware has a buffer for the command channel.  I don't
currently know how deep that is, but it basically buffers the characters
until flow control on the s3c24xx activates 'clear to send'.

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