i.MX6 Suspend to RAM locks up if interrupt occurs

[jcc273]

Hello,

I am trying to get my system to suspend-to-ram (echo mem > /sys/power/state) and it works great and wakes up with my assigned gpio-key without issue.  However, if the gpio is pressed while the system is going into suspend it locks up and won't come out.  The same occurs with the console.  So if i spam the button while executing echo mem > /sys/power/state the system goes to sleep fine:

PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: suspend of devices complete after 126.463 msecs
PM: suspend devices took 0.130 seconds
PM: late suspend of devices complete after 1.323 msecs
PM: noirq suspend of devices complete after 1.377 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown

But it never wakes back up from any interrupt.  The same exact thing happens with the console interrupt if i spam a key after sending the suspend command so that leads me to believe it is any interrupt that occurs while trying to suspend.  I can't seem to find any other mention of this issue?  Something I am missing?  I am using gpio7_13 for the button and am using an i.mx6 quad plus and running imx linux 4.1.15_1.1.0_ga.

Thanks!

[igorpadykov]

Hi Jarrod

issue may be caused by ERR007265 CCM: When improper low-power

sequence is used, the SoC enters low power mode before the ARM core executes WFI

https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf 

One can try to reproduce issue on Sabre SD reference board with  Demo Images

https://www.nxp.com/webapp/Download?colCode=L4.1.15_2.0.0_MX6QDLSOLO&appType=license&location=null 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jcc273]

This sounds like what I am experiencing but the Kernel I am using appears to have the workaround already implemented in pm-imx6.c:

/*
	* ERR007265: CCM: When improper low-power sequence is used,
	* the SoC enters low power mode before the ARM core executes WFI.
	*
	* Software workaround:
	* 1) Software should trigger IRQ #32 (IOMUX) to be always pending
	* by setting IOMUX_GPR1_GINT.
	* 2) Software should then unmask IRQ #32 in GPC before setting CCM
	* Low-Power mode.
	* 3) Software should mask IRQ #32 right after CCM Low-Power mode
	* is set (set bits 0-1 of CCM_CLPCR).
	*
	* Note that IRQ #32 is GIC SPI #0.
	*/
	imx_gpc_hwirq_unmask(0);
	writel_relaxed(val, ccm_base + CLPCR);
	imx_gpc_hwirq_mask(0);

However, i did stumble upon this forum post:  IMX6SX Kernel 4.1.15 suspend/resume issue 

And the solution there seems to have fixed my problem, although I am not sure i completely understand why because my issue does not seem to be the same has his.  For some reason moving CAAM to the gpc seems to have corrected whatever was happening for me : /.  Looking at the device tree CCM has an interrupt parent of gpc still so no changes there like with the CAAM.  Any insight into what is going on would be helpful so that i can make sure i fully understand the problem and it doesn't crop up on me randomly down the road.

For convenience here is the patch from Dave in that other post that fixed things for me:

--- linux-rel_imx_4.1.15_1.0.0_ga/arch/arm/boot/dts/imx6sx.dtsi.orig 2016-04-01 14:09:50.000000000 -0400

+++ linux-rel_imx_4.1.15_1.0.0_ga/arch/arm/boot/dts/imx6sx.dtsi 2016-04-01 14:10:34.000000000 -0400

@@ -928,14 +928,14 @@

                     sec_jr0: jr0@1000 {

                           compatible = "fsl,sec-v4.0-job-ring";

                           reg = <0x1000 0x1000>;

-                          interrupt-parent = <&intc>;

+                          interrupt-parent = <&gpc>;

                           interrupts = <0 105 0x4>;

                     };

                     sec_jr1: jr1@2000 {

                           compatible = "fsl,sec-v4.0-job-ring";

                           reg = <0x2000 0x1000>;

-                          interrupt-parent = <&intc>;

+                          interrupt-parent = <&gpc>;

                           interrupts = <0 106 0x4>;

                     };

                };

--- linux-rel_imx_4.1.15_1.0.0_ga/drivers/crypto/caam/jr.c.orig 2016-04-01 12:34:12.000000000 -0400

+++ linux-rel_imx_4.1.15_1.0.0_ga/drivers/crypto/caam/jr.c 2016-04-01 15:09:58.000000000 -0400

@@ -7,6 +7,7 @@

#include <linux/of_irq.h>

#include <linux/of_address.h>

+#include <linux/imx_gpc.h>

#include "compat.h"

#include "regs.h"

@@ -543,6 +544,7 @@ static int caam_jr_suspend(struct device

     struct platform_device *pdev = to_platform_device(dev);

     struct caam_drv_private_jr *jrpriv = platform_get_drvdata(pdev);

+    imx_gpc_mf_request_on(jrpriv->irq, 1);

     if (device_may_wakeup(&pdev->dev))

           enable_irq_wake(jrpriv->irq);

@@ -554,6 +556,7 @@ static int caam_jr_resume(struct device

     struct platform_device *pdev = to_platform_device(dev);

     struct caam_drv_private_jr *jrpriv = platform_get_drvdata(pdev);

+    imx_gpc_mf_request_on(jrpriv->irq, 0);

     if (device_may_wakeup(&pdev->dev))

           disable_irq_wake(jrpriv->irq);

Thanks,

Jarrod

[igorpadykov]

Hi Jarrod

could you try to reproduce issue on Sabre SD reference board with  Demo Images.

Best regards
igor

[jcc273]

Hi Igor,

I do not have a Sabre SD reference board in order to perform this test.  Maybe at some point i can get one and try it.  The board the issue is occuring on is Compulab's SBC-FX6 with factory images and the patch above corrects the issue.  I also have an e-con systems eSOMiMX6-micro board that i have tested with it's factory images and it does not have the problem.

Thanks,

Jarrod