[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1



Hi,

On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote:
> On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote:
> > On Thu, Aug 05, 2021 at 05:26:09PM +0000, Diederik de Haas wrote:
> > > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> > > 
> > > So I build my own kernel with the following patch:
> > > +CONFIG_CLK_RASPBERRYPI=y
> > 
> > Would CONFIG_CLK_RASPBERRYPI=m be enough?
> 
> Maybe. I haven't tried that. I 'copied' what was done for arm64 and armhf in
> https://salsa.debian.org/kernel-team/linux/-/commit/7dc3d9453272836a9571c30
> b9776a85a5e41c657
> https://salsa.debian.org/kernel-team/linux/-/commit/c4ab143979cc30c395251a4
> 8ba6b5b8969973b70
> 
> If I grep on CLK on configs on my amd64 machine and various RPi's,
> then they all have '=y' on them, so it appears to be the standard/norm.

I just found out that on my Rock64 arm64 kernel the value is '=y'
$ grep CONFIG_CLK_RASPBERRYPI /boot/config-5.14.0-trunk-arm64 
CONFIG_CLK_RASPBERRYPI=y

And on top of that, this kernel config change is targeted at 
debian/config/armel/config.rpi which is a config file solely for the RPi 0/0w/1.
I understand/agree with the principle to enable things as modules as much as 
possible, but I don't think it's important in this specific case.
 
> > > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> > > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> > > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> > > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> > > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> > 
> > Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
> > able to switch to that if you prefer it?!

True, but I think 'performance' is a bad default scheduler in general as 
AFAICT it runs the CPU at full speed all the time.
In the case or RPi's I think it's especially bad as due to their low power 
consumption they're often on 24/7, while being idle most of the time.
With 'ondemand' it runs at lowest speed normally, but only scales up when 
needed, which I think is what most people want and expect.
So changing the default to 'ondemand' seems the right choice and the default 
governor must be builtin.

https://salsa.debian.org/kernel-team/linux/-/merge_requests/381 is my MR to fix 
this bug and enable these changes in config.rpi.
(I'll soon update that MR and retarget it to master)

In that MR I've also made 'conservative' governor builtin.
While strictly not needed, this change is also restricted to config.rpi and 
it's the best governor for solar/battery powered devices, which is (afaik) a 
common use case for RPi 0/0w/1.
I'm _assuming_ that many users of RPi's are not tech-savvy and don't know that 
you can 'modprobe' additional governors if you want to use them.
In fact I only learned that recently. Previously I thought I couldn't use them 
because they didn't show up in the *available* governors. When a governor is 
loaded (or builtin), it does show up as an available governor.

Cheers,
   Diederik

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: