summaryrefslogtreecommitdiffstats
path: root/arch/x86_64/kernel/time.c
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] x86_64: Fix get_cmos_time()Jan Beulich2006-01-111-7/+4
| | | | | | | | | | | | | Due to a broken condition, the body of the loop that is intended to wait for the Update-In-Progress bit to get set and then cleared again was never entered; in fact, the entire loop was optimized out by the compiler. Here is a change to fix the condition (and to also move the initialization of locals out of the spin lock protected region). Signed-Off-By: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: No need to export get_cmos_time anymoreAndi Kleen2006-01-111-1/+1
| | | | | | | | | | | It was only needed for APM Pointed out by Jan Beulich Cc: jbeulich@novell.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fix up white space in time.cAndi Kleen2006-01-111-39/+32
| | | | | | | | | No functional changes. And remove one redundant prototype. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: On Intel CPUs don't do an additional CPU sync before RDTSCAndi Kleen2006-01-111-19/+7
| | | | | | | | | | | RDTSC serialization using cpuid is not needed for Intel platforms. This increases gettimeofday performance. Cc: vojtech@suse.cz Cc: rohit.seth@intel.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Don't try to synchronize the TSC over CPUs on Intel CPUs at ↵Andi Kleen2006-01-111-2/+2
| | | | | | | | | | | | | boot. They already do this in hardware and the Linux algorithm actually adds errors. Cc: mingo@elte.hu Cc: rohit.seth@intel.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Handle missing local APIC timer interrupts on C3 stateVenkatesh Pallipadi2006-01-111-0/+5
| | | | | | | | | | | | Whenever we see that a CPU is capable of C3 (during ACPI cstate init), we disable local APIC timer and switch to using a broadcast from external timer interrupt (IRQ 0). Patch below adds the code for x86_64. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] move rtc_interrupt() prototype to rtc.hAdrian Bunk2006-01-081-2/+0
| | | | | | | | | | | | | | | This patch moves the rtc_interrupt() prototype to rtc.h and removes the prototypes from C files. It also renames static rtc_interrupt() functions in arch/arm/mach-integrator/time.c and arch/sh64/kernel/time.c to avoid compile problems. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Paul Gortmaker <p_gortmaker@yahoo.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Fix collision between pmtimer and pit/hpetjohn stultz2005-12-121-1/+1
| | | | | | | | | | | | | | On systems that do not support the HPET legacy functions (basically the IBM x460, but there could be others), in time_init() we accidentally fall into a PM timer conditional and set the vxtime_hz value to the PM timer's frequency. We then use this value with the HPET for timekeeping. This patch (which mimics the behavior in time_init_gtod) corrects the collision. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Make sure hpet_address is 0 when any part of HPET ↵Andi Kleen2005-12-121-1/+3
| | | | | | | | | | initialization fails Otherwise TSC->HPET fallback could see incorrect state and crash later. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] hpet-RTC: cache the comparator registerClemens Ladisch2005-10-301-1/+4
| | | | | | | | | | | | Reads from an HPET register require a round trip to the south bridge and are almost as slow as PCI reads. By caching the last value we've written to the comparator register, we can eliminate all HPET reads from the fast path in the emulated RTC interrupt handler. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] hpet-RTC: fix timer config register accessesClemens Ladisch2005-10-301-7/+2
| | | | | | | | | | | | | | | | Make sure that the RTC timer is in non-periodic mode; some stupid BIOS might have initialized it to periodic mode. Furthermore, don't set the SETVAL bit in the config register. This wouldn't have any effect unless the timer was in period mode (which it isn't), and then the actual timer frequency would be half that of the desired one because incrementing the comparator in the interrupt handler would be done after the hardware has already incremented it itself. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] hpet-RTC: disable interrupt when no longer neededClemens Ladisch2005-10-301-1/+5
| | | | | | | | | | | | | | | When the emulated RTC interrupt is no longer needed, we better disable it; otherwise, we get a spurious interrupt whenever the timer has rolled over and reaches the same comparator value. Having a superfluous interrupt every five minutes doesn't hurt much, but it's bad style anyway. ;-) Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Acked-by: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] jiffies_64 cleanupThomas Gleixner2005-10-301-4/+0
| | | | | | | | | Define jiffies_64 in kernel/timer.c rather than having 24 duplicated defines in each architecture. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] i386 and x86_64 TSC set_cyc2ns_scale imprecisionMathieu Desnoyers2005-10-301-4/+4
| | | | | | | | | | | | | | | | | I just found out that some precision is unnecessarily lost in the arch/i386/kernel/timers/timer_tsc.c:set_cyc2ns_scale function. It uses a cpu_mhz parameter when it could use a cpu_khz. In the specific case of an Intel P4 running at 3001.171 Mhz, the truncation to 3001 Mhz leads to an imprecision of 19 microseconds per second : this is very sad for a timer with nearly nanosecond accuracy. Fix the x86_64 architecture too. Cc: george anzinger <george@mvista.com> Cc: john stultz <johnstul@us.ibm.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86-64: Fix bad assumption that dualcore cpus have synced TSCsjohn stultz2005-09-281-3/+0
| | | | | | | | | | | | | | | | | This should resolve the issue seen in bugme bug #5105, where it is assumed that dualcore x86_64 systems have synced TSCs. This is not the case, and alternate timesources should be used instead. For more details, see: http://bugzilla.kernel.org/show_bug.cgi?id=5105 Andi's earlier concerns that the TSCs should be synced on dualcore systems have been resolved by confirmation from AMD folks that they can be unsynced. Acked-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86-64: more gratitious linux/irq.h includesAl Viro2005-09-121-1/+0
| | | | | | | ... and with that all instances in arch/x86_64 are gone. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86-64: Remove unused vxtime.hz fieldAndi Kleen2005-09-121-1/+0
| | | | | Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] NTP: ntp-helper functionsjohn stultz2005-09-071-5/+2
| | | | | | | | | | | | | | | | This patch cleans up a commonly repeated set of changes to the NTP state variables by adding two helper inline functions: ntp_clear(): Clears the ntp state variables ntp_synced(): Returns 1 if the system is synced with a time server. This was compile tested for alpha, arm, i386, x86-64, ppc64, s390, sparc, sparc64. Signed-off-by: John Stultz <johnstul@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] detect soft lockupsIngo Molnar2005-09-071-0/+1
| | | | | | | | | | | | | | | | | | | This patch adds a new kernel debug feature: CONFIG_DETECT_SOFTLOCKUP. When enabled then per-CPU watchdog threads are started, which try to run once per second. If they get delayed for more than 10 seconds then a callback from the timer interrupt detects this condition and prints out a warning message and a stack dump (once per lockup incident). The feature is otherwise non-intrusive, it doesnt try to unlock the box in any way, it only gets the debug info out, automatically, and on all CPUs affected by the lockup. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de> Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: fix hpet for systems that don't support legacy replacementjohn stultz2005-06-231-14/+28
| | | | | | | | | | | | | | | | | | | | Currently the x86-64 HPET code assumes the entire HPET implementation from the spec is present. This breaks on boxes that do not implement the optional legacy timer replacement functionality portion of the spec. This patch fixes this issue, allowing x86-64 systems that cannot use the HPET for the timer interrupt and RTC to still use the HPET as a time source. I've tested this patch on a system systems without HPET, with HPET but without legacy timer replacement, as well as HPET with legacy timer replacement. This version adds a minor check to cap the HPET counter value in gettimeoffset_hpet to avoid possible time inconsistencies. Please ignore the A2 version I sent to you earlier. Acked-by: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: More fixes for compilation without CONFIG_ACPIAndi Kleen2005-05-311-0/+2
| | | | | | | | Suggested by Alexander Nyberg Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Add pmtimer supportAndi Kleen2005-05-171-17/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | There are unfortunately more and more multi processor Opteron systems which don't have HPET timer support in the southbridge. This covers in particular Nvidia and VIA chipsets. They also don't guarantee that the TSCs are synchronized between CPUs; and especially with MP powernow the systems are nearly unusable because the time gets very inconsistent between CPUs. The timer code for x86-64 was originally written under the assumption that we could fall back to the HPET timer on such systems. But this doesn't work there. Another alternative is to use the ACPI PM timer as primary time source. This patch does that. The kernel only uses PM timer when there is no other choice because it has some disadvantages. Ported over from i386. It should be faster than the i386 version because I dropped the "read three times" workaround, but is still considerable slower than HPET and also does not work together with vsyscalls which have to be disabled. Cc: <mark.langsdorf@amd.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix u32 vs. pm_message_t in x86-64Pavel Machek2005-04-161-1/+1
| | | | | | | | | I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that turned out not to be the case... Here are fixes x86-64. Signed-off-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Switch SMP bootup over to new CPU hotplug state machineAndi Kleen2005-04-161-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow hotplug CPU in the future and in general cleans up a lot of crufty code. It also should plug some races that the old hackish way introduces. Remove one old race workaround in NMI watchdog setup that is not needed anymore. I removed the old total sum of bogomips reporting code. The brag value of BogoMips has been greatly devalued in the last years on the open market. Real CPU hotplug will need some more work, but the infrastructure for it is there now. One drawback: the new TSC sync algorithm is less accurate than before. The old way of zeroing TSCs is too intrusive to do later. Instead the TSC of the BP is duplicated now, which is less accurate. akpm: - sync_tsc_bp_init seems to have the sense of `init' inverted. - SPIN_LOCK_UNLOCKED is deprecated - use DEFINE_SPINLOCK. Cc: <rusty@rustcorp.com.au> Cc: <mingo@elte.hu> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] x86_64: Support constantly ticking TSCsAndi Kleen2005-04-161-2/+3
| | | | | | | | | | | | On Intel Noconas the TSC ticks with a constant frequency. Don't scale the factor used by udelay when cpufreq changes the frequency. This generalizes an earlier patch by Intel for this. Cc: <venkatesh.pallipadi@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+1262
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud