Issue #891
closedDisplay remains semi-on while in Sleep
0%
Description
I noticed this in a dark room.
Connected to a power source: The display is not entirely powered off while in Sleep. There is a faint gray light emanating from the screen.
Not connected to a power source: The display alternates between being entirely powered off and not being entirely powered off while in Sleep. It switches between the faint gray light and total darkness.
Updated by Paul Kocialkowski over 10 years ago
That's already fixed in git and will be part of the next release :)
Updated by Paul Kocialkowski over 10 years ago
Also, it seems that the device fails to reach deep sleep (proper suspend) here:
<6>[ 3027.529846] PM: Syncing filesystems ... done. <7>[ 3027.532135] PM: Preparing system for mem sleep <4>[ 3027.532562] Freezing user space processes ... (elapsed 0.02 seconds) done. <4>[ 3027.555084] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. <7>[ 3027.578552] PM: Entering mem sleep <6>[ 3027.612731] PM: suspend of devices complete after 32.958 msecs <6>[ 3027.613800] PM: late suspend of devices complete after 0.915 msecs <4>[ 3027.613800] Disabling non-boot CPUs ... <5>[ 3027.614868] CPU1: shutdown <6>[ 3027.615478] Resume caused by IRQ 69, gp timer <6>[ 3027.615478] PD_CORE curr=ON prev=ON logic=ON <6>[ 3027.615478] PD_L4_PER curr=ON prev=ON logic=ON <6>[ 3027.615478] PD_MPU curr=ON prev=ON logic=ON <6>[ 3027.615478] Powerdomain (core_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3 <6>[ 3027.615478] Powerdomain (mpu_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3 <6>[ 3027.615478] Powerdomain (l4per_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3 <3>[ 3027.615478] Could not enter target state in pm_suspend <6>[ 3027.615539] Suspended for 0.004 seconds <6>[ 3027.615722] Enabling non-boot CPUs ... <4>[ 3027.642181] CPU1: Booted secondary processor <6>[ 3027.643554] CPU1 is up <6>[ 3027.644744] PM: early resume of devices complete after 1.037 msecs <6>[ 3027.649383] Switched to NOHz mode on CPU #1 <6>[ 3028.102264] wakeup wake lock: musb_autosuspend_wake_lock <6>[ 3028.127105] PM: resume of devices complete after 482.086 msecs <7>[ 3028.128143] PM: Finishing wakeup. <4>[ 3028.128295] Restarting tasks ... done. <6>[ 3028.140472] suspend: exit suspend, ret = 0 (2014-04-29 19:59:37.033343125 UTC) <6>[ 3028.140869] active wake lock musb_autosuspend_wake_lock <3>[ 3028.305358] hub 1-0:1.0: activate --> -22
It just loops that way over and over again. I wonder why musb_autosuspend_wake_lock is waking up the device. I doubt this is related to Replicant directly though.
Updated by Paul Kocialkowski over 10 years ago
It did work on CyanogenMod, with a clean suspend first time I tried:
<6>[ 188.477142] PM: Syncing filesystems ... done. <7>[ 188.478149] PM: Preparing system for mem sleep <4>[ 188.478637] Freezing user space processes ... (elapsed 0.02 seconds) done. <4>[ 188.499481] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. <7>[ 188.522949] PM: Entering mem sleep <6>[ 188.532104] PM: suspend of devices complete after 7.965 msecs <6>[ 188.533203] PM: late suspend of devices complete after 0.915 msecs <4>[ 188.533203] Disabling non-boot CPUs ... <5>[ 188.534240] CPU1: shutdown <6>[ 188.535095] Resume caused by IRQ 39, TWL6030-PIH <3>[ 188.535095] Successfully put all powerdomains to target state <6>[ 188.535156] Suspended for 43.601 seconds <6>[ 188.535369] Enabling non-boot CPUs ... <4>[ 188.551544] CPU1: Booted secondary processor <6>[ 188.553009] CPU1 is up <6>[ 188.553405] Switched to NOHz mode on CPU #1 <6>[ 188.555114] PM: early resume of devices complete after 2.044 msecs <6>[ 188.666198] wakeup wake lock: musb_autosuspend_wake_lock <6>[ 188.688201] PM: resume of devices complete after 132.354 msecs <7>[ 188.689208] PM: Finishing wakeup. <4>[ 188.689392] Restarting tasks ... <3>[ 188.689971] hub 1-0:1.0: activate --> -22 <4>[ 188.699859] done. <6>[ 188.701232] suspend: exit suspend, ret = 0 (2014-04-29 20:09:59.495727534 UTC) <6>[ 188.701599] active wake lock musb_autosuspend_wake_lock
Maybe I was just unlucky when I tried with Replicant, I'll do it again.
Updated by Paul Kocialkowski over 10 years ago
Looks like it might be the ducati gptimer kicking in, unhappy because its firmware was not loaded. I'll look into it later on. Reference: http://e2e.ti.com/support/omap/f/849/p/188109/677670.aspx
Updated by Paul Kocialkowski over 10 years ago
Fixed in git with commits: https://gitorious.org/replicant/kernel_samsung_tuna/commit/daf88fa5b9fcc747addec1bb5789e119cfab55a3/diffs/6a30ee12e83ed77376619ceda9ec72520774a02d
This was related to the Ducati chip lacking its firmware, as expected. Thankfully, a fix to properly handle the lack of firmware was available on OmapZoom.
I also figured it would be a good idea to have OMAP DSS use earlysuspend to increase PM savings (that's how it's done on Samsung OMAP4 devices, too).
Updated by Paul Kocialkowski over 10 years ago
- Status changed from New to Closed
- Resolution set to fixed
Part of the latest batch of Replicant images!
Updated by Denis 'GNUtoo' Carikli almost 9 years ago
- Category changed from 87 to Framework
- Device Galaxy Nexus (I9250) added
Updated by Denis 'GNUtoo' Carikli over 3 years ago
- Device Galaxy Nexus (GT-I9250) added