Using the GPT to wake iMX.8MN from suspend-to-RAM

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Using the GPT to wake iMX.8MN from suspend-to-RAM

932 次查看
davidkon
Contributor I

We are trying to wake up an i.MX8MN from suspend using the GPT timer. But the GPT timer doesn't seem to be running during suspend.

On a custom iMX8MN board with linux we want to be able to wake the device from suspend (echo mem > /sys/power/state) after a specified timeout using the GPT timer. I have written a driver for the GPT that allows using the output-compare interrupt. I have configured the according IRQ to wake the device. When using the GPT with this driver during normal operation, I can see that the counter register counts up as expected until OCR1 is matched, then triggers an IRQ that the driver handles, resets the counter to zero and restarts counting. The 32K clock is used as counter source. Similarly, the 24M clock can be used. Both work fine when the system is in running mode.

But when switching into suspend, the counter register doesn't seem to increase. In the drivers suspend() routine, I restart the counter so the timeout is accurate, and configure it to be running and trigger the interrupts. But the device doesn't wake up after the timeout, and when I wake up using a different method, I can see that the counter register barely increased. (about 1/2 a second worth of steps, so about as much  as a suspend/resume would take).

It was necessary to get()+prepare()+enable() the IMX8MN_CLK_GPT1_ROOT clock during driver probe to allow access to the GPT registers. Further I get+prepare+enable the IMX8MN_CLK_GPT1 and the IMX8MN_CLK_32K clocks. The clocks are not released in the suspend() routine.

The iMX8.MN reference manual chapter 12.1 (GPT) section 12.1.3.2.4 (Low Power Mode Behaviour) states that "In Low Power modes, if the clock from the selected clock source is available [...], the counter will continue to run depending on whether the control bit forthat mode is set.".

I have set all corresponding flags WAITEN, DOZEEN, STOPEN in the ControlRegister, and selected the 32K clock (CLKsrc=0b100), which is supplied externally also during suspend. Similarly I tried using the 24M clock (CLKsrc=0b101, also setting EN_24M).

Do I need to configured some clocks of the imx differently? What do I need to change so that the counter continues to operate during suspend mode?

 

Edit with additional information:

We are using the NXP-based linux kernel in version lf-6.1.55-2.2.0 with additional changes that we need to support the custom board.

 

标签 (2)
0 项奖励
回复
7 回复数

749 次查看
opedis
Contributor III

You can not do that. 

Only the low power domain(SNVS) keeps running during the suspend.

Only he low power domain(SNVS) can do suspend/resume, which is using 32k clock as alarm to wake up system. 

and gpt and 24M clock is in high power domain, it will get stop and looses power during suspend. 

 

 

2024-03-23_073719.png

0 项奖励
回复

669 次查看
davidkon
Contributor I

Hi Opedis,

thanks for your message!

I believe that you actually *can*, since there are sections 5.2.9.1 and 5.2.9.2 (CCM, Code Examples 1&2) that exactly claim to set up the CCM such that the device can be woken using the GPT, and also the GPT chapter 12.1.3.2.4 (Low Power Mode Behaviour) claims that the GPT keeps running in low-power mode given that the according flags in the GPT CR are set.

(Note that the chapter numberings are for REV2 of the document)

Your message might explain why the 24M clock is disabled during suspend though. But since I can switch over to the 32K clock, and that doesn't work either, I am still looking for a solution or an explanation on why this isn't working.

 

0 项奖励
回复

604 次查看
opedis
Contributor III

You can NOT let GPT running during suspend.

GPT is not in SNVS power domain.

0 项奖励
回复

815 次查看
davidkon
Contributor I

Sorry, answered to the wrong message. Please see my answer above. TLDR: Problem seems to be that the input clock isn't running, not the IRQ configuration.

0 项奖励
回复

760 次查看
davidkon
Contributor I

I still have no idea why the GPT counter register doesn't increment during suspend. I have

- created a driver for the GPT that works perfectly when the system isn't in suspend (counter is counting, IRQs are received) and delivers the exact expected increments on the counter register

- set the according flags in GPT's CR (STOPEN, DOZEEN, WAITEN)

- selected the 32KHz or 24MHz inputs (GPT's CR.CLKSR = 0b100 or 0b101)

- set the GPT1_CLK_ROOT to 24M_REF_CLK (in CCM_TARGET_ROOT107) and verified that the value is not changed when the system enters suspend

- enabled the GPT1_CLK_ROOT in CCGR16 such that it should be enabled during suspend (level=3 for domain0) and verified that the value is not changed when the system enters suspend

- allowed access to the GPT in the RDC

=> still the counter doesn't increment during suspend.

I can see that the 24M oscillator is stopped during suspend, but haven't figured a way to keep it running. The 32K signal is supplied by a PMIC and doesn't stop, but seemingly doesn't reach the GPT when in suspend.

I also tried to

- poke around in the XTALOSC block to see if I can find a flag that keeps the 24M XTAL running during suspend or that would make the 32K signal reach the GPT during suspend. No success there.

- read the CCM chapter for more ideas

- read much of the GPC chapter to see if there is something relevant on clock domain power

 

please advise. thank you!

0 项奖励
回复

829 次查看
davidkon
Contributor I

Back on the issue after a little detour.

Thank you Aldo for the reference, we have checked the example but cannot find any settings used in there that would explain why the GPT counter isn't increasing during suspend. These settings will become important later, though, when an IRQ is generated during suspend and that IRQ needs to be configured to wake the system up.

 

So far we have also tried the following changes:

  • in linux's drivers/clk/imx/clk-imx8mn.c : set the IMX8MN_CLK_GPT1 and IMX8MN_CLK_GPT1_ROOT clocks to "critical". This seems to lead to higher reference counts in /sys/kernel/debug/clk/clk_summary for these clocks, but no change in the behavior. Since these seem to be the peripheral clocks, and not the input clock for the counter, that probably is the wrong direction anyway?
  • in the same, changed the IMX8MN_CLK_GPT1_ROOT to add reference counting:
    hws[IMX8MN_CLK_GPT1_ROOT] = imx_clk_hw_gate2_shared2("gpt1_root_clk", "gpt1", base + 0x4100, 0, &share_count_gpt1);
  • in uboot's device tree in the mcu_rcr section: removed any configuration for access restrictions to the GDC_PDAP_GPT1 (but that wasn't needed, as we could access the GPT all along)
  • in imx-atf: explicitly allowed access to the RDC_PDAP_GPT1 for the linux domain
    (  RDC_PDAPn(RDC_PDAP_GPT1, D0R | D0W)  )
    (but that wasn't needed, as we could access the GPT all along)
  • use GPT2 instead of GPT1

We still don't see an increment in the counter-register of GPT1 during suspend-to-RAM.

In the imx8mn reference manual the only thing I can think of as an issue is the CCGR16, which controls the low power clock gating for the GPT. Granting access with the RDC to the peripheral, as above, should allow the linux kernel to configure the clocks to continue operation during low power. My current assumption is that the CCGR16 is configured in a way that the input clocks are disabled during suspend.

Is there an extra step needed to tell linux to configure CCGR16 in that way?

I will look into this in more detail next week.

0 项奖励
回复

888 次查看
AldoG
NXP TechSupport
NXP TechSupport

Hello,

You may take a look to the i.MX8MN Reference Manual for a sample on this application, you may use it as a reference.
Chapter 5.2.9.1 Example Code 1

Best regards/Saludos,
Aldo.

0 项奖励
回复