components/esp32,spi_flash: update some comments

components/esp32/cpu_start.c

@@ -190,7 +190,6 @@ void IRAM_ATTR user_start_cpu1(void) {
 	    ;
 	}
 	ets_printf("Starting scheduler on APP CPU.\n");
-	// Start the scheduler on APP CPU
 	xPortStartScheduler();
 }
 

components/esp32/include/esp_ipc.h

@@ -25,6 +25,8 @@ typedef void (*esp_ipc_func_t)(void* arg);
  * FreeRTOS provides several APIs which can be used to communicate between
  * different tasks, including tasks running on different CPUs.
  * This module provides additional APIs to run some code on the other CPU.
+ *
+ * These APIs can only be used when FreeRTOS scheduler is running.
  */
 
 
@@ -56,6 +58,7 @@ void esp_ipc_init();
  * @param arg arbitrary argument to be passed into function
  *
  * @return ESP_ERR_INVALID_ARG if cpu_id is invalid
+ *         ESP_ERR_INVALID_STATE if FreeRTOS scheduler is not running
  *         ESP_OK otherwise
  */
 esp_err_t esp_ipc_call(uint32_t cpu_id, esp_ipc_func_t func, void* arg);
@@ -75,6 +78,7 @@ esp_err_t esp_ipc_call(uint32_t cpu_id, esp_ipc_func_t func, void* arg);
  * @param arg arbitrary argument to be passed into function
  *
  * @return ESP_ERR_INVALID_ARG if cpu_id is invalid
+ *         ESP_ERR_INVALID_STATE if FreeRTOS scheduler is not running
  *         ESP_OK otherwise
  */
 esp_err_t esp_ipc_call_blocking(uint32_t cpu_id, esp_ipc_func_t func, void* arg);

components/spi_flash/esp_spi_flash.c

@@ -36,15 +36,14 @@
     the flash operation. In the dual-core setup this is slightly more complicated.
     We need to make sure that the other CPU doesn't run any code from flash.
 
-    SPI flash driver starts two tasks (spi_flash_op_block_task), one pinned to
-    each CPU. Each task is associated with its own semaphore.
 
-    When SPI flash API is called on CPU A (can be PRO or APP), we wake up the task
-    on CPU B by "giving" the semaphore associated with it. Tasks resumes, disables
-    cache on CPU B, and acknowledges that it has taken the semaphore by setting
-    a flag (s_flash_op_can_start). Flash API function running on CPU A waits for
-    this flag to be set. Once the flag is set, it disables cache on CPU A and
-    starts flash operation.
+    When SPI flash API is called on CPU A (can be PRO or APP), we start
+    spi_flash_op_block_func function on CPU B using esp_ipc_call API. This API
+    wakes up high priority task on CPU B and tells it to execute given function,
+    in this case spi_flash_op_block_func. This function disables cache on CPU B and
+    signals that cache is disabled by setting s_flash_op_can_start flag.
+    Then the task on CPU A disables cache as well, and proceeds to execute flash
+    operation.
 
     While flash operation is running, interrupts can still run on CPU B.
     We assume that all interrupt code is placed into RAM.
@@ -52,8 +51,7 @@
     Once flash operation is complete, function on CPU A sets another flag,
     s_flash_op_complete, to let the task on CPU B know that it can re-enable
     cache and release the CPU. Then the function on CPU A re-enables the cache on
-    CPU A as well and returns control to the calling code. Task on CPU B returns
-    to suspended state by "taking" the semaphore.
+    CPU A as well and returns control to the calling code.
 
     Additionally, all API functions are protected with a mutex (s_flash_op_mutex).