Device power save mechanism

1. Device power save applicable cases

The power save feature allows the host to put the WFx in sleep state when the application does not require the Wi-Fi network co-processor to be active. The WFx sleep mode can take place in several conditions:

  • The WFx is initialized (e.g. the firmware has been loaded) and is in idle state (neither in station nor in access point mode).
  • The WFx is connected and the power management mode is different than WFM_PM_MODE_ACTIVE. The power management mode can be changed once connected to an access point using the FMAC API sl_wfx_set_power_mode() .

In opposite, the WFx cannot go to sleep mode in the following cases:

  • The WFx is not initialized.
  • The WFx is acting as an access point.
  • The WFx is connected and the power management mode is left to the default value (e.g. WFM_PM_MODE_ACTIVE).

2. Device power save APIs

The FMAC driver exposes two APIs to handle the device power save mechanism of the WFx chip:

When the device power save is active, the FMAC driver drives the wake-up GPIO through the sl_wfx_host_set_wake_up_pin() API (implemented by the host). Once the wake-up pin is low, the WFx is allowed to go to sleep mode. There are two events which trigger a WFx wake-up:

  • The host sets the wake-up pin high.
  • The WFx is connected and wakes up to receive a beacon/DTIM from the access point it is connected to.

With the device power save active, the FMAC driver wakes up the WFx chip if the host sends a request. If the WFx was actually consider asleep by the FMAC driver, the driver calls the API sl_wfx_host_wait_for_wake_up() . This host implemented function has to wait for the WFx to wake up. Two events can validate the WFx is indeed awake:

After one of the two above conditions is met, the sl_wfx_host_wait_for_wake_up() function can return and the FMAC driver sends the request to the WFx.

3. Optimizations while the device power save is active

Note that by design, the FMAC power save feature has an impact on the absolute throughput performances achievable using the FMAC driver . To optimize the throughput performances and the system power consumption to a specific application, the host application can take advantage of the sl_wfx_host_sleep_grant() function called by the FMAC driver. This host implemented function gives the host flexibility on whether or not the WFx can to go to back to sleep mode. The host decision can be based on multiple factors:

  • The parameters of the sl_wfx_host_sleep_grant() function (address, type and length of the message previously sent by the driver)
  • The IP stack information (e.g. pending TCP acks to be received, traffic peak)
  • A specific application information or event
  • A timer value
  • ...

Depending on the decision taken by the host application, the function has to return SL_WIFI_SLEEP_GRANTED to allow the WFx to go to sleep mode or SL_WIFI_SLEEP_NOT_GRANTED to keep the WFx awake. In case of SL_WIFI_SLEEP_NOT_GRANTED being returned, the FMAC driver will not reevaluate the state in which the WFx should be until the next bus communication. If the application considers that the WFx should go to sleep mode before the next FMAC request, the host can call the sample code below once there is no more communication on the bus :

sl_wfx_context-> state |= SL_WFX_SLEEPING;
sl_wfx_host_set_wake_up_pin (0);

After this sample code runs, the WFx is allowed to go back to sleep mode. below is a diagram summarizing the exchanges between the host application, the FMAC driver and the WFx chip when the device power save feature is enabled.

msc_inline_mscgraph_2

Note that the FMAC driver itself already tests few conditions before calling the sl_wfx_host_sleep_grant() function:

  • The first test is to check that the device power save is active in the FMAC driver.
  • The second is to check that there is no more pending TX FMAC request waiting for confirmation.