init: ondemand tuning

[kszaq]

Set all ondemand tunables like it's done for RPi. Thanks to these GUI animations feel smoother, particularly on ARM targets.

[lrusak]

I'm fine with that. Thanks!

[MilhouseVH]

On RPi/RPi2 with this PR I'm getting this:

and then the system is dead. Will dig into this tomorrow (Fri) unless anyone has any bright ideas!

[HiassofT]

As also commented in slack I'd prefer cpufreq tweaks to be a standard systemd unit - this allows easier tweaking (or disabling) if needed

[MilhouseVH]

The RPi/RPi2 failures may be the result of an interaction between this PR and #3537 (package bumps) which I'm also including in my builds. A build with both #3537 and this PR results in the previously mentioned boot problems, but with only this PR (and without #3537) is booting OK. Hmmm.

Will try and narrow it down Friday - currently clean building RPi2 on a second machine with both this PR and #3537 to see if I can reproduce the original boot problem.

[MilhouseVH]

I haven't been able to reproduce the previously reported boot issue so far, maybe it was a one-off (or ccache related?) issue and thus a red herring. A new build with both #3538 and #3537 is booting normally while a similar build would not boot last night. Very odd.

As mentioned on Slack it would be better to tweak platforms on a project/device basis (maybe using systemd, or platform_init), and something like the default governor could also be set in the kernel config. Setting the same cpufreq settings for all devices may become a problem in future if we need to use different settings for a specific project and/or device.

[MilhouseVH]

Also... this PR doesn't actually work - add debugging break=all to single step init:

😄

[kszaq]

@MilhouseVH Thank you for extensive testing! I'll leave this PR open and amend according to suggestions when I find some time...

[kszaq]

Changed modifications in init to not use find.

[MilhouseVH]

Close now, after #3896?

[chewitt]

Closing as the PR wa superseeded with #3896