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.
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.
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.
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.
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>
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.
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.
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.
- 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
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.
