Commit Graph

13 Commits

Author SHA1 Message Date
Ivan Grokhotkov
0716e65955 pm: prevent entering light sleep again immediately after wakeup
When light sleep is finished on one CPU, it is possible that the other
CPU will enter light sleep again very soon, before interrupts on the
first CPU get a chance to run. To avoid such situation, set a flag
for the other CPU to skip light sleep attempt.
2018-11-05 12:18:29 +08:00
Ivan Grokhotkov
22dd3103bd pm: fix entering light sleep in single core mode
Tickless idle/light sleep procedure had a bug in single core mode.
Consider the flow of events:
1. Idle task runs and calls vApplicationIdleHook
2. This calls esp_vApplicationIdleHook, which calls esp_pm_impl_idle_hook, and pm lock for RTOS on the current core is released.
3. Then esp_vApplicationIdleHook calls esp_pm_impl_waiti, which checks that s_entered_light_sleep[core_id]==false and goes into waiti state.
4. Some interrupt happens, calls esp_pm_impl_isr_hook, which takes pm lock for RTOS. PM state goes back to CPU_FREQ_MAX.
5. Once the interrupt is over, vApplicationIdleHook returns, and Idle task continues to run, finally reaching the call to vApplicationSleep.
6. vApplicationSleep does not enter light sleep, because esp_pm_impl_isr_hook has already changed PM state from IDLE to CPU_FREQ_MAX.

This didn’t happen in dual core mode, because waiti state of one CPU was interrupted by CCOMPARE update interrupt from the other CPU, in which case PM lock for FreeRTOS was not taken.

Fix by inverting the meaning of the flag (for convenience) and only setting it to true when vApplicationSleep actually fails to enter light sleep.
2018-11-05 12:18:29 +08:00
Mahavir Jain
b5c321d981 esp32: fix regression introduced in automatic light sleep pm
Closes: https://github.com/espressif/esp-idf/issues/2459

Signed-off-by: Mahavir Jain <mahavir@espressif.com>
2018-09-26 08:52:15 +05:30
Mahavir Jain
ff81dc16e0 freertos: cleanup tick/idle hook functionality
If CONFIG_FREERTOS_LEGACY_HOOKS is kept enabled then defining
idle/tick hooks will be applications responsibility as was the
case earlier.

Signed-off-by: Mahavir Jain <mahavir@espressif.com>
2018-09-17 17:05:17 +05:30
Ivan Grokhotkov
bec70ce298 esp32: use new CPU frequency setting API 2018-08-21 13:02:46 +08:00
Ivan Grokhotkov
028fbb58e8 freertos,esp32: automatic light sleep support 2018-05-18 03:14:46 +00:00
Ivan Grokhotkov
94014a9a51 pm: handle the case of 2MHz frequency
It is not possible to generate 1 MHz REF_TICK from 2 MHz APB clock
(this is a limitation of REF_TICK divider circuit). Since switching
REF_TICK frequency is something we would like to avoid (to maintain
UART output even with DFS), 2 MHz frequency has been marked as
unsupported.
2018-03-27 11:20:55 +08:00
Ivan Grokhotkov
839c665c92 pm: fix initialisation only done in dual core mode
Introduced in 9377d4ac. Accidentally put the new code block under an
2018-03-27 11:20:54 +08:00
Ivan Grokhotkov
fe5d294f6c pm: handle changes to the PM_MODE_ACTIVE frequency
The issue would manifest itself in cases when switching from PM
configuration like {active=160MHz, idle=80MHz} to {active=80MHz,
idle=80Mhz}. After the configuration was changed, PM logic would
think that current frequency was 80MHz and would not do any further
switching. In fact, frequency was still 160MHz.
2018-03-27 11:20:54 +08:00
Ivan Grokhotkov
1517aeda6c pm: fix calculation of maximum of two frequencies
The old code calculated MAX() of two enum values, but CPU frequency
enum values are not ordered (2MHz goes after 240MHz). This caused
incorrect configuration to be set.
2018-03-27 11:20:53 +08:00
Ivan Grokhotkov
7167ad45ab pm: improve debug output from esp_pm_dump_locks
- separate mode stats from lock stats by an extra comment line
- add CPU frequency column to the mode stats
- don’t print a row for light sleep if light sleep is not enabled
2018-03-20 18:08:19 +08:00
Ivan Grokhotkov
9377d4acd4 pm: fix incorrect configuration at startup
s_cpu_freq_by_mode array was statically initialised with 80MHz CPU
frequency in CPU_MAX and APB_MAX modes, but sdkconfig setting for the
CPU frequency could have been different. For the case of 240MHz CPU
frequency, this would cause a frequency switch between 240MHz and
80MHz to happen, even though such switch is not supported in the fast
path switching functions used by the DFS implementation.

This fixes the issue by moving initialisation into esp_pm_impl_init,
which is called at startup before the first mode switch can happen.

Fixes https://github.com/espressif/esp-idf/issues/1729.
2018-03-20 18:06:58 +08:00
Ivan Grokhotkov
68e1751b78 pm: initial implementation for ESP32 2017-10-18 14:19:16 +08:00