[-mm PATCH] time: reduced ntp rework part 2 - remove duplicate leapsecond code

[-mm PATCH] time: reduced ntp rework part 2 - remove duplicate leapsecond code

[john stultz]

Hey Andrew,
	Just wanted to sync up with you before I do a B20 release of the TOD
code. 

The reduced ntp rework patch part 2 adds a new ntp_leapsecond() which
should replace the existing leapsecond processing. However somehow the
chunk which removes the old code got dropped. Probably my fault.

Without this patch, its possible the leapsecond TIME_OOP state would not
be set for the second following a insertion.

thanks
-john


Index: mmmerge/kernel/timer.c
===================================================================
--- mmmerge.orig/kernel/timer.c
+++ mmmerge/kernel/timer.c
@@ -694,58 +694,6 @@ static void second_overflow(void)
 	}
 
 	/*
-	 * Leap second processing. If in leap-insert state at the end of the
-	 * day, the system clock is set back one second; if in leap-delete
-	 * state, the system clock is set ahead one second. The microtime()
-	 * routine or external clock driver will insure that reported time is
-	 * always monotonic. The ugly divides should be replaced.
-	 */
-	switch (time_state) {
-	case TIME_OK:
-		if (time_status & STA_INS)
-			time_state = TIME_INS;
-		else if (time_status & STA_DEL)
-			time_state = TIME_DEL;
-		break;
-	case TIME_INS:
-		if (xtime.tv_sec % 86400 == 0) {
-			xtime.tv_sec--;
-			wall_to_monotonic.tv_sec++;
-			/*
-			 * The timer interpolator will make time change
-			 * gradually instead of an immediate jump by one second
-			 */
-			time_interpolator_update(-NSEC_PER_SEC);
-			time_state = TIME_OOP;
-			clock_was_set();
-			printk(KERN_NOTICE "Clock: inserting leap second "
-					"23:59:60 UTC\n");
-		}
-		break;
-	case TIME_DEL:
-		if ((xtime.tv_sec + 1) % 86400 == 0) {
-			xtime.tv_sec++;
-			wall_to_monotonic.tv_sec--;
-			/*
-			 * Use of time interpolator for a gradual change of
-			 * time
-			 */
-			time_interpolator_update(NSEC_PER_SEC);
-			time_state = TIME_WAIT;
-			clock_was_set();
-			printk(KERN_NOTICE "Clock: deleting leap second "
-					"23:59:59 UTC\n");
-		}
-		break;
-	case TIME_OOP:
-		time_state = TIME_WAIT;
-		break;
-	case TIME_WAIT:
-		if (!(time_status & (STA_INS | STA_DEL)))
-		time_state = TIME_OK;
-	}
-
-	/*
 	 * Compute the phase adjustment for the next second. In PLL mode, the
 	 * offset is reduced by a fixed factor times the time constant. In FLL
 	 * mode the offset is used directly. In either mode, the maximum phase

[-mm PATCH] time: i386 conversion part 3 - lock jiffies_64 manipulation

[john stultz]

Hey Andrew,

This should merge TOD my changes with Atsushi's jiffies/jiffies_64 fix
that is in your tree.

thanks
-john

Signed-off-by: John Stultz <johnstul@us.ibm.com>

diff -ru mmmerge/arch/i386/kernel/time.c mytree/arch/i386/kernel/time.c
--- mmmerge/arch/i386/kernel/time.c	2006-03-03 19:44:22.000000000 -0800
+++ mytree/arch/i386/kernel/time.c	2006-03-03 19:44:45.000000000 -0800
@@ -266,6 +266,7 @@
 
 static int timer_resume(struct sys_device *dev)
 {
+	unsigned long flags;
 	unsigned long sec;
 	unsigned long sleep_length;
 
@@ -276,8 +277,10 @@
 	setup_pit_timer();
 	sec = get_cmos_time() + clock_cmos_diff;
 	sleep_length = (get_cmos_time() - sleep_start) * HZ;
+	write_seqlock_irqsave(&xtime_lock, flags);
 	jiffies_64 += sleep_length;
 	wall_jiffies += sleep_length;
+	write_sequnlock_irqrestore(&xtime_lock, flags);
 	touch_softlockup_watchdog();
 	return 0;
 }

[-mm PATCH] time: i386 clocksource drivers - drop acpi_pm_buggy paranoia

[john stultz]

	As pointed out by Adrian Bunk, I was a bit paranoid with the acpi_pm.c
code and included code to work around buggy chipset's acpi pm
implementations. Andi Kleen convinced me that its not worth punishing
all systems for it, so I left the code disabled thinking I'd re-enable
it via a DMI blacklist when problematic systems surfaced. However, since
the code is not enabled, this removes it from the patch, as it can be
easily re-added if such a system does show up.

thanks
-john

Signed-off-by: John Stultz <johnstul@us.ibm.com>

diff -ru mmmerge/drivers/clocksource/acpi_pm.c mytree/drivers/clocksource/acpi_pm.c
--- mmmerge/drivers/clocksource/acpi_pm.c	2006-03-03 19:44:22.000000000 -0800
+++ mytree/drivers/clocksource/acpi_pm.c	2006-03-03 19:44:45.000000000 -0800
@@ -30,7 +30,6 @@
  * in arch/i386/acpi/boot.c
  */
 u32 pmtmr_ioport;
-int acpi_pmtmr_buggy;
 
 #define ACPI_PM_MASK 0xFFFFFF /* limit it to 24 bits */
 
@@ -40,26 +39,6 @@
 	return inl(pmtmr_ioport) & ACPI_PM_MASK;
 }
 
-static cycle_t acpi_pm_read_verified(void)
-{
-	u32 v1 = 0, v2 = 0, v3 = 0;
-
-	/*
-	 * It has been reported that because of various broken
-	 * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM clock
-	 * source is not latched, so you must read it multiple
-	 * times to ensure a safe value is read:
-	 */
-	do {
-		v1 = read_pmtmr();
-		v2 = read_pmtmr();
-		v3 = read_pmtmr();
-	} while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
-			|| (v3 > v1 && v3 < v2));
-
-	return (cycle_t)v2;
-}
-
 static cycle_t acpi_pm_read(void)
 {
 	return (cycle_t)read_pmtmr();
@@ -104,12 +83,6 @@
 
 pm_good:
 
-	/* check to see if pmtmr is known buggy: */
-	if (acpi_pmtmr_buggy) {
-		clocksource_acpi_pm.read = acpi_pm_read_verified;
-		clocksource_acpi_pm.rating = 110;
-	}
-
 	return register_clocksource(&clocksource_acpi_pm);
 }