Zephyr power management issues

RE: Zephyr power management issues

Simonr — Thu, 16 Sep 2021 13:35:12 GMT

2. I got a clarification from one of our developers on this: PM_DEVICE enables device power management from a system perspective. So for example when the system is suspsended, so will the devices be. PM_DEVICE_RUNTIME enables a separate API that drivers can use to implement runtime power management independent of the system state.

He'd also like to add a word of caution, as PM_DEVICE_RUNTIME is missing some features as of yet like dependency management.

3. Thank you for your suggestions. I will indeed forward this to the development team and we'll evaluate it internally.

Best regards,

Simon

RE: Zephyr power management issues

Dmitry Kr — Wed, 15 Sep 2021 10:15:47 GMT

Hi Simonr,

1. OK.

2. Yes, we've implemented. For clarity, could you please suggest:

a) when PM_DEVICE_RUNTIME is enabled, should we turn-off device power on init or turn-on by default? Different device drivers have different implementations, and example (dummy_driver) is disabled (turned off) by default. What's the common approach?

b) when PM_DEVICE_RUNTIME is disabled (and PM_DEVICE) still enabled, should we enable device power by default?

c) at which usecases we should use PM_DEVICE without PM_DEVICE_RUNTIME?

3. Yes, but it isn't turned off when SPI driver goes to suspended state, and this pin provides parasitic power for the sensor, leads to 14 uA consumption in addition.

For the SPI driver, could you please consider the following suggestions to the driver's source?

For spi_context.h:

// @ctmlab added ->

static inline void spi_context_cs_deconfigure(struct spi_context *ctx)

{

if (ctx->config->cs && ctx->config->cs->gpio_dev) {

gpio_pin_configure(ctx->config->cs->gpio_dev,

ctx->config->cs->gpio_pin,

GPIO_DISCONNECTED);

} else {

LOG_INF("CS control inhibited (no GPIO device)");

}

// <-

For spi_nrfx_spim / spim_nrfx_pm_control():

case PM_DEVICE_STATE_LOW_POWER:

case PM_DEVICE_STATE_SUSPEND:

case PM_DEVICE_STATE_OFF:

if (data->pm_state == PM_DEVICE_STATE_ACTIVE) {

nrfx_spim_uninit(&config->spim);

// @ctmlab 2021-09-10 added ->

struct spi_context *ctx = &get_dev_data(dev)->ctx;

spi_context_cs_deconfigure(ctx);

// <-

}

break;

For spi_nrfx_spim / spim_nrfx_pm_control():

RE: Zephyr power management issues

Simonr — Mon, 13 Sep 2021 08:22:19 GMT

1. Yes, in order to add a 'vin-supply' field I'd recommend making a custom implementation of the QSPI driver with this field.

2. That sounds like a good idea if you need to manage the power usage of multiple external devices, as PM_DEVICE_RUNTIME lets devices be suspended/resumed based on device usage.

3. The SPI documentation specifies that a GPIO node is supposed to be used when instantiating a SPI_CS_CONTROL structure.

Thank you for notifying us of the missing bracket. I've reported it internally.

Best regards,

Simon

RE: Zephyr power management issues

Dmitry Kr — Fri, 10 Sep 2021 10:17:37 GMT

Hi Simonr,

We applied the regulator susbystem as well by your recommendation (at another ticket).

The question is not about the regulator module itself (it works fine enough for the moment) still about the proper approach to implement that in the application.

The dummy_driver application shows relatively clear approach about regulator PM chain management (parent - child suspending), and we're going to implement someting like that.

The still active questions are:

1. Basic 'nordic,qspi-nor' driver doesn't have 'vin-supply' field, should we implement our custom driver for NOR flash based on this driver? Or should we manually turn on-off the regulator for flash? Please note there will be logging and perhaps bootloader modules in chain with QSPI driver.

2. Should we consider using PM_DEVICE_RUNTIME functionality and related functions for PM management of external ICs?

3. As of SPI driver, there is an issue with PM function: although it has de-initialization for SCK/MOSI/MISO pins, the CS pin still remains active and leads parasitic supply of external ICs (spi_context_cs_configure() - the only function for CS pin configuration from spi_context.h). How we should deal that?

PS. pls note the pm/device_runtime.h header has no closing '}' bracket for 'external "C" {' definition. It leads to error on using the module with C++ sources.

RE: Zephyr power management issues

Simonr — Wed, 08 Sep 2021 10:53:01 GMT

Thank you for the update.

1. The regulator subsystem here describes how you can add a regulator to any kind of external device (like sensors or external flash drives). It should be possible to implement something like this for both the QSPI flash and sensor you're using.

2. Check out the subsystem linked to above as well as the regulator.h file in \NCS_VERSION\zephyr\include\drivers\

Best regards,

Simon

RE: Zephyr power management issues

Dmitry Kr — Tue, 07 Sep 2021 10:01:50 GMT

Hi Simonr,

1. Of course it has power :) We have GPIO-controlled LDO 3.6->1.8V on the board and both QSPI flash and 6-DOF sensor are powered from this LDO. For good battery life it's necessary to turn off LDO when devices are not in use (when disconnected from Bluetooth central). So, for example, 'jedec,spi-nor' device has 'vin-supply' property, why don't the 'nordic,qspi-nor' have? How it can be controlled?

2. Could you please suggest proper example / description we shoud consider to control powering of the sensor?

RE: Zephyr power management issues

Simonr — Mon, 06 Sep 2021 13:29:54 GMT

Hi Dmitry

1. I'm not sure I understand the question. It sounds like you don't have a Vin on the QSPI device you're using, but I find that hard to believe. How do you power the QSPI device?

2. Yes, I think the power managemer in the nRFConnect SDK should be able to handle power management on the chip. You could alternatively set these SPI lines low so they don't draw any current at all during this time.

Best regards,
Simon