support for CPUFREQ_ETERNAL drivers by the ondemand governor

Hello,

For now the ondemand governor doesn't support the drivers which reports a transition latency of CPUFREQ_ETERNAL. That's really a problem because most of the drivers declare such a latency (simply because it's not known, not really because the transition will take an eternal time). All userspace daemons suport those drivers, they just don't pay attention to the transition latency.

This patch proposes to consider a CPUFREQ_ETERNAL latency as the maximum possible latency of the governor (10 ms). I think this should be conservative enough to be safe with any driver.

On Sun, Feb 06, 2005 at 11:33:49PM +0100, Eric Piel wrote:

Quoted 1 line

This patch proposes to consider a CPUFREQ_ETERNAL latency as the maximum possible latency of the governor (10 ms). I think this should be conservative enough to be safe with any driver.

No. CPUFREQ_ETERNAL is there to assert no dynamic frequency governor runs with this driver. If a driver is safe to run on dynamic frequency governors like ondemand, fix the latency value instead.

Hi,

Quoted 1 line · Eric Piel

Here is my third try to get speedstep-ich compatible with the ondemand governor. Taking into account the comments of Dominik I've gone through the intel documentation in order to get the transition latency depending on the processor.

Thanks for doing so!

Review

Quoted 2 lines

(quoted diff) +2 -0

+	case SPEEDSTEP_PROCESSOR_PIII_T:
+		/* Max 100??s, according to intel's 29834006.pdf p.22 */

			  ^^

The greek sign in microsecond can't be printed well, so I suggest you use "us" instead.

Review

Quoted 1 line

(quoted diff) +1 -0

+		 * Max ~42??s -> 50??s, according to intel's 25068607.pdf p.40 and p.50

			  ^^       ^^

same here.

Other than that, it'd be great if you, Venki, could take a look at the technical side of this. Because of the cpufreq list still being down, I attached the message in full below.

Quoted 62 lines

While for the centrino processors such information is clearly written, this was not the case for the processors managed by speedstep-ich. I did my best to understand the electrical timing descriptions and the results look realistic, but I can't guaranty 100% certainty. At least, the code hasn't destroyed my pentium coppermine yet ;-)

It's against 2.6.13, hope you like it...

Eric

--
Set the transition latency of speedstep-ich depending on the processor, using information taken from intel's manuals.

Signed-off-by Eric Piel <[email protected]>

--

arch/i386/kernel/cpu/cpufreq/speedstep-ich.c renamed from arch/i386/kernel/cpu/cpufreq/speedstep-ich.c.bak +31 -1

@@ -301,6 +301,35 @@ static int speedstep_verify (struct cpuf
 }
 
 
+/**
+ * speedstep_get_transition_latency - returns the maximum transition latency
+ * of the current processor
+ * @processor: type of processor
+ *
+ * The CPU transition latency depends on the type of CPU, so we get it
+ * from a database.
+ */
+static unsigned int speedstep_get_transition_latency(unsigned int processor)
+{
+	switch (processor) {
+	case SPEEDSTEP_PROCESSOR_PIII_C:
+	case SPEEDSTEP_PROCESSOR_PIII_C_EARLY:
+		/* According to intel's p3_ds.pdf p.23 and table 22, similar to PIII_T */
+	case SPEEDSTEP_PROCESSOR_PIII_T:
+		/* Max 100??s, according to intel's 29834006.pdf p.22 */
+		return 100000;
+	case SPEEDSTEP_PROCESSOR_P4M:
+		/* 
+		 * Depends on the bus clock, which should be at least 100MHz.
+		 * Max ~42??s -> 50??s, according to intel's 25068607.pdf p.40 and p.50
+		 */
+		return 50000;
+	default:
+		/* No info has yet be found, so we are conservative */
+		return CPUFREQ_ETERNAL;
+	}
+}
+
 static int speedstep_cpu_init(struct cpufreq_policy *policy)
 {
 	int result = 0;

@@ -335,7 +364,8 @@ static int speedstep_cpu_init(struct cpu
 
 	/* cpuinfo and default policy values */
 	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+	policy->cpuinfo.transition_latency = 
+		speedstep_get_transition_latency(speedstep_processor);
 	policy->cur = speed;
 
 	result = cpufreq_frequency_table_cpuinfo(policy, speedstep_freqs);