PM broke for ESP32 and ESP32-C3 after #6673

[tmedicci]

The esp32-devkitc:pm defconfig for ESP32 and esp32c3-devkit:pm for ESP32-C3 broke after #6673. It's been a while since that PR, but the problem only happens after typing something in the NSH terminal, so it's worth performing an investigation:

NuttShell (NSH) NuttX-12.2.1
nsh> esp32_idlepm: newstate= 1 oldstate=0

nsh> esp32_idlepm: newstate= 0 oldstate=1
_assert: Current Version: NuttX  12.2.1 35a26e8ad969 Oct  3 2023 14:44:01 xtensa
_assert: Assertion failed wakelock->count > 0: at file: power/pm/pm_activity.c:405 task: Idle_Task 0x400d18e4

Specifically, the issue was introduced by 479689e

[acassis]

@tmedicci did your patch fixed this issue?

[tmedicci]

@tmedicci did your patch fixed this issue?

I didn't submit any patch for that yet, Alan. I still had no time to investigate it further...

[GUIDINGLI]

@tmedicci

I have debugged this issue and find the root cause.

in arch/xtensa/src/esp32/esp32_idle.c esp32_idlepm()

static enum pm_state_e oldstate = PM_NORMAL;
newstate = pm_checkstate(PM_IDLE_DOMAIN);
if (newstate != oldstate)
  {
    ...
  }
else
  {
      if (oldstate == PM_NORMAL)
        {
          /* Relax normal operation */

          pm_relax(PM_IDLE_DOMAIN, PM_NORMAL);  // this meet the assert failed
        }

     ...
  }

This code means, if the newstate still in PM_NORMAL, that there must have someone doing pm_stay(), then relax it.

And this assume is not suitable for all the situation:
someone called pm_activity,
and uart driver will call pm_activity() when received new chars.

In the new version with greedy mode, when someone called pm_activity(), then pm_checkstate() will jump over the pm count.
So, the pm_checkstate() will return PM_NORMAL, then meet the error.

I will commit a patch to change the behavior of pm_activity().

But, this assume is still dangerous:
If the newstate still in PM_NORMAL, that there must have someone doing pm_stay(), then relax it.
Because, in the new architecture of PM, I add the wakelock mechanism.
If someone use an another wakelock handle, then pm_checkstate() may still return PM_NORMAL.

[GUIDINGLI]

#11074