Disabling performance cpufreq governer in kernel config causes build errors

[ljbade]

I was trying to force the kernel to use the performance cpufreq governor rather than ondemand since my Hackberry board runs of AC.

The first problem was that when I enabled the performance governor and made it the default the board still booted with ondemand as default.

I then removed all governors except performance and I got this link error:

arch/arm/mach-sun4i/built-in.o: In function sun4i_cpufreq_target': cpu-freq.c:(.text+0x12268): undefined reference tocpufreq_frequency_table_target'
cpu-freq.c:(.text+0x1238c): undefined reference to sun4i_freq_tbl' arch/arm/mach-sun4i/built-in.o: In functionsun4i_cpufreq_initcall':
cpu-freq.c:(.init.text+0xb84): undefined reference to cpufreq_frequency_table_get_attr' cpu-freq.c:(.init.text+0xbb0): undefined reference tosun4i_freq_tbl'
arch/arm/mach-sun4i/built-in.o:(.data+0x2a0c): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'

Is the ondemand governor hard coded somewhere?

[adrientetar]

I took a quick look at the code...

Ondemand isn't "hardcoded" anywhere, its just that performance has no cpufreq_frequency_table_target function since its always at max frequency, etc.

[romanrm]

1. I can use the performance governor just fine.

# cpufreq-set -g performance
# cpufreq-info 
...
  available cpufreq governors: fantasy, interactive, conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 300 MHz and 1.03 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.01 GHz (asserted by call to hardware).
...

2. What are you trying to achieve by ripping out governors from the kernel? My MK802 runs off AC too, yet I consider tuned 'ondemand' to be a better choice than 'performance'. See http://linux-sunxi.org/Cpufreq

[adrientetar]

@romanrm To answer 2), it looks like he wanted to have performance as default bootup gov and switching it from defconfig didn't work.

[ljbade]

Yeah I wanted to speed up booting and framebuffer rendering by always running at max frequency.

Hmm I may take a look at why it requires the frequency table. It shouldn't need it otherwise the broken governors should be removed from the default governor option in the config menu,

EDIT: Yeah the build errors come from two places, first the https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.0/arch/arm/mach-sun4i/cpu-freq/Makefile will not link cpu-freq-table.c if kernel config says frequency table is not needed, and as @romanrm says https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.0/arch/arm/mach-sun4i/cpu-freq/cpu-freq.c fails when cpufreq_frequency_table_target is not compiled as when no frequency table is compiled.

So I guess I will need to look at how other cpufreq drivers are written to handle this.

EDIT 2:
Found how similar bugs were fixed in other cpufreq drivers:
https://lkml.org/lkml/2012/8/22/381
http://permalink.gmane.org/gmane.linux.kernel.cpufreq/8083

Basically if a driver uses the table stuff then the Kconfig needs to ensure CPU_FREQ_TABLE is selected.

[ljbade]

Okay what I propose is this,

Add something like this to the cpufreq Kconfig:
config CPU_FREQ_SUN4I
tristate "CPUfreq driver for sun4i CPUs"
depends on ARCH_SUN4I && CPU_FREQ
select CPU_FREQ_TABLE
def_bool y
help
This enables the CPUfreq driver for sun4i CPUs.

Then change the makefile to use CPU_FREQ_SUN4I for selecting the cpufreq files.

This way it ensures that CPU_FREQ_TABLE is always built.

[romanrm]

This seems to be the proper way to do this, did you test and it helps solve the previous build failure?

and as @romanrm says https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.0/arch/arm/mach-sun4i/cpu-freq/cpu-freq.c fails when cpufreq_frequency_table_target is not compiled

I don't remember saying anything of that sort, though :p

[ljbade]

I will test it this evening when I reboot back into Linux.

Looking at the Makefiles I will also test if something breaks when you disable CONFIG_PM...

[adrientetar]

Well it looks like commit 0d0fa65 fixed the cpufreq table issue.

[ljbade]

Excellent!