pinebookpro-kernel: overclock patch #28007
Conversation
thypon
force-pushed
the
overclock-pinebook
branch
from
f230bc0
to
25a3521
Compare
|
Overclocking related issues are super hard to isolate and bisect, especially on a machine that already has other issues. Why merge this into the main kernel package when you can simply ship an overlay and instruct users on how to apply it and stress-test their own silicon? It's literally 1 line in the u-boot boot script. Silicon lottery applies to RK3399 too. If Google has their SoCs tested to be able to reach higher clock speeds, good for them. Does Pine64 have them tested for higher clocks? I don't think so. |
|
^ this, we imo should keep the defaults. |
|
I'll leave it here and test a couple of weeks. When we upgraded from tsys to this mainline we downclocked all our users of 0.3Ghz. |
|
Compiled the kernel 3 times, in an evironment with stable 22.5 degrees and 50% humidity. The temperature was in the 60s degree range, with 61/62 peak with the OP1 profile. Interestingly the pinebook pro never crashed while on the same test with the non-OP1 profile (underclock), crashed once in 3 run. Powersupply connected in both cases. |
|
Has this been submitted upstream? What did the rockchip maintainers have to say about it? @depau thanks for the tip I am willing to roll the dice and throw this on my book, but I agree with the others that we should be striving to get closer to a vanilla kernel, not farther. You may have also noticed that the 5.7 tsys kernel had altmode support, and the newer kernels Void ships do not. The altmode patches are much deeper than dts tweaks, though. |
|
Not yet, I would like to do a distribution-wide test before sending this upstream. And the odds of being distructive is very remote on the pinebook, given that tsys was using a stronger overclock. |
|
I'm running benchmarks over benchmarks right now, and, if I can say something, the pinebook seems more responsive and stable than before. |
|
@thypon how does it affect power consumption. I know that excessive power consumption (even with the barrel charger plugged in) has been an issue. Especially when using an SSD. |
Your Pinebook. Again, the device clearly has many other issues and crashes, and until every issue has been bisected and identified you can't be 100% sure that the problems aren't caused by overclocking. RK3399 chips are real life objects, and as such no chip is made equal and not all chips will run stably at the same high frequencies. Since users will most likely NOT be aware that their device is being overclocked/undervolted/overvolted/anything unless they read the DTS, they will most likely blame it on faulty hardware rather than faulty settings. Devices crash with tsys' kernel too. If yours doesn't, then you won the silicon lottery, good for you. I suggest to stick with what rockchip does for mainstream RK3399 - not for Chromebooks - and with whatever Rockchip has tested and guarantees when they sell the chips to their customers. But most importantly - and I can't stress this enough - I do not think it is a good idea to imply that since it runs smoothly on your particular device it will run smoothly on everyone else's device. Run it on 100 devices, stress test them continuously with a synthetic workload for 24h and see if any of them crashes. I seriously doubt they will all pass the test. Yes, it is fair to stress test them with a synthetic workload because you want devices to never crash, not to not crash when you're "just compiling Linux". If it runs fine on your machine you can always add an overlay, it's free open-source software. |
I tested with power cord on. That really depends on the usage. Do you want me to do a battery time test from 100 to 0? Or watt usage? Watt usage is below 12w for me. The problem is that I have a very power efficient nvme, since I bought the less power hungry (nvme) available, but that may not apply to everybody. The barrel charger is known for not to be able to provide enough energy even with no overclock, but this is a problem due to power hungry PCIe devices imho. After applying the patch, it is possible to disable the 2.01ghz extra step with |
|
Same kernel, no external load, on the left without patch, on the right, with the patch: |
|
I had a quick chat with tsys, the guy that mainlined that DTC definition and maintained the manjaro linux pinebook kernel. He told me that he was using the overclock on manjaro because he was sure the first batch was supporting higher clock. He is not sure any other batch supported that higher speed, so he mainlined a more conservative profile. He added that it should not be possible to be sure of the correct profile if we don't ask directly to rockchip. I'm now running the patched version since some days with heavy duty tasks + browsing, the W usage is very mild (6-8), even on battery. I don't believe it will be a dangerous mod. While there is usually a correct profile, when the vendor step in, I don't believe my one is more or less dangerous at the moment, and, due to the fact that we run a OP1 profile until now I don't see how that will be an issue while we still use a distinct kernel for pinebook wrt generic arm64 builds. |
|
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it. |
Pinebook PRO uses the same OP1 RK3399 of many other chromebooks devices.
These devices has been rated for 2.1Ghz max clock speed.
Use the OP1 profile already present in the kernel tree.
@ericonr @CameronNemo