QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

RE: QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

Bogdan Marinescu — Tue, 30 Jul 2024 12:21:36 GMT

Hi Simon,

Thank you, that is reassuring. If possible, please let your developers know about the piece of code that I linked to in my previous post. It might be perfectly fine, but I think that taking another look at it doesn't hurt.

Thanks,
Bogdan

RE: QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

Simonr — Tue, 30 Jul 2024 12:00:29 GMT

Hi Bogdan

So I double checked with the devs regarding this, and I'm told that yyou can safely ignore this error, as it is just the QSPI letting you know it can't be powered down because of XIP being enabled. If everything works as intended you should be just fine. They will also double check the driver to make sure it's working correctly, but at first glance it seems okay.

Best regards,

Simon

RE: QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

Bogdan Marinescu — Mon, 29 Jul 2024 11:03:28 GMT

Hi SImon,

I am definitely not ttrying to put the MCU to sleep manually. When I enabled CONFIG_PM_DEVICE_RUNTIME, I added various calls to pm_device_runtime_get and pm_device_runtime_put in my code. With these changes in places, power management should be automatic: the PM subsystem should figure out which device(s) it can put to sleep and when (I am not considering device drivers here (which need to do more work), because my code doesn't implement any device drivers, it just uses the existing ones). However, none of the PM calls in my code touch the QSPI NOR device, I just use the existing driver. And the driver should do all the required PM work automatically. Looking at the driver, I don't think it's doing it correctly. I'm talking specifially about https://github.com/nrfconnect/sdk-zephyr/blob/v3.6.99-ncs2/drivers/flash/nrf_qspi_nor.c#L318-L323:

if (!dev_data->xip_enabled) {
qspi_clock_div_change();

pm_device_busy_set(dev);
}

I would think that you want to call pm_device_busy_set when XIP is enabled, not disabled, like the code above does? There might be other places where this isn't used correctly, I just highlighted one that looks suspicious.

Thanks,
Bogdan

RE: QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

Simonr — Mon, 29 Jul 2024 07:46:57 GMT

Okay, so I think what's happening here is that this error is caused because you've set CONFIG_NORDIC_QSPI_NOR_XIP=y in your project, because it will keep the QSPI busy to avoid it from being affected by the power management. But something in your project does use power management, that is in turn rejected by the QSPI. Are you trying to put the nRF53 to sleep at all, because that will also call the pm_device_runtime_put I believe.

Best regards,

Simon

RE: QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

Bogdan Marinescu — Sun, 28 Jul 2024 06:51:28 GMT

Hi SImon,

Thabks for your reply. I agree with the first part of your answer: indeed, it seems like the QSPI NOR device is busy when pm_device_runtime_put is being called. However, I disagree with "something in your application is trying to put the device in a suspended state", because I don't do any explicit power management on the QSPI NOR in my application. And I don't think I should, because I believe that the QSPI NOR driver (and maybe some lower level drivers) should do this automatically. If my applcation should actually be involved in this process, please let me know how.

Thanks,
Bogdan

EDIT: also, remember what I said earlier: in my application, I don't actually want the QSPI NOR to go to sleep, which is why I set CONFIG_NORDIC_QSPI_NOR_XIP=y. It is my understanding that this configuration option should prevent the QSPI NOR from sleeping. If this is correct, then the driver shouldn't attempt to put it to sleep at all.

RE: QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

Simonr — Fri, 26 Jul 2024 13:28:48 GMT

Error message -16 points to the device or resource you're calling being busy, so it seems the QSPI is doing something when the pm_device_runtime_put() function is being called in your project. If you don't intend to suspend the device, like this function does, you should find out where and why it's being called, as something in your application is trying to put the device in a suspended state.

Best regards,

Simon