--- /dev/null
+
+*************************************************************
+AMD
+http://lkml.org/lkml/2005/11/4/173
+http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF
+http://developer.amd.com/article_print.jsp?id=92 (RH)
+
+[7] AMD's 7th generation processors return a CPUID base
+ family value of '7'. These include AMD Athlon, AthlonXP,
+ AthlonMP, and Duron.
+
+[8] AMD's 8th generation processors return an effective
+ CPUID family of '0x0F'. These include AMD Opteron,
+ Athlon64, and Turion.
+
+
+before 7th gen : ok
+7th gen:
+ P-state (performance state) change
+ sol : disable powernow
+ STPCLK-Throttling (temperature) : only done on UP, ok
+8th gen :
+ P-state change
+ dual-core : locked-step
+ SMP : may drift
+ sol : disable powernow
+ SMP, dual core : C1-clock ramping (halt) (power state : C-state)
+ sol : idle=poll or disable C1-ramping
+ STPCLK-Throttling (temperature) :
+ single processor dual-core ok
+ SMP : NOT ok (rare)
+
+
+Until TSC becomes invariant, AMD recommends that operating
+system developers avoid TSC as a fast timer source on
+affected systems. (AMD recommends that the operating system
+should favor these time sources in a prioritized manner:
+HPET first, then ACPI PM Timer, then PIT.) The following
+pseudo-code shows one way of determining when to use TSC:
+
+ use_AMD_TSC() { // returns TRUE if ok to use TSC
+ if (CPUID.base_family < 0xf) {
+ // TSC drift doesn't exist on 7th Gen or less
+ // However, OS still needs to consider effects
+ // of P-state changes on TSC
+ return TRUE;
+ } else if (CPUID.AdvPowerMgmtInfo.TscInvariant) {
+ // Invariant TSC on 8th Gen or newer, use it
+ // (assume all cores have invariant TSC)
+ return TRUE;
+ } else if ((number_processors == 1)&&(number_cores == 1)){
+ // OK to use TSC on uni-processor-uni-core
+ // However, OS still needs to consider effects
+ // of P-state changes on TSC
+ return TRUE;
+ } else if ( (number_processors == 1) &&
+ (CPUID.effective_family == 0x0f) &&
+ !C1_ramp_8gen ){
+ // Use TSC on 8th Gen uni-proc with C1_ramp off
+ // However, OS still needs to consider effects
+ // of P-state changes on TSC
+ return TRUE;
+ } else {
+ return FALSE;
+ }
+ }
+ C1_ramp_8gen() {
+ // Check if C1-Clock ramping enabled in PMM7.CpuLowPwrEnh
+ // On 8th-Generation cores only. Assume BIOS has setup
+ // all Northbridges equivalently.
+ return (1 & read_pci_byte(bus=0,dev=0x18,fcn=3,offset=0x87));
+ }
+
+
+When an operating system can not avoid using TSC in the
+short-term, the operating system will need to either
+re-synchronize the TSC of the halted core when exiting halt
+or disable C1-clock ramping. The pseudo-code for disabling
+C1-clock ramping follows:
+
+ if ( !use_AMD_TSC() &&
+ (CPUID.effective_family == 0x0f) &&
+ C1_ramp_8gen() ){
+ for (i=0; i < number_processors; ++i){
+ // Do for all NorthBridges in platform
+ tmp = read_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87);
+ tmp &= 0xFC; // clears pmm7[1:0]
+ write_pci_byte(bus=0,dev=0x18+i,fcn=3,offset=0x87,tmp)
+ }
+ }
+
+
+Future TSC Directions and Solutions
+===================================
+Future AMD processors will provide a TSC that is P-state and
+C-State invariant and unaffected by STPCLK-throttling. This
+will make the TSC immune to drift. Because using the TSC
+for fast timer APIs is a desirable feature that helps
+performance, AMD has defined a CPUID feature bit that
+software can test to determine if the TSC is
+invariant. Issuing a CPUID instruction with an %eax register
+value of 0x8000_0007, on a processor whose base family is
+0xF, returns "Advanced Power Management Information" in the
+%eax, %ebx, %ecx, and %edx registers. Bit 8 of the return
+%edx is the "TscInvariant" feature flag which is set when
+TSC is P-state, C-state, and STPCLK-throttling invariant; it
+is clear otherwise.
+
+The rate of the invariant TSC is implementation-dependent
+and will likely *not* be the frequency of the processor
+core; however, its period should be short enough such that
+it is not possible for two back-to-back rdtsc instructions
+to return the same value. Software which is trying to
+measure actual processor frequency or cycle-performance
+should use Performance Event 76h, CPU Clocks not Halted,
+rather than the TSC to count CPU cycles.
+
+
+
+*************************************************************
+Intel
+
+Pentium M
+ family [06H], models [09H, 0DH]
+ SOL : disable speedstep
+Pentium 4 processors, Intel Xeon
+ family [0FH], models [00H, 01H, or 02H]
+ SOL : disable speedstep
+
+Other : ok
+
+http://download.intel.com/design/Xeon/specupdt/30675712.pdf
+http://forum.rightmark.org/post.cgi?id=print:6:269&user=%20Dmitri%20Besedin&color=1
+http://bochs.sourceforge.net/techspec/24161821.pdf cpuid
+
+cpuz
+AFAIK this problem only concerns Prescott CPUs, but I bet future production will
+also use the same rule.
+
+Well, from what Intel states in one of their docs (Intel(R) Pentium(R) M
+Processor on 90 nm Process with 2-MB L2 Cache, Specification Update, Document
+No. 302209-010 (http://www.intel.com/design/mobile/specupdt/302209.htm) ), your
+supposition is true:
+
+
+Article V. For Pentium M processors (family [06H], models [09H, 0DH]); for
+Pentium 4 processors, Intel Xeon processors (family [0FH], models [00H, 01H, or
+02H]); and for P6 family processors: the timestamp counter increments with every
+internal processor clock cycle. The internal processor clock cycle is determined
+by the current core-clock to bus-clock ratio. Intel(R) SpeedStep(R) technology
+transitions may also impact the processor clock.
+
+Article VI. For Pentium 4 processors, Intel Xeon processors (family [0FH],
+models [03H and higher]): the time-stamp counter increments at a constant rate.
+That rate may be set by the maximum core-clock to bus-clock ratio of the
+processor or may be set by the frequency at which the processor is booted. The
+specific processor configuration determines the behavior. Constant TSC behavior
+ensures that the duration of each clock tick is uniform and supports the use of
+the TSC as a wall clock timer even if the processor core changes frequency. This
+is the architectural behavior moving forward.
+
+
+It's a pity they call this sucking TSC behavior an "architectural behavior
+moving forward"
+
+
+
+*************************************************************
+HPET
+
+http://www.intel.com/hardwaredesign/hpetspec_1.pdf
+
+
+
+
projects / lttv.git / commitdiff
