cpufreq on ARM broken

cpufreq doesn't appear to initialise on ARM - cpufreq_register_driver() fails with -ENODEV.

This appears to be because we register cpus at subsys_initcall() time, and cpufreq drivers at arch_initcall() time. We need cpufreq up and running before any drivers are initialised since their timings depend on the CPU clock rate.

The following patch appears to fix these problems.

arch/arm/mach-sa1100/cpu-sa1100.c +3 -2

@@ -230,8 +230,9 @@
 }
 
 static struct cpufreq_driver sa1100_driver = {
-	.flags		= (CPUFREQ_PANIC_OUTOFSYNC | 
-			   CPUFREQ_PANIC_RESUME_OUTOFSYNC),
+	.flags		= CPUFREQ_STICKY |
+			  CPUFREQ_PANIC_OUTOFSYNC | 
+			  CPUFREQ_PANIC_RESUME_OUTOFSYNC,
 	.verify		= sa11x0_verify_speed,
 	.target		= sa1100_target,
 	.get		= sa11x0_getspeed,

arch/arm/mach-sa1100/cpu-sa1110.c +3 -2

@@ -329,8 +329,9 @@
 }
 
 static struct cpufreq_driver sa1110_driver = {
-	.flags		= (CPUFREQ_PANIC_OUTOFSYNC | 
-			   CPUFREQ_PANIC_RESUME_OUTOFSYNC),
+	.flags		= CPUFREQ_STICKY |
+			  CPUFREQ_PANIC_OUTOFSYNC | 
+			  CPUFREQ_PANIC_RESUME_OUTOFSYNC,
 	.verify		= sa11x0_verify_speed,
 	.target		= sa1110_target,
 	.get		= sa11x0_getspeed,

Thoughts ?
I've forgotten why we introduced this flag, it appears that this would be the first thing in the tree to actually use it, which makes me sceptical.

Quoted 4 lines · Dave Jones

Thoughts ?
I've forgotten why we introduced this flag, it appears that this would be the first thing in the tree to actually use it, which makes me sceptical.

This flag was introduced when I added the "fail if no proper CPU found" feature, which is helpful for the ACPI P-States driver and some other x86 drivers which only check whether they can run on _any_ CPU in the cpu-specific initialization call.

To assert backwards-compatibility, this
flag avoids "automatic unregistration" -- I wasn't aware some drivers do need this backwards compatibility, but obviously ARM needs it. So Russell's patch looks to be what's needed, from my perspective.

Quoted 6 lines · Dominik Brodowski

Quoted 4 lines · Dave Jones

Thoughts ?
I've forgotten why we introduced this flag, it appears that this would be the first thing in the tree to actually use it, which makes me sceptical.

Quoted 4 lines

This flag was introduced when I added the "fail if no proper CPU found" feature, which is helpful for the ACPI P-States driver and some other x86 drivers which only check whether they can run on _any_ CPU in the cpu-specific initialization call.

So how come grepping for STICKY in arch/i386/kernel/cpu/cpufreq didn't turn anything up?

Quoted 4 lines

To assert backwards-compatibility, this
flag avoids "automatic unregistration" -- I wasn't aware some drivers do need this backwards compatibility, but obviously ARM needs it. So Russell's patch looks to be what's needed, from my perspective.

Ok, I've no real objection either way. It just seemed odd to have this functionality around, that no-one was using, which just happened to be the right fix.

I'll roll this in later, right now there's some corruption in the cpufreq bk tree which the bitmover folks are looking into.

Quoted 4 lines · Dave Jones

Thoughts ?
I've forgotten why we introduced this flag, it appears that this would be the first thing in the tree to actually use it, which makes me sceptical.

This flag was introduced when I added the "fail if no proper CPU found" feature, which is helpful for the ACPI P-States driver and some other x86 drivers which only check whether they can run on _any_ CPU in the cpu-specific initialization call. To assert backwards-compatibility, this flag avoids "automatic unregistration" -- I wasn't aware some drivers do need this backwards compatibility, but obviously ARM needs it. So Russell's patch looks to be what's needed, from my perspective.