FelipeMdeO opened a new pull request, #20228:
URL: https://github.com/apache/nuttx/pull/20228
## Summary
`/proc/pm/state0` reported a flat 0 s in its SLEEP column on a board that
was demonstrably light-sleeping, because this port never told the PM core
it had slept.
`pm_stats()` (`drivers/power/pm/pm_changestate.c`) splits the time since
the last transition into `dom->wake[state]` or `dom->sleep[state]`
depending on whether the state it's handed is `PM_RESTORE`. `up_idlepm()`
called `esp_pmstandby()` and carried straight on, so every second —
including the ones spent in light sleep — was billed to `wake[]`. The
statistics `CONFIG_PM_PROCFS` advertises were simply never true on this
port.
Fix: issue `pm_changestate(PM_IDLE_DOMAIN, PM_RESTORE)` right after
`esp_pmstandby()` returns. This is the documented way to record the
statistic — it skips the driver prepare/veto phase, notifies drivers of
the restore, and deliberately does not overwrite the domain's state, so
the domain correctly stays in `PM_STANDBY`. Only `PM_STANDBY` needs this:
`PM_SLEEP` is deep sleep and does not return at all (the chip resets), so
there is nothing to attribute on a return path that doesn't exist.
Depends on #20223 ("esp32s3/esp32s3_idle.c: unwedge the PM state machine
after the first wakeup") — that commit is included here too since it has
not merged yet, so the diff currently shows both. Once #20223 merges, this
branch will be rebased onto master and only its own commit will remain.
## Impact
* Is new feature added? No — makes an existing, advertised statistic
(`CONFIG_PM_PROCFS`'s SLEEP column) actually correct.
* Is existing feature changed? No behavior change to sleep/wake logic
itself, only to what gets recorded.
* Impact on hardware? `arch/xtensa/src/esp32s3/esp32s3_idle.c` only.
## Testing
I confirm that changes are verified on local setup and works as intended:
* Build Host: Ubuntu 24.04, x86_64, `xtensa-esp-elf-gcc`.
* Target: Xtensa, Seeed XIAO ESP32-S3 (esp32s3-xiao), `CONFIG_PM=y` +
`CONFIG_PM_PROCFS=y`.
Before the fix, read from a board that had just spent 89 s in
`PM_STANDBY`:
```
DOMAIN0 WAKE SLEEP TOTAL
standby 89s 83% 0s 0% 89s 83%
```
After the fix, corroborated over a 12 h 25 continuous production run:
`/proc/pm/state0` reports figures consistent with the configured
behaviour (93% of wall time asleep). Note this is corroboration from a
different build, not a same-run cross-check — the independent per-sleep
timing measurement used to compute the 93% figure came from log lines
this patch's build doesn't emit. This PR depends on #20223 to be
observable — a board that never reaches `PM_STANDBY` never exercises this
code path.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
