i.MX6DQ Android 5.1.1_2.1.0-ga fails resume.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6DQ Android 5.1.1_2.1.0-ga fails resume.

4,421 Views
satoshishimoda
Senior Contributor I

Hi community,

Our customer have a question about i.MX6Q Android 5.1.1 BSP.

This BSP sometimes faile to resume from suspend.

Please see the detail as below.

=====

[Board]

MCIMX6Q-SDP

[BSP]

Android 5.1.1_2.1.0-ga

[Problem]

Sometimes fail to resume from suspend.

[Procedure]

1.Boot Android 5.1.1 and set the following bootargs to use serial console.

  setenv bootargs console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb,bpp=32 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consoleblank=0 androidboot.hardware=freescale cma=384M androidboot.selinux=disabled androidboot.dm_verity=disabled

2. Suspend Anroid with the following command.

  echo mem > /sys/power/state

3. Resume with pushing power switch (SW1).

[Frequency]

Often

[log]

root@sabresd_6dq:/ # echo mem > /sys/power/state

PM: suspend entry 1970-01-01 00:42:12.771037673 UTC

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.001 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.

Suspending console(s) (use no_console_suspend to debug)    // Suspending Done

PM: suspend of devices complete after 66.477 msecs    // Push power button to resume

PM: suspend devices took 0.070 seconds

PM: late suspend of devices complete after 0.535 msecs

PM: noirq suspend of devices complete after 0.634 msecs

Disabling non-boot CPUs ...

CPU1: shutdown

CPU2: shutdown

CPU3: shutdown

Resume caused by IRQ 103

Suspended for 0.000 seconds

Enabling non-boot CPUs ...

CPU1: Booted secondary processor

CPU1 is up

CPU2: Booted secondary processor

CPU2 is up

CPU3: Booted secondary processor

CPU3 is up

PM: noirq resume of devices complete after 0.392 msecs

PM: early resume of devices complete after 0.454 msecs

PM: resume of devices complete after 131.201 msecs

PM: resume devices took 0.140 seconds

Restarting tasks ... done.

PM: suspend exit 1970-01-01 00:42:16.162975000 UTC

root@sabresd_6dq:/ # ata1: SATA link down (SStatus 0 SControl 300)

mma enable setting inactive

PU: Power-off latency exceeded, new value 29000 ns

PM: suspend entry 1970-01-01 00:42:20.462260334 UTC

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.001 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.

Suspending console(s) (use no_console_suspend to debug)   // Suspend automatically again with no handling

=====

[Question]

How can I modify this resume problem?

Best Regards,

Satoshi Shimoda

Tags (1)
0 Kudos
23 Replies

52 Views
satoshishimoda
Senior Contributor I

Dear SergioSolis,

I tested with another SABRE-SDP, but same problem was occurred.

And tested with M6.0.1_2.1.0 BSP, but same problem was occurred.

> Can we get a log of the system? 

Did you mean dmesg log as "a log of the system"?

If yes, please see the attached file.

I entered to suspend on line 656, and push power switch on line 662.

The system was woken-up on line 685, but entered to suspend again automatically on line 692.

I woke-up the system on line 693 again by pushing power switch, and execute dmesg on line 720.

For your information, I tested with SCH-27392 Rev. C4 SABRE-SDP, and another one is Rev. C2.

Best Regards,

Satoshi Shimoda

0 Kudos

52 Views
SergioSolis
NXP Employee
NXP Employee

Hello Satoshi,

I am unable to duplicate using a SABRE6Q-SDB version.  Sounds like something on the power rails may not be turning back on after a suspend.

Can the customer duplicate the problem under Marshmallow 6.0?

0 Kudos

52 Views
satoshishimoda
Senior Contributor I

Dear Sergio,

I tested with SCH-27392 REV C4 board.

700-27392 REV C is written on the board also.

Best Regards,

Satoshi Shimoda

0 Kudos