pm_device_action_run behavior when multipile sensors are connected on same bus

[Ankit_chauhan]

I have an application in which there are two high speed sensors consider it as sensors 1 and sensor 2. Both sensors are connected over same SPI lines having different CS pins and power supply pins using different LDOs.

According to my application, in idle case when there is no requirement of reading data from the sensors, I am turning off their powers and suspend the SPI bus using Zephyr's PM APIs. I registred pm_action APIs for both the sensors in the respective drivers and I am using CONFIG_PM_DEVICE to manage device state using PM_DEVICE_ACTION_RESUME and PM_DEVICE_ACTION_SUSPEND.

In actual application, I will call the pm_device_action_run(dev, PM_DEVICE_ACTION_SUSPEND); to a sensor at a time, and this will suspend the SPI bus when it executed. In this case what should happen to the second sensor as the SPI bus is already suspeded.

What I observed is, when I call pm_device_action_run(dev, PM_DEVICE_ACTION_SUSPEND); from sensor 1 it suspend the interface and I can see the success return from pm_device_action_run. Now when application tried to suspend the sensor 2 using the same API then I observed that pm_action API of that sensor 2 is not executing which is registered in the driver. In short, if Sensor 1 is suspended then if I call pm_device_action_run it is not reaching to the driver pm_action API and I am not able to execute the Sensor 2 power suspend operations.

Is it something expected or I am handling such scenario differently. I am curious how the Zephyr is handling such scenarion as using common interface for multiple sensor is quite common and I believe Zephyr is alreayd handling it but I am not aware about it.

If someone can help here to understand me such usecase that would be helpful.

[Hieu]

Hi Ankit_chauhan,

What I observed is, when I call pm_device_action_run(dev, PM_DEVICE_ACTION_SUSPEND); from sensor 1 it suspend the interface and I can see the success return from pm_device_action_run. Now when application tried to suspend the sensor 2 using the same API then I observed that pm_action API of that sensor 2 is not executing which is registered in the driver. In short, if Sensor 1 is suspended then if I call pm_device_action_run it is not reaching to the driver pm_action API and I am not able to execute the Sensor 2 power suspend operations.

What is the "dev" you are using when you call pm_device_action_run() for these two sensors?

The behavior might also depends on the sensor's PM support a little. What sensors are you using here?

Hieu

[Ankit_chauhan]

Hi Hieu,

Thank you for the response. 

I have two sensors, sensor 1 is the Biopotential and Bioimpedance AFE that measures ECG. And sensor 2 is the IMU sensor. Both sensors are connected on SPI2 that uses "nordic,nrf-spim" interface.

The dev that I am using in the application is from const struct device *const dev = DEVICE_DT_GET_ANY(AFE); that is defined in the dts file inside SPI2 node.

[Ankit_chauhan]

Hieu,

Thanks for the reply.

I got your point here, instead of suspedning an entire bus I need to focus of device runtime status and then suspend the device. I will take a look at the link that you shared. 

[Hieu]

Hi Ankit_chauhan,

Perfect. I will keep this case on hold then. Please feel free to follow-up or close it as you see fit.

Hieu

[Ankit_chauhan]

Hi Hieu,

Sorry for the late reply. I went through the dev training page you shared and I have implemented the device runtime power management support in my application.

In my case its using SPIM driver of nordic spi_nrfx_spim.c. When I check the driver I found that in function "transceive" it first calls the pm_device_runtime_get(dev); and at the end of the operation it calls pm_device_runtime_put_async(dev, K_NO_WAIT); from "finalize_spi_transactio".

From this implementation, it looks like the SPI bus toggles the interface on every communication we made with the peripheral. I confirm that as well by putting debug logs around these operations and observe the toggling of interfaces.

With this behavior what I observe is, it causes a delay between the reads that I performed for both the peripherals MAX and LSM. This ultimately results into a data loss if I compare the performance of the device that does not have device runtime configuration.

Do you have any other alternative for this, as the loss of a data is not something that we can go ahead with?

 
Ankit.

[Hieu]

Hi Ankit,

I am afraid that is just how the driver is implemented. I fully agree it is not ideal.

For this, you have the following options:

• Forking sdk-zephyr and implement changes to the SPI driver.
• Switch to using the nrfx driver
  • This also requires you to implement the rest of the driver stack all the way back to the application. However, you do have full control of the SPI peripheral.

Hieu

[Ankit_chauhan]

Hi Hieu,

Thanks for the reply and support.

[Hieu]

Hi Ankit,

Just doing my job. I will close this case then. Please feel free to reopen it if you have any questions on the same topic.

Hieu