I looked through the code in the mx4 kernel now a bit more and the reason for the hold wakelock is that there is simply data flowing. What triggers the data flow or what data is actually flowing is not clear yet but I don't see any HCI frames receiving on the bluetooth stack side so far when this happens.
Next steps are to find a proper fix: 1. Find out what is actually sending data and why 2. Look into the difference between mx4 and krillin on the kernel side and see if that helps us 3. Trace the trigger through the whole MTK stack and see what is actually causing the activity -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1505241 Title: Phone does not suspend Status in Canonical System Image: In Progress Status in bluez package in Ubuntu: In Progress Bug description: I am seeing both the MX4 on proposed and the E4.5 on stable exhibit similar behavior According to the logs they are not able to suspend due to active wakeup sources. (I am running a BT test kernel on the MX4 3.10.35+) To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1505241/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
