Ticket #81 (closed defect: fixed)
Decide how PMU RTC alarm interrupt is signalled to userspace
| Reported by: | laforge@… | Owned by: | werner |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | kernel | Version: | current svn head |
| Severity: | major | Keywords: | |
| Cc: | buglog@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | no | PatchReviewResult: | |
| Reproducible: |
Description
Change History
comment:4 Changed 6 years ago by laforge@…
This is done via a "boot_reason" argument, which will be implemented in u-boot soon.
comment:6 Changed 6 years ago by laforge@…
- Owner changed from laforge@… to werner@…
There already is an environment variable that gets initialized with the first
read of OOCS (or was it INT1) register of the PMU.
We somehow need to pass this variable either as boot parameter to the kernel (if
the alarm is actually waking us up from power off mode).
If we're resuming from power off, then the PMU wakeup reason should not be read,
and the kernel PCF50606 driver should receive the ALARM interrupt.
This needs to be implemented and verified.
comment:9 Changed 4 years ago by andy
- Status changed from new to closed
- HasPatchForReview unset
- Resolution set to fixed
On wake you can figure out the wake source generally from here:
# cat /sys/bus/platform/devices/neo1973-resume.0/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
and in the event of it being the PMU interrupt, which is the case for RTC alarm, you can get more info from here:
# cat /sys/class/i2c-adapter/i2c-0/0-0073/resume_reason
4000000000
That bit shown above should be set on RTC alarm wake.
