TWIM drivers don't work with power management runtime enabled

[RobHel]

Hello. I'm trying to get my I2C peripheral (I2C1) working with Zephyr's Power Management feature. If I make my i2c1 peripheral compatible with "nordic,nrf-twi" the driver works, but the driver does not support Zephyr's CONFIG_PM functionality. 

If I make the driver compatible with "nordic,nrf-twim", which does support Zephyr's CONFIG_PM functionality, the driver does not work at all. Line 153 in i2c_nrfx_twim.c:

ret = k_sem_take(&dev_data->completion_sync, I2C_TRANSFER_TIMEOUT_MSEC);

assigns -EAGAIN to ret. Increasing the I2C_TRANSFER_TIMEOUT_MSEC doesn't fix the problem, so it appears the semaphore gets reset during the waiting period. 

Has the twim driver been tested and validated with CONFIG_PM=y?

My *-pinctrl.dtsi file and .dts file snippet are attached.

Thanks,

Rob

[RobHel]

To add onto this, I can confirm the dev_data->completion_sync semaphore is getting corrupted. At line 60 in i2c_nrfx_twim.c, it is correct with a count of zero and a limit of 1 as shown below.

However, at line 153 the count and limit are clearly corrupted. 

[RobHel]

The pointer to dev_data gets corrupted in the i2c_nrfx_twim_transfer function. See the below two images when the completion_sync sem is valid and when it is not.

[ovrebekk]

Hi Rob

How are you using the driver from your application? 

Is there any chance you are calling driver functions from an interrupt? 
(keeping in mind that many of the callbacks triggered by various libraries will run in interrupt context)

I am not aware of any issues using the nrfx_twim driver when you have PM enabled, at worst it should just ignore any PM commands, but I can take a look at the implementation if you can confirm whether or not the driver is called from an interrupt. 

Best regards
Torbjørn 

[RobHel]

Hi ovrebekk 

I don't believe anything is happening in an interrupt context. I can't find a way to attach my .c file for you to view. 

On init, the PM action handler function gets called to init the device. In my PM action handler, when entering the case for the action PM_DEVICE_ACTION_RESUME, I do an I2C write. This happens immediatly upon startup. I can confirm this .c file is being initialized after and PM and I2C low level drivers. This I2C write is never successful and I have an assertion in my code to catch this unsuccessful write. 

Why would this be the case? By the way, I can test the I2C writing and reading seperatly using the shell and it works, but doesn't seem to work in the PM action handler function. Is this expected?

Thanks,

Rob

[ovrebekk]

Hi Rob

You should be able to drag drop files into the message box directly, or click Insert -> Image/video/file at the bottom. 

If you want to share a lot of files it is best to zip them first. 

Since you mentioned the PM action handler I assume you are writing your own driver. Looking at the overlay you shared earlier I notice you include ".yaml" in the compatible property, which I think you should remove. The property should just be the company and driver name: "ti,lp5030". 

Once you share the files I will take a closer look. 

Best regards
Torbjørn