@mautz, happy to help! As far as I remember, you used custom kernel. Did you underclock/undervolt? In non-sleeping device, you are probably using the lowest frequency a lot.

To my understanding, there are tradeoffs with CPU sleep which are related to larger number of operations that device has to do when entering/exiting sleep.

So, let's see how long does one sleep cycle lasts. For that, under CPU sleep graph in SystemDataScope, you have a stats on "Duration of single suspend" and "Suspend overview". For now, we can just check the duration. On OPX, I have 60-150 s during a night and 0-40 s during a relatively active period of use. For reference, the CPU sleep % goes and stays at 97% during most of the time in a night.

How large CPU sleep % do you get when you let the device rest?

How long is an average duration of a single suspend?

Note that 150s is probably induced by collectd itself, since I have to wakeup the device to measure the stats. So far, I haven't seen any major impact on battery life when using such relatively rare wakeups.

@rinigus

No modifications to kernel at the moment, since im running my cm13 port.

I completely disabled bluetooth an hour ago: Stats so far are:

CPU sleep % Max 97 Last 95

Duration average is 109

I'll let it run through the night to give more stats.

But the problem is that i don't know how to fix the bluetooth wakelock issue in cm12.1 and cm13 ports at the moment.

@mautz: that's looking very good! Give it some time and let's see if you get better battery life. I guess you would need to measure for few days to see whether the battery improved with the sleep or not. But with these CPU sleep stats, I don't think you could improve it much more through CPU sleep (and use your phone as well).

Now regarding BT wakelock: don't know much about it. Maybe someone else can help, IRC?

@rinigus

Battery usage is a bit lower when suspend is working.

I also found the cause for the wakelocks, the bt config is missing in /proc

/proc/bluetooth/sleep/lpm for example, but i don't know why they are not created atm.

EDIT: This happens because CONFIG_BT_MSM_SLEEP is not enabled in the kernel, since this could cause trouble with bluez. I'll try it anyway I report back.

A bunch of Nexus 5 related commits here: https://git.kernel.org/cgit/linux/ke...p&q=hammerhead

So does it mean it's possible now to run Linux 4.9 on it with Freedreno? Did anyone try?

I'm getting a second device soon to experiment. So if anyone has instructions how to do it - I can help testing.

Just got my new Nexus 5. Looking forward for some Freedreno tests with upstream kernel

Mhh, what about all the other drivers? I don't think that Qualcomm and Broadcom will release updated drivers for new kernel versions.

Can you enumerate, what exactly is usually using a blob? WiFi I suppose? Touchscreen? Interface to the modem?

Some of that stutf could be in those upstream patches already, some might not. It's probably good to make some table, describing what's missing.

I doubt they'll release anything, but same thing was with Adreno blobs. They were reverse engineered however.

Could anyone please test this kernel and the bt on off 'scripts'? I don't have any BT devices here at the moment.

I enabled the BT sleep in the kernel, but it doesn't work correctly at the moment, the wakelocks are still there.

So, as a quick and also dirty hack, please create

bt-on.sh which should contain the follwing line:
and bt-off.sh with follwing line in it:
Don't forget to chmod +x both files.

To use these scripts as user add to /init.hammerhead.rc in the bluetooth lpm section or execute the command after boot with devel-su.

The bt-off command should disable bluetooth and the wakelocks allowing the Nexus to enter suspend state.

bt-on starts bluetooth(and the wakelocks).

So bt-off should be executed after boot or put it in your rc.local or any script which gets executed after boot.

Would be nice if someone could report back if this works.

Suspend time can be checked with 'mcetool --get-suspend-stats' or SystemDataScope.

Kernel can be downloaded here.

Another method that works without flashing a kernel:

If you don't need bluetooth you could also disable bt completely with following command: This also stops the wakelock but bluetooth can not be enabled again until you reboot.

@mautz, I guess even a little bit more battery could be good . You probably see the largest improvement when you don't have network, i.e. travelling without roaming.