Questions regarding the wakeup interrupt
balrogg at gmail.com
Thu Mar 27 18:19:14 CET 2008
ok, so you're asking about how this was "specified" to work. Last I
looked into it there wasn't any kind of specification or plan so I
waited before responding, to see if in the meantime someone had
written one, but it doesn't seem like it. At the time I played with
it, the nearest to it came to a specification was this part written by
Yes, that's for GTA01. The differences with GTA02 is that we now have
the interrupt pin and the firmware changed.
On 27/03/2008, Holger Freyther <zecke at openmoko.org> wrote:
> On Wednesday 26 March 2008 23:16:55 andrzej zaborowski wrote:
> > I'm afraid there is no way around making the GSM stack power-state
> > conscious, because responses sent from the modem while the CPU was
> > asleep confuse the serial logic.
> > Note though that (I think) Sean Chiang can program the modem to drive
> > the interrupt pin exactly how the GSM stack needs it (before shipping
> > obviously), so we're not limited to what logic TI has predicted for
> > it.
> My view on these things are a bit different, I'm interested in mass production
> of GTA02 and want to know what needs to be done to get the software side in
> shape and make them deployable in the factory. So I try to avoid roundtrips
> and such, please keep this in mind when reading this response.
> Okay, so you do not know how it is intended to work. Yes I know we can change
> any software before mass production but that is pretty near and we do not
> have a possibility to update the firmware in the field yet.
> Regarding your serial logic point, I do not know what you mean but I think
> flow control solved that issue? The modem will not send us any data as long
> as we are not ready to receive it. This assumes that the buffer in the modem
> is big enough. And that we do the right thing on suspend.
What I mean is that gsmd has to disable all unsolicited responses from
the modem, using AT commands, before suspending, because:
1. (as you know well) no buffer is big enough,
2. iirc there were problems in the serial driver getting completely
confused by the bulk of buffered data sent all at once on wake-up.
That's why there's no way around disabling the unwanted notifications
> So let me ask again (the ones that specified and implemented it please
> - How is the wakeup handling supposed to work?
> - What is the host expected to do on suspend?
> - When will the modem toggle the GPIO/interrupt line? On any data it has?
> Only on incoming phone calls and sms? only on incoming calls?
One of the comments on bugzilla made by Sean Chiang said that in
firmware version 7 the interrupt line is asserted on incoming calls
and on incoming SMS, and exactly these two events. I don't know how
exact is this information but it's quite easy to check on the hw. So I
suspect you can ignore the level changes on this pin while the CPU is
running, but on suspend you set it to be a wake-up source, and that
should be all. The important part of the whole mechanism will be in
gsmd, making sure that the UART is usable after resume and discarding
the right amount of potential garbage.
Please do not print this email unless absolutely necessary. Spread
More information about the openmoko-devel