cvs commit: src/sys/i386/cpufreq p4tcc.c

[Nate Lawson]

Maxim Sobolev wrote:
> Nate Lawson wrote:
> 
>> njl         2005-02-23 16:42:56 UTC
>>
>>   FreeBSD src repository
>>
>>   Modified files:
>>     sys/i386/cpufreq     p4tcc.c   Log:
>>   Import a rewrite of p4tcc for the cpufreq(4) framework.  This includes
>>   a bugfix of clearing the On-Demand flag when going back to 100%.  It
> 
> I don't think this counts as a bugfix, moreover I don't see any need for 
> additional logic to do this, since clearing on-demand flag is the same 
> as setting 100%. In both those cases performance is 100% and throttling 
> only kicks in when CPU overheats.

The original p4tcc.c never cleared the On-Demand flag.  Instead, it just 
set the 3-bit field to zero in the 100% case.  I'm not sure if that 
worked on some systems, but on my R32, this gave the same performance as 
the 12.5% setting, not 100%.  However, clearing the On-Demand flag did 
pull it back up to 100% performance, hence it was a bugfix.  This 
matches the Intel documentation in that it only mentions the user being 
able to set values from 87.5% to 12.5% when On-Demand is set, no 100% 
value.  (In other words, a setting of 0 in On-Demand mode is undefined).

Here is the info from section 6.1.2 of the P4-Mobile datasheet:

"When using On-Demand mode to activate the TCC, the duty cycle of the 
clock modulation is programmable via bits 3:1 of the same ACPI Thermal 
Monitor Control register. In automatic mode, the duty cycle is fixed, 
however in On-Demand mode, the duty cycle can be programmed from 12.5% 
on/ 87.5% off, to 87.5% on/12.5% off in 12.5% increments."

However, this is still not perfect in that if a high thermal condition 
occurs, we can be at 50% performance no matter what On-Demand is set to. 
  I added an XXX comment for this.  In practice, a system that is 
bumping up against the Automatic thermal trip point a few seconds after 
boot is not going to be concerned about the announced values for cpufreq 
being low by 50%.

-- 
Nate