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 :-/
--- Begin Message ---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
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
signature.asc
Description: This is a digitally signed message part.
