Ticket #2324 (new defect)
resume_reason can show EINT01_GSM even if GSM is off
| Reported by: | lindi | Owned by: | openmoko-kernel |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | kernel | Version: | unspecified |
| Severity: | normal | Keywords: | resume_reason GSM |
| Cc: | Blocked By: | ||
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | no | PatchReviewResult: | |
| Reproducible: | always |
Description
Steps to reproduce:
1) receive a call while the phone is in suspend
2) stop GSM
3) suspend the phone
4) press power button
5) check /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-resume.0/resume_reason for resume reason
Expected results:
5) resume reason is only EINT09_PMU
Actual results:
5) both GSM and PMU are shown as a resume reason:
EINT00_ACCEL1 * EINT01_GSM EINT02_BLUETOOTH EINT03_DEBUGBRD EINT04_JACK EINT05_WLAN EINT06_AUXKEY EINT07_HOLDKEY EINT08_ACCEL2 * EINT09_PMU EINT10_NULL EINT11_NULL EINT12_GLAMO EINT13_NULL EINT14_NULL EINT15_NULL
More info:
1) linux andy-tracking a3587e4ed77974ad
2) Qi 9ef7754b8243457c
3) the problem does not appear unless the GSM has woken the system up at least once
4) I read some source code and was able to figure out:
4.1) drivers/misc/neo1973_pm_resume_reason.c reads resume reason from gstatus4 at 0x560000BC
4.2) Qi has written to this address the contents of SRCPND at 0x4A000000
I mmap()'d SRCPND via /dev/mem and it seems to contain the bytes
0c 20 00 00. (I have no idea if simple mmap() is actually able to read this correctly.)
5) If I execute steps 3 - 5 again GSM is not shown as a resume reason anymore.

I was bit unclear in how I stop the GSM. I just killed gsm0710muxd and ogsmd and then checked that /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gsm.0/power_on had a zero in it.