Re: [PATCH] transition latency of speedstep-ich (third try)

[Eric Piel <Eric.Piel@tremplin-utc.net>]

19.09.2005 12:18, Dominik Brodowski wrote/a écrit:
> Hi,
> 
> On Sun, Sep 18, 2005 at 11:15:09PM +0200, Eric Piel wrote:
> 
>>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!
> 
> 
>>+	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.
> 
> 
>>+		 * Max ~42??s -> 50??s, according to intel's 25068607.pdf p.40 and p.50
> 
> 			  ^^       ^^
> same here.
Ok, sorry, just forgot it was not an ASCII character (even xterm 
supports UTF-8 nowadays ;-) ). I'll resend as soon as I get the answer 
from Venki.

> 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.
Indeed, Venki, I would be extremely thanksfull if you could validate 
those numbers. To sum up, could you confirm that the transition latency 
between two frequencies never exeeds:
* 100us for Coppermine and Tualatin
* 50us for Pentium 4 M

Cheers
Eric



> 
>>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 <eric.piel@tremplin-utc.net>
>>--
> 
> 
>>--- linux-2.6.13/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c.bak	2005-08-08 10:14:35.000000000 +0200
>>+++ linux-2.6.13/arch/i386/kernel/cpu/cpufreq/speedstep-ich.c	2005-09-17 12:50:27.000000000 +0200
>>@@ -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);