andy git 06/15 suspend/resume observations

[Sean McNeil]

I have unsolicited signal quality messages coming in and I'm 99% sure 
that is what wakes up my device. I get them fairly often even when it is 
just sitting on the table. No walking around required for me (which is 
good because I am pretty lazy).

Joerg Reisenweber wrote:
> Am Mi  18. Juni 2008 schrieb Andy Green:
>   
>> Somebody in the thread at some point said:
>> | Andy,
>> |
>> | I've now confirmed it is from GSM wakeup. If I do not initialize the GSM
>> | then the phone never locks up.
>>
>> EXCELLENT, thanks a lot.
>>
>> Mike can this plug into the serial resume problems?
>>
>> How can one provoke GSM wakes then?  Although I am in runlevel 3 I do
>>     
>
>   
>>>> Unexpected wake from suspend can be provoked by carrying around the
>>>> device, *only* IF registered to GSM. So to me it's very clear some msg
>>>> from GSM (probably associated to cell reselect or signal quality) is a
>>>> source for unexpected wake. (OM-sw)
>>>>
>>>> /j
>>>>         
>
> Hmm, seems you don't read my posts :-/
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: andy git 06/15 suspend/resume observations
> From:
> Joerg Reisenweber <joerg at openmoko.org>
> Date:
> Tue, 17 Jun 2008 12:34:35 +0200
> To:
> openmoko-kernel at lists.openmoko.org
>
> To:
> openmoko-kernel at lists.openmoko.org
>
>
> Am Di  17. Juni 2008 schrieb Andy Green:
>   
>> Somebody in the thread at some point said:
>>
>> | Yes, I only get the pop now on resume.
>>
>> OK Great looks like we are working on the right issue.
>>
>> |> BTW Mark... we use the sideband path for voice data... no *ALSA* device
>> |> is opened during that time, but we could do with 50K source impedence to
>> |> Vref not 500K which happens shortly after you close an alsa device.  How
>> |> do you think we should come at that?  Keep 50K up while there is any
>> |> active analogue routing path open?  Or a new ALSA switch, or something
>> |> else?
>> |
>> | In my application, I always have an *ALSA* device open when in a call. I
>> | open different pseudo devices depending on the mode (normal with
>> | speaker, normal in a call, speaker out in a call, headphone stuff, etc).
>>
>> Yes I don't think it makes any trouble here, it's just that solid Vref
>> is still needed even if you are only using, say, a Mic input on an
>> analogue path and not involving the CPU or Alsa at all.  It seemed like
>> the driver currently believes it only has to maintain lower stability
>> Vref if the CPU / PCM interface is not up, but that isn't true in the
>> default rootfs case anyway.
>>
>> | I'll try to see if I can get it to happen with headphone jack. I can
>> | also try disabling the radio interface to see if it will hang without a
>> | GSM wakeup. Also keep in mind there is a long period of being in suspend
>> | before an attempted resume. Make sure you give it 10 minutes or more
>> | between suspend/resume.
>>
>> Wah I never really give it 10 minutes :-(  OK.  But this is going to be
>> frustration hell.
>>
>> I also wonder what it is that counts out the 10 minutes to "know if it
>> should go wrong".  Network timeouts from NFS external host?  The GSM
>> chips are awake and can tell they didn't get talked to for 10 minutes?
>> Waits for BATFULL somehow?  We turned a voltage rail off we shouldn't have?
>>
>> I guess with NFS rootfs you always have USB in during suspend, it might
>> be interesting to see if the problem ever comes with local rootfs and no
>> USB in during suspend.  If you want some tips on SD Card boot you're
>> welcome.
>>     
>
>
> Unexpected wake from suspend can be provoked by carrying around the device, 
> *only* IF registered to GSM. So to me it's very clear some msg from GSM 
> (probably associated to cell reselect or signal quality) is a source for 
> unexpected wake. (OM-sw)
>
> /j
>