[Nexus 6  Original Android Development] flar2:
Yes, but I don't think it's a good idea. You will recall earlier that there were a lot of problems with reboots on this device, and that I was unable to explain a lot of them. Now on 5.1, things are quite stable. Some of the early reboots were related to trying to carry the frequency along when tasks migrated to different cores (ie, the problems with cpuboost driver and the original elementalx governor). But this was only part of it (and could be related to what I'm about to describe).

The CPU uses power (obviously) and draws a higher current at higher frequencies. The battery and regulator have to be able to supply enough current to drive the CPU. The ability to deliver that current diminishes at lower battery levels and at higher temperatures. But it's not just about delivering the required current, it has to be done in a very short timespan. It has to deliver the current quickly enough to respond to frequency/state changes. I believe the major problem all along has been that a significant proportion of Nexus 6's are not able to deliver the required current quickly enough. This is why there has always been a frequency cap below 20% battery, and why another cap was added at 40%. This is a problem of electrical design points (EDP).

Look at the kernel threads and you'll see people complaining of shutdowns and reboots at low battery levels and a lot of unexplained general instability. Earlier, I had disabled the thermal daemon and used a in-kernel thermal management, which seemed to exacerbate reboot and shutdown problems (this was reverted by franco too, as there were reports of shutdowns at low battery). Earlier versions of the elementalx governor also exacerbated the problem, due to frequent jumps between min and max frequency. This caused instability in the power supply. It was not always delivering the required current quickly enough for these jumps. I suspect this is also one of the reasons hotplugging is now disabled: to avoid strain on the power supply when cores jumped from sleep to max freq.

Most damning of all, there was a user in this thread who was trying to overclock, and naturally thought that increasing the voltage to the oc frequency would help. Counter intuitively, the answer was actually *decreasing* the voltage for the oc frequency. The reason is that the battery/regulator could not deliver enough current at the higher voltage and it was crapping out.

As with any electronics, there is a distribution of tolerances to these effects. Some devices will be fine disabling these caps and others will be very sensitive. When Google/Motorola decided to cap the frequency at 40% and 20% battery, they likely looked at these tolerances and chose something that would guarantee stability for most or all devices under normal use.

There are multiple ways to prevent the frequency cap: stop the thermal daemon, use custom thermal driver in kernel, or add something in the kernel to override the activities of the thermal daemon (as [MENTION=3357040]Imoseyon[/MENTION] is doing). Once imoseyon's code is tested thoroughly, I will have a look and if it's not going to mess with anything else, I will add it. But I'm not going to make it easy to disable due to the reasons above. I don't want to see any more reboot reports. Nevertheless, if imoseyon's patches work well, the option will be there for those willing to take the risk.