Commit Graph

21 Commits

Author SHA1 Message Date
Anton Maklakov
afbaf74007 tools: Mass fixing of empty prototypes (for -Wstrict-prototypes) 2019-08-01 16:28:56 +07:00
Sachin Parekh
a190b527ac power_management: port*_CRITICAL vanilla FreeRTOS compliance
Signed-off-by: Sachin Parekh <sachin.parekh@espressif.com>
2019-05-13 16:39:19 +05:30
Ivan Grokhotkov
912c8e31fc Merge branch 'bugfix/pm_isr_exit_lock' into 'master'
pm: prevent interrupt nesting during esp_pm_impl_isr_hook

See merge request idf/esp-idf!4775
2019-04-18 11:16:26 +08:00
Ivan Grokhotkov
d31ee806be pm: prevent interrupt nesting during esp_pm_impl_isr_hook
Follows the approach proposed in https://github.com/espressif/esp-idf/pull/3110,
but masks the interrupts during the entire ISR hook, not only during
leave_idle. Interrupt nesting during update_ccompare may also cause
issues.

Closes https://github.com/espressif/esp-idf/issues/3057
2019-04-17 07:13:52 +00:00
Michael (XIAO Xufeng)
562af8f65e global: move the soc component out of the common list
This MR removes the common dependency from every IDF components to the SOC component.

Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components.
But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components.

In CMAKE, we have two kinds of header visibilities (set by include path visibility):

(Assume component A --(depends on)--> B, B is the current component)

1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B)
2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only)

and we have two kinds of depending ways:

(Assume component A --(depends on)--> B --(depends on)--> C, B is the current component)

1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B)
2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B)

1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default.
2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it.
3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers
4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link)

This is a breaking change. Previous code may depends on the long include chain.
You may need to include the following headers for some files after this commit:

- soc/soc.h
- soc/soc_memory_layout.h
- driver/gpio.h
- esp_sleep.h

The major broken include chain includes:

1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h.
2. ets_sys.h no longer includes soc/soc.h
3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h

some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h

BREAKING CHANGE
2019-04-16 13:21:15 +08:00
morris
a2f07b0806 move common include files from esp32 into esp_common 2019-03-26 11:57:03 +08:00
morris
fcedf442ce move common source files from esp32 to esp_common 2019-03-22 10:35:03 +08:00
morris
956c25dedd move esp32 chip specific includes to esp32/xxx.h 2019-03-18 17:14:05 +08:00
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