Replicant

That's already fixed in git and will be part of the next release :)

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.

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.

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

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).