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 <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone