i.MX8m nano: Power consumption optimization in suspend mode

[anton_glukhov]

Hello,

I'm trying to achieve the total power consumption <150mW in suspend mode on imx8m-nano SoC with DDR3L and PMIC BD71837, while keeping M7 core running. Here is the information regarding the Software and Hardware that we use.

Software:
Linux kernel, 5.4.70 from the repo: https://source.codeaurora.org/external/imx/linux-imx.git
branch: imx_5.4.70_2.3.0.
The current clock tree - please see in the attachment

Hardware:
SOM - AzureWave AW-PU551
imx8m-nano (with active M7 core)
RAM: DDR3L
PMIC: bd71837
eMMC:
Power tree: in attachment
Unfortunately, I cannot measure the current for each power rail and can only measure the total consumption for the SOM.

Our goals:
Achieve total power consumption in suspend mode (< 150mW), while keeping M7 core running with support following peripherals: GPT1, PWM(for one LED), control few GPIO lines, UART4 for debugging output. And being able to wake up the main core via MU or RPMSG, or any other internal mechanism.

Here are some ideas and knowledge that I've collected during the initial investigation.
1. ATF and PLL clocks. In order to reduce power consumption, we need to fine-tuning all PLLs, by disabling those that we don't need in suspend mode. Sys_pll1, sys_pll2, sys_pll3 which we can focus on.
2. DRAM PLL.
I've put this as a separate point, as it made a significant contribution during my tests. Since we put RAM into retention(refresh only) mode, we can disable DRAM PLL in the ATF code. In order to do so, please see the patch 0001-Disable-DRAM-PLL.patch.
4. PMIC.
As far as I understand, it's possible to disable some power rails in the suspend mode. Unfortunately, the PMIC that we have on the SOM, can disable only BUCK1 in suspend mode. And this BUCK1 provides the power for VDD_SOC rail. I need to investigate if we can disable others if it's possible.
5. M7 core
If we want to put DRAM in retention mode then M7 core has to use the only OCRAM. This part has to be adjusted in the linker script.

M7 core uses only clock sources that are enabled in suspend mode. In my case, I use 24MHz clock.

Clock configuration:

/* switch AHB NOC root to 24M first in order to configure the SYSTEM PLL1. */
CLOCK_SetRootMux(kCLOCK_RootAhb, kCLOCK_AhbRootmuxOsc24M);

/* switch AXI M7 root to 24M first in order to configure the SYSTEM PLL3. */
CLOCK_SetRootMux(kCLOCK_RootM7, kCLOCK_M7RootmuxOsc24M);

CLOCK_SetRootDivider(kCLOCK_RootUart4, 1U, 1U);
CLOCK_SetRootMux(kCLOCK_RootUart4, kCLOCK_UartRootmuxOsc24M);

CLOCK_EnableClock(kCLOCK_Rdc); /* Enable RDC clock */
CLOCK_EnableClock(kCLOCK_Ocram); /* Enable Ocram clock */

Additional RDC configuration:

void Peripheral_RdcSetting(void)
{
    rdc_periph_access_config_t periphConfig;

    RDC_GetDefaultPeriphAccessConfig(&periphConfig);
    /* Do not allow the A53 domain(domain0) to access the following peripherals. */
    periphConfig.policy = RDC_DISABLE_A53_ACCESS;
    periphConfig.periph = kRDC_Periph_UART4;
    RDC_SetPeriphAccessConfig(RDC, &periphConfig);
}

Additional CCM configuration (but I'm not sure that it's the correct one):

CCM->PLL_CTRL[6].PLL_CTRL = kCLOCK_ClockNeededRun;
CCM->PLL_CTRL[25].PLL_CTRL = kCLOCK_ClockNeededRun;
CCM->PLL_CTRL[27].PLL_CTRL = kCLOCK_ClockNeededRun;

Next step:
I would like to focus on SYS_PLL1 now. I believe that it's possible to switch it off. Could you please confirm it, based on the clock tree that I added in the attachment? From the clock tree I see that SYS_PLL1 provides the clock to the following:
audio_ahb (not used)
arm_a53_src (can we safely switch it off?)
dram_apb (can we safely switch it off?)
dram_alt (can we safely switch it off?)
disp_apb (not used)
usdhc3 (we can switch it off in suspend mode)
usdhc2 (we can switch it off in suspend mode)
usdhc1 (we can switch it off in suspend mode)
qspi (not used)
dsi_core (not used)
nand_usdhc_bus (not used)
enet_axi (we can switch it off in suspend mode)
ahb (not sure about it, since we need to use GPIO lines, and MU to wake up the main CPU)
usb_phy_ref (we can switch it off in suspend mode)
uart3 (not used)
uart1 (not used)
wrclk (not used)

Additional question:
1. Can we disable the voltage for VDD_SOC?
2. Can we disable the voltage for VDD_ARM, VDD_GPU, VDD_VPU? (it is not clear if it's possible with our PMIC)
3. Can we keep VDD_GPU and VDD_VPU disabled even in active/idle modes? (Because we don't need them)
4. What are the best optimal voltages in suspend mode? VDD_ARM, VDD_DRAM, NVCC_DRAM?
5. If I want to assign a certain clk_root to another clock source(for example to SYS_PLL2), what is the place in the source code where I can do it? Do you have any examples? Is it device tree files, or ATF, or u-boot?

Thank you!

Best regards,
Anton

[terry_lv]

Hi Anton,

  I think if arm_a53_src, dram_apb, dram_alt are not used, they can be disabled. But ahb should be bypassed.

  If nand_usdhc_bus is not used, it can be disabled also.

  But some clock root can't be disabled directly. It depends on some other conditions.

  If it is wrong disabled, system might get crash. That's why we need to disable those clocks one by one carefully.

  Normally, for BUS, NOC and modules that M7 needs, we will bypass the root pll to 24MHz crystal and for other modules, we can disable them.

  Thanks! 

Regards

Terry

[anton_glukhov]

Hi Terry,

Thank you for your help!

I've reassigned some clocks that were connected to the SYS_PLL1, but still, I cannot manage to suspend/resume with full SYS_PLL1 disable option. I think that the issue in dram_apb, because I've seen in some sources that this clock is critical. It's also "marked" as critical in kernel sources. Please, see my sys_pll1 clock tree in the attachments. What would you recommend? I thought about re-assign this clock to sys_pll2, but I don't know where can I do it. I've tried in u-boot and kernel, but w/o success.

What would you recommend?

Thank you!

BR,
Anton

[terry_lv]

Hi Anton,

  Then I think we shouldn't change dram_apb.

  I checked my atf patch for 8MP and dram_apb is not changed.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv ,

Could you please tell me what is the supplier clock of dram_apb on your board? Is it Sys_pll1?

I wanted to re-assign this clock to sys_pll3 and keep sys_pll3 intact. Do you know how can I do that? I couldn't find the right place in ATF or U-boot.

Thank you!

BR,
Anton

[terry_lv]

Hi,

  I've a new finding that when need to disable ARM_PLL, AHB_ROOT need to be bypassed. Othewise, the system can't wakeup.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv 

That's important information, which can help if the system has problems during resume operation. In my case, I still struggle with SYS_PLL1 clock. When I switch it off the system cannot resume properly. Could you please take a look at the clock tree that I attached here and let me know if ARM_PLL causes this issue? I don't see that ARM_PLL depends on SYS_PLL1. Could you please clarify?

Another question/idea that I asked in the previous question... Do you think it makes sense to re-assign the critical clocks (dram_apb, ahb, maybe dram_apb and arm_a53_src) to another clock? For example Sys_Pll3? I don't know how to re-assign dram_apb. I guess that it should be configured in u-boot or ATF, but all my attempts failed. Do you know if someone from NXP can help with a proper configuration?

Please, examine the clock tree and let me know what do you think. As I said earlier, as a first step, I would like to manage sys_pll1 first. The goal is to be able to switch SYS_PLL1 off completely.

BR
Anton

[terry_lv]

Hi Anton,

  For your question:

1. "In my case, I still struggle with SYS_PLL1 clock. When I switch it off the system cannot resume properly. Could you please take a look at the clock tree that I attached here and let me know if ARM_PLL causes this issue? I don't see that ARM_PLL depends on SYS_PLL1. Could you please clarify?"
   [Ty] I don't think ARM_PLL can cause this issue. To confirm this, you can keep ARM_PLL ON in this case.
2. "Another question/idea that I asked in the previous question... Do you think it makes sense to re-assign the critical clocks (dram_apb, ahb, maybe dram_apb and arm_a53_src) to another clock? For example Sys_Pll3? I don't know how to re-assign dram_apb. I guess that it should be configured in u-boot or ATF, but all my attempts failed. Do you know if someone from NXP can help with a proper configuration?"
   [Ty] If possible, pls take a look at my patch for imx8mp. Some root clocks are kept, e.g. dram_apb. I don't know if someone has a configuration for this. But maybe Tom Zheng can give you some suggestions on this.
3. "Please, examine the clock tree and let me know what do you think. As I said earlier, as a first step, I would like to manage sys_pll1 first. The goal is to be able to switch SYS_PLL1 off completely."
   [Ty] Pls take my patch for imx8mp as a reference in this case.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv ,

Thank you for your help!

I've attached the patch that i use. It is based on your patch that you suggested earlier. However, I cannot enable #define POW_OPT_SUSP_DISABLE_SYSPLL1 option. If I turn it on, then the system doesn't resume properly. This patch shows the latest version of clock configuration that I could achieve. Also, in attachments there is a clock tree of Sys_pll1. Do you think I missed something in this configuration?

Thank you!

BR,
Anton

[terry_lv]

Hi Anton,

  I see POW_OPT_SUSP_BYPASS_SYSPLL1_ROOT and POW_OPT_SUSP_DISABLE_SYSPLL1_ROOT are set to 1 in your patch. In my understanding, if these two options are not causing issues, disabling SYSPLL1 should be OK.

  Also, I think we need to figure out whether it is that the system can wakeup, or it crashes in SYSPLL1 disabling code.

  Have you enabled log prints in ATF and kernel to check this?

ATF:

  Find function bl31_early_platform_setup2 in imx8mn_bl31_setup.c,

  change:

    console_set_scope(&console.console, CONSOLE_FLAG_BOOT);

  to:

    console_set_scope(&console.console, CONSOLE_FLAG_RUNTIME);

Kernel:

echo N > /sys/module/printk/parameters/console_suspend

Then you should be able to see logs from NOTICE function in ATF patch.

Other suggestions:

1. If enet in your M core application is not touched, ENET_AXI can be disabled, not bypassed.
2. If SYSPLL2 is not used in your application, POW_OPT_SUSP_DISABLE_SYSPLL2 could be defined as 1.
3. For power testing, Audio PLLs can be kept (keep POW_OPT_SUSP_DISABLE_AUDIO_PLL as 0). Because in my testing, disabling APLLs might increase power.

Regards

Terry

[anton_glukhov]

Hi @terry_lv,

Thank you for your suggestions. I've enabled log and see those messages in runtime.

Enable or disable Audio_pll gives the same power consumption.

Unfortunately, disabling syspll1 is the main problem. If I disable SYSPLL1 then the system never resumes. I don't know what is the root cause. My idea was dram_apb, or arm53_src clocks, but I'm not sure. Do you know if I need to bypass arm53_src or I can turn it off?

Disabling ENET_AXI conflicts with M4 for some reason (I don't need it though). I need to test it a bit more.

Thank you!

BR,
Anton

[anton_glukhov]

Hi @terry_lv ,

I spent more time and tried to investigate why the system doesn't resume after suspending mode if I disable SYS_PLL1. Unfortunately still the same issue, but I re-assigned all clocks from SYS_PLL1 to other system clocks, so that the sys_pll1 looks like this:

sys_pll1_ref_sel                  1 1 0 24000000 0 0 50000
       sys_pll1                    1 1 0 800000000 0 0 50000
          sys_pll1_bypass             1 1 0 800000000 0 0 50000
             sys_pll1_out             1 1 0 800000000 0 0 50000
                sys_pll1_800m         1 1 0 800000000 0 0 50000
                   dram_apb           1 1 0 160000000 0 0 50000
                   dram_alt           0 0 0 800000000 0 0 50000
                      dram_alt_root       0 0 0 200000000 0 0 50000
                sys_pll1_400m         0 0 0 400000000 0 0 50000
                sys_pll1_266m         0 0 0 266666666 0 0 50000
                sys_pll1_200m         0 0 0 200000000 0 0 50000
                sys_pll1_160m         0 0 0 160000000 0 0 50000
                sys_pll1_133m         0 0 0 133333333 0 0 50000
                sys_pll1_100m         0 0 0 100000000 0 0 50000
                sys_pll1_80m          0 0 0 80000000 0 0 50000
                sys_pll1_40m          0 0 0 40000000 0 0 50000

As you can see, there are only two clocks left that are assigned to sys_pll1. If I try to disable SYS_PLL1 from the patch by setting POW_OPT_SUSP_DISABLE_SYSPLL1 to 1 then the system doesn't resume properly. If I do not set that definition flag then the system resumes as expected. In this experiment, I didn't even start M7 core! Also, I tried all combinations to disable/bypass those two clocks(dram_apb, dram_alt), but the same result. When the system goes to suspend mode then I see all messages from the ATF, which (from my point of view) looks totally fine.

Maybe there are some clocks that depend on SYS_PLL1 and are not exposed via /sys/kernel/debug/clk/clk_summary interface.

I'm focusing only on SYS_PLL1 now and am completely confused. What else can I try from your point of view? Or maybe there are some debug options that might help?

Thank you for your help!

BR,
Anton

[terry_lv]

Hi Anton,

  When POW_OPT_SUSP_DISABLE_SYSPLL1 is set, will the ATF code disable SYSPLL1 successfully?

  In my experience, it will cause a crash if disabling the SYSPLL when some root clocks are using it.

  For wakeup, I have below suggestions to check:

1. Enable log to find out whether the system really can’t wakeup or it crashes when disabling SYSPLL1. I mean, have you seen any wakeup log? There should be three possibilities here.
   
   1. In my atf patch, if no "M7 alive, suspend ok!", the system might get crash in disabling sysplls.
   2. If no "bus_freq_dvfs high bus", please check if SLPCR_A53_FASTWUP_STOP_MODE bit is set.
   3. Get crash in wakeup. There should be some logs for wakeup procedure.
2. Check if SLPCR_A53_FASTWUP_STOP_MODE bit is set in SLPCR of GPC module. Generally, this should be done in function imx_set_sys_lpm() of plat/imx/imx8m/gpc_common.c in ATF.
3. What clock source is your M core? As I know, AHB_ROOT and M core should use the same clock root, e.g., 24MHz crystal or syspll1.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv 

Thank you for your help!

Please, see in the attachment the log from the terminal. When I switch the board to suspend mode in both cases (with enabled SYS_PLL1 or disabled SYS_PLL1) seems the system goes to suspend mode properly. But the power consumption that I observe is the same in both cases.

Regarding SLPCR_A53_FASTWUP_STOP_MODE:

I have this code in plat/imx/imx8m/gpc_common.c:

void imx_set_sys_lpm(unsigned int last_core, bool retention)
{
  if (retention)
    mmio_clrsetbits_32(IMX_GPC_BASE + SLPCR, SLPCR_A53_FASTWUP_STOP_MODE,
      SLPCR_EN_DSM | SLPCR_VSTBY | SLPCR_SBYOS | SLPCR_BYPASS_PMIC_READY);
  else
    mmio_clrsetbits_32(IMX_GPC_BASE + SLPCR, SLPCR_EN_DSM | SLPCR_VSTBY |
      SLPCR_SBYOS | SLPCR_BYPASS_PMIC_READY, SLPCR_A53_FASTWUP_STOP_MODE);

  ....
}

I would assume that the bit SLPCR_A53_FASTWUP_STOP_MODE is handled properly here.

Regarding M7 core. For the current tests I don't even start it. I'm trying to suspend/resume the board without M7 Core running. But in general, I run M7 with the following clocks settings:

CLOCK_SetRootMux(kCLOCK_RootAhb, kCLOCK_AhbRootmuxOsc24M);
CLOCK_SetRootMux(kCLOCK_RootM7, kCLOCK_M7RootmuxOsc24M);

CLOCK_SetRootDivider(kCLOCK_RootAhb, 1U, 1U);
CLOCK_SetRootMux(kCLOCK_RootAhb, kCLOCK_AhbRootmuxSysPll2Div8);

CLOCK_SetRootDivider(kCLOCK_RootUart4, 1U, 1U);
CLOCK_SetRootMux(kCLOCK_RootUart4, kCLOCK_UartRootmuxOsc24M);

CLOCK_EnableClock(kCLOCK_Rdc);
CLOCK_EnableClock(kCLOCK_Ocram);

CLOCK_EnableClock(kCLOCK_Sim_display);
CLOCK_EnableClock(kCLOCK_Sim_m);
CLOCK_EnableClock(kCLOCK_Sim_main);
CLOCK_EnableClock(kCLOCK_Sim_s);
CLOCK_EnableClock(kCLOCK_Sim_wakeup);
CLOCK_EnableClock(kCLOCK_Debug);
CLOCK_EnableClock(kCLOCK_Dram);
CLOCK_EnableClock(kCLOCK_Sec_Debug);

The one uncertain part in M7 configuration is the following settings:

for (int i = 0; i < 39; i++)
     CCM->PLL_CTRL[i].PLL_CTRL = kCLOCK_ClockNeededRun;

 After a few experiments I managed to set only few PLL_CTRL as NeededRun which gives less power consumption:

CCM->PLL_CTRL[6].PLL_CTRL = kCLOCK_ClockNeededRun;
CCM->PLL_CTRL[25].PLL_CTRL = kCLOCK_ClockNeededRun;
CCM->PLL_CTRL[27].PLL_CTRL = kCLOCK_ClockNeededRun;
CCM->PLL_CTRL[31].PLL_CTRL = kCLOCK_ClockNeededRun;

But as I mentioned earlier, I don't even run M7 for all recent tests.

Thank you!

BR,
Anton

[terry_lv]

Hi Anton,

1. If M core is not running, kernel will enter DSM mode, not fast wakeup stop mode. This mode is not what we're working for.
2. If M core is running, pls check:
   1. fast wakeup stop bit is set when kernel enters suspend mode.
   2. Wakeup source is enabled in GIC module.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv,

I did a bit more tests and it the system doesn't resume. It doesn't even show log any single log message after I try to wake it up.

1. I set SLPCR_A53_FASTWUP_STOP_MODE flag in function imx_set_sys_lpm. Now the function looks:

void imx_set_sys_lpm(unsigned int last_core, bool retention)
{
	unsigned int val;
	if (retention)
		mmio_clrsetbits_32(IMX_GPC_BASE + SLPCR, SLPCR_A53_FASTWUP_STOP_MODE, SLPCR_EN_DSM | SLPCR_VSTBY | SLPCR_SBYOS | SLPCR_BYPASS_PMIC_READY);
	else
		mmio_clrsetbits_32(IMX_GPC_BASE + SLPCR, SLPCR_EN_DSM | SLPCR_VSTBY | SLPCR_SBYOS | SLPCR_BYPASS_PMIC_READY, SLPCR_A53_FASTWUP_STOP_MODE);
		
	/* mask M4 DSM trigger if M4 is NOT enabled */
	if (!imx_is_m4_enabled())
		mmio_setbits_32(IMX_GPC_BASE + LPCR_M4, BIT(31));
		
	val = mmio_read_32(IMX_GPC_BASE + SLPCR);
	val |= SLPCR_A53_FASTWUP_STOP_MODE;
	mmio_write_32(IMX_GPC_BASE + SLPCR, val);
	
	/* config wakeup irqs' mask in gpc */
	imx_set_sys_wakeup(last_core, retention);
}

Please let me know if it's correct one.

2. I enabled logging from ATF as you recommended earlier. Thus, I hope I will not be able to miss any log messages. I see those when I suspend the system:

NOTICE: bus_freq_dvfs low bus
NOTICE: no needed enabled SYSPLL3
NOTICE: bypass CCM
NOTICE: Disable CCM
NOTICE: bypass ARM
NOTICE: disable arm pll
NOTICE: bypass syspll1
NOTICE: disable syspll1
NOTICE: bus_freq_dvfs low bus done

But I don't see any logs when I resume it.

3. Now I perform all tests with M7 core active. As you mentioned many parts of ATF code depends on M7 running code (or logic). Therefore all experiments now with M7 core.

4. I'm trying to set kCLOCK_RootM7 to the same root PLL as ahb. In my case the plan is to use SYS_PLL2 for AHB. So, I tried to assign RootM7 clock to kCLOCK_M7RootmuxSysPll2Div4:

CLOCK_SetRootDivider(kCLOCK_RootM7, 1U, 1U);
CLOCK_SetRootMux(kCLOCK_RootM7, kCLOCK_M7RootmuxSysPll2Div4);

The system starts, but when I suspend it, the M7 core doesn't work anymore. Looks like it crashes or suspended as well. But if I use kCLOCK_M7RootmuxOsc24M for M7 core, then at least it continues to work in suspend mode. Do you know any ideas why I have such issue?

And the resume from suspend mode still doesn't work. I see all log messages when it goes to suspend mode, but I don't see any single message when I press the button and wakes up the system. It looks like it tries to resume, since I see that power consumption slightly increases in this moment, but no message. M7 core stops working during resume transition (This is when I use kCLOCK_M7RootmuxOsc24M clock).

Is it possible that someone from NXP tries the same configuration on imx8m-nano board? Maybe it would save some time.

Thank you!

BR,
Anton

[terry_lv]

Hi Anton,

  For 1, the code looks OK.

  For 2, is disabling syspll1 causing the wakeup issue?

  For 4, I recommend to use 24MHz crystal for AHB and M7 first.

  About "The system starts, but when I suspend it, the M7 core doesn't work anymore. Looks like it crashes or suspended as well. But if I use kCLOCK_M7RootmuxOsc24M for M7 core, then at least it continues to work in suspend mode. Do you know any ideas why I have such issue?"

  It seems some clocks used by M7 are disabled in ATF. I recommend to use hello_world project and 24MHz crystal for M7 and UART for testing. 

 About "And the resume from suspend mode still doesn't work. I see all log messages when it goes to suspend mode, but I don't see any single message when I press the button and wakes up the system. It looks like it tries to resume, since I see that power consumption slightly increases in this moment, but no message. M7 core stops working during resume transition (This is when I use kCLOCK_M7RootmuxOsc24M clock)."

  Have you added logs to start of function imx_domain_suspend_finish?

  About "Is it possible that someone from NXP tries the same configuration on imx8m-nano board? Maybe it would save some time."

  Sorry, I don't know if anyone have done the same work on 8mn board. My patch on 8mp is based on @tom Zheng 's work on LPA. As I know, similar work should have been done on 8mm and 8mp.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv,

Thank you for support!

I've added the log message to imx_domain_suspend_finish function and it seems that the execution goes in wrong branch:

if (is_local_state_off(SYSTEM_PWR_STATE(target_state))) {
  if (!imx_m4_lpa_active()) {
    // NOTE: The branch when M7 core is enabled and running!?!?!
    imx_noc_wrapper_post_resume(core_id);
    imx_anamix_override(false);
    dram_exit_retention();
    imx_set_sys_lpm(core_id, false);
  } else {
    NOTICE("call bus_freq_dvfs\n");
    bus_freq_dvfs(false);
    /* flag 0xD means DSP LPA buffer is in OCRAM */
    if (mmio_read_32(IMX_SRC_BASE + LPA_STATUS) == 0xD)
      dram_exit_retention();
  }

  imx_set_sys_wakeup(core_id, false);
}

So, after if (!imx_m4_lpa_active()) check, when M7 core running, the code goes to the branch where bus_freq_dvfs never called. Should I place bus_freq_dvfs call before imx_noc_wrapper_post_resume(core_id); call?

In your patch you call bus_freq_dvfs in exactly the same place. Or maybe it's because you don't run M4 core on your platform?

Thank you!

BR,
Anton

[terry_lv]

Hi Anton,

  bus_freq_dvfs  should be called here.

  What's your setting for SRC->GPR9? Have you set SRC->GPR9 to 0x5555 of 0xD in your M core application?

  Please set SRC->GPR9 to 0xD (if no DDR access in suspend) or 0x5555 (if DDR is needed in suspend).

  Then bus_freq_dvfs  can be called.

  Thanks!

Regards

Terry

[anton_glukhov]

Hi @terry_lv,

I've added the bus_freq_dvfs to the second branch and now the system resumes properly. However, there is no difference in power consumption when I enable these flags: POW_OPT_SUSP_DISABLE_SYSPLL1, POW_OPT_SUSP_DISABLE_CCGR, and POW_OPT_SUSP_DISABLE_SYSPLL2. Maybe those PLLs do not contribute to the total power consumption, or they already were disabled somehow by ATF. Another idea is, maybe those PLLs do not disabled for some reasons.

Regarding the flag SRC->GPR9 to 0xD, I think it's already managed in ATF. I tried it to set from MCU and can leave it there if it's necessary.

In the result, I can suspend and resume the system, but the total power consumption the same and still high. It's about 280-300mW now, but our goal is 150-200mW. I don't know how else can we analyze it w/o getting access to the separate power rails of the SOM.

Do you have any ideas, what else can we try?

Thank you!

BR,
Anton

[terry_lv]

Hi,

  I just recall a document about a power test we did for i.MX8MN.

  The M4 test code is attached.

  Also, I find AN13340 which should be helpful for you.

  After some investigation recently, it seems that my work on i.MX8MP might not be suitable for i.MX8MN, as i.MX8MN is simpler. (Indeed, if you'd like to reach a least low power, you can follow the procedure on 8MP). But for your target (<150mW), that should be easy to achieve on i.MX8MN.

  Text me if you meet any issues.

  Thanks!

Regards

Terry