[PATCH 1/10] NTP: Remove pps support

[PATCH 1/10] NTP: Remove pps support

[Roman Zippel]

This removes the support for pps. It's completely unused within the
kernel and is basically in the way for further cleanups. It should be
easier to readd proper support for it after the rest has been converted
to NTP4.
Patch is originally done by John Stultz, I did some minor cleanups and
updated it.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

---

 include/linux/timex.h |   41 ----------------------------------
 kernel/time.c         |   59 +++++++++++++-------------------------------------
 kernel/timer.c        |   13 +----------
 3 files changed, 18 insertions(+), 95 deletions(-)

Index: linux-2.6-mm/include/linux/timex.h
===================================================================
--- linux-2.6-mm.orig/include/linux/timex.h	2005-12-21 12:10:36.000000000 +0100
+++ linux-2.6-mm/include/linux/timex.h	2005-12-21 12:11:48.000000000 +0100
@@ -97,38 +97,11 @@
 
 #define MAXPHASE 512000L        /* max phase error (us) */
 #define MAXFREQ (512L << SHIFT_USEC)  /* max frequency error (ppm) */
-#define MAXTIME (200L << PPS_AVG) /* max PPS error (jitter) (200 us) */
 #define MINSEC 16L              /* min interval between updates (s) */
 #define MAXSEC 1200L            /* max interval between updates (s) */
 #define	NTP_PHASE_LIMIT	(MAXPHASE << 5)	/* beyond max. dispersion */
 
 /*
- * The following defines are used only if a pulse-per-second (PPS)
- * signal is available and connected via a modem control lead, such as
- * produced by the optional ppsclock feature incorporated in the Sun
- * asynch driver. They establish the design parameters of the frequency-
- * lock loop used to discipline the CPU clock oscillator to the PPS
- * signal.
- *
- * PPS_AVG is the averaging factor for the frequency loop, as well as
- * the time and frequency dispersion.
- *
- * PPS_SHIFT and PPS_SHIFTMAX specify the minimum and maximum
- * calibration intervals, respectively, in seconds as a power of two.
- *
- * PPS_VALID is the maximum interval before the PPS signal is considered
- * invalid and protocol updates used directly instead.
- *
- * MAXGLITCH is the maximum interval before a time offset of more than
- * MAXTIME is believed.
- */
-#define PPS_AVG 2		/* pps averaging constant (shift) */
-#define PPS_SHIFT 2		/* min interval duration (s) (shift) */
-#define PPS_SHIFTMAX 8		/* max interval duration (s) (shift) */
-#define PPS_VALID 120		/* pps signal watchdog max (s) */
-#define MAXGLITCH 30		/* pps signal glitch max (s) */
-
-/*
  * syscall interface - used (mainly by NTP daemon)
  * to discipline kernel clock oscillator
  */
@@ -246,20 +219,6 @@ extern long time_reftime;	/* time at las
 extern long time_adjust;	/* The amount of adjtime left */
 extern long time_next_adjust;	/* Value for time_adjust at next tick */
 
-/* interface variables pps->timer interrupt */
-extern long pps_offset;		/* pps time offset (us) */
-extern long pps_jitter;		/* time dispersion (jitter) (us) */
-extern long pps_freq;		/* frequency offset (scaled ppm) */
-extern long pps_stabil;		/* frequency dispersion (scaled ppm) */
-extern long pps_valid;		/* pps signal watchdog counter */
-
-/* interface variables pps->adjtimex */
-extern int pps_shift;		/* interval duration (s) (shift) */
-extern long pps_jitcnt;		/* jitter limit exceeded */
-extern long pps_calcnt;		/* calibration intervals */
-extern long pps_errcnt;		/* calibration errors */
-extern long pps_stbcnt;		/* stability limit exceeded */
-
 /**
  * ntp_clear - Clears the NTP state variables
  *
Index: linux-2.6-mm/kernel/time.c
===================================================================
--- linux-2.6-mm.orig/kernel/time.c	2005-12-21 12:10:37.000000000 +0100
+++ linux-2.6-mm/kernel/time.c	2005-12-21 12:11:48.000000000 +0100
@@ -198,24 +198,6 @@ asmlinkage long sys_settimeofday(struct 
 	return do_sys_settimeofday(tv ? &new_ts : NULL, tz ? &new_tz : NULL);
 }
 
-long pps_offset;		/* pps time offset (us) */
-long pps_jitter = MAXTIME;	/* time dispersion (jitter) (us) */
-
-long pps_freq;			/* frequency offset (scaled ppm) */
-long pps_stabil = MAXFREQ;	/* frequency dispersion (scaled ppm) */
-
-long pps_valid = PPS_VALID;	/* pps signal watchdog counter */
-
-int pps_shift = PPS_SHIFT;	/* interval duration (s) (shift) */
-
-long pps_jitcnt;		/* jitter limit exceeded */
-long pps_calcnt;		/* calibration intervals */
-long pps_errcnt;		/* calibration errors */
-long pps_stbcnt;		/* stability limit exceeded */
-
-/* hook for a loadable hardpps kernel module */
-void (*hardpps_ptr)(struct timeval *);
-
 /* we call this to notify the arch when the clock is being
  * controlled.  If no such arch routine, do nothing.
  */
@@ -275,7 +257,7 @@ int do_adjtimex(struct timex *txc)
 		    result = -EINVAL;
 		    goto leave;
 		}
-		time_freq = txc->freq - pps_freq;
+		time_freq = txc->freq;
 	    }
 
 	    if (txc->modes & ADJ_MAXERROR) {
@@ -308,10 +290,8 @@ int do_adjtimex(struct timex *txc)
 		    if ((time_next_adjust = txc->offset) == 0)
 			 time_adjust = 0;
 		}
-		else if ( time_status & (STA_PLL | STA_PPSTIME) ) {
-		    ltemp = (time_status & (STA_PPSTIME | STA_PPSSIGNAL)) ==
-		            (STA_PPSTIME | STA_PPSSIGNAL) ?
-		            pps_offset : txc->offset;
+		else if (time_status & STA_PLL) {
+		    ltemp = txc->offset;
 
 		    /*
 		     * Scale the phase adjustment and
@@ -352,23 +332,14 @@ int do_adjtimex(struct timex *txc)
 		    }
 		    time_freq = min(time_freq, time_tolerance);
 		    time_freq = max(time_freq, -time_tolerance);
-		} /* STA_PLL || STA_PPSTIME */
+		} /* STA_PLL */
 	    } /* txc->modes & ADJ_OFFSET */
 	    if (txc->modes & ADJ_TICK) {
 		tick_usec = txc->tick;
 		tick_nsec = TICK_USEC_TO_NSEC(tick_usec);
 	    }
 	} /* txc->modes */
-leave:	if ((time_status & (STA_UNSYNC|STA_CLOCKERR)) != 0
-	    || ((time_status & (STA_PPSFREQ|STA_PPSTIME)) != 0
-		&& (time_status & STA_PPSSIGNAL) == 0)
-	    /* p. 24, (b) */
-	    || ((time_status & (STA_PPSTIME|STA_PPSJITTER))
-		== (STA_PPSTIME|STA_PPSJITTER))
-	    /* p. 24, (c) */
-	    || ((time_status & STA_PPSFREQ) != 0
-		&& (time_status & (STA_PPSWANDER|STA_PPSERROR)) != 0))
-	    /* p. 24, (d) */
+leave:	if ((time_status & (STA_UNSYNC|STA_CLOCKERR)) != 0)
 		result = TIME_ERROR;
 	
 	if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
@@ -376,7 +347,7 @@ leave:	if ((time_status & (STA_UNSYNC|ST
 	else {
 	    txc->offset = shift_right(time_offset, SHIFT_UPDATE);
 	}
-	txc->freq	   = time_freq + pps_freq;
+	txc->freq	   = time_freq;
 	txc->maxerror	   = time_maxerror;
 	txc->esterror	   = time_esterror;
 	txc->status	   = time_status;
@@ -384,14 +355,16 @@ leave:	if ((time_status & (STA_UNSYNC|ST
 	txc->precision	   = time_precision;
 	txc->tolerance	   = time_tolerance;
 	txc->tick	   = tick_usec;
-	txc->ppsfreq	   = pps_freq;
-	txc->jitter	   = pps_jitter >> PPS_AVG;
-	txc->shift	   = pps_shift;
-	txc->stabil	   = pps_stabil;
-	txc->jitcnt	   = pps_jitcnt;
-	txc->calcnt	   = pps_calcnt;
-	txc->errcnt	   = pps_errcnt;
-	txc->stbcnt	   = pps_stbcnt;
+
+	/* PPS is not implemented, so these are zero */
+	txc->ppsfreq	   = 0;
+	txc->jitter	   = 0;
+	txc->shift	   = 0;
+	txc->stabil	   = 0;
+	txc->jitcnt	   = 0;
+	txc->calcnt	   = 0;
+	txc->errcnt	   = 0;
+	txc->stbcnt	   = 0;
 	write_sequnlock_irq(&xtime_lock);
 	do_gettimeofday(&txc->time);
 	notify_arch_cmos_timer();
Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2005-12-21 12:10:37.000000000 +0100
+++ linux-2.6-mm/kernel/timer.c	2005-12-21 12:11:48.000000000 +0100
@@ -679,18 +679,9 @@ static void second_overflow(void)
 
 	/*
 	 * Compute the frequency estimate and additional phase adjustment due
-	 * to frequency error for the next second. When the PPS signal is
-	 * engaged, gnaw on the watchdog counter and update the frequency
-	 * computed by the pll and the PPS signal.
+	 * to frequency error for the next second.
 	 */
-	pps_valid++;
-	if (pps_valid == PPS_VALID) {	/* PPS signal lost */
-		pps_jitter = MAXTIME;
-		pps_stabil = MAXFREQ;
-		time_status &= ~(STA_PPSSIGNAL | STA_PPSJITTER |
-				STA_PPSWANDER | STA_PPSERROR);
-	}
-	ltemp = time_freq + pps_freq;
+	ltemp = time_freq;
 	time_adj += shift_right(ltemp,(SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE));
 
 #if HZ == 100

Re: [PATCH 1/10] NTP: Remove pps support

[john stultz]

On Thu, 2005-12-22 at 00:20 +0100, Roman Zippel wrote:
> This removes the support for pps. It's completely unused within the
> kernel and is basically in the way for further cleanups. It should be
> easier to readd proper support for it after the rest has been converted
> to NTP4.
> Patch is originally done by John Stultz, I did some minor cleanups and
> updated it.
> 
> Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

Hey Roman, sorry for the slow response, but I've been busy since getting
back from the holiday.

Initially when I wrote this I was hoping to prod Ulrich into updating
and sending his PPS driver for inclusion. But I believe he has just been
too busy, so pulling this code is probably the right thing. 

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


I do hope someone interested in PPS drivers will re-add the support code
along with a driver that utilizes the interface at some point.

thanks
-john

new time code problem

[George Anzinger]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

The 64-bit conversion routine to convert 64-bit nsec time to a time spec. 
gives an unnormalized result if the value being converted is negative.  I 
think there are two ways to go about fixing this.  Most systems will give a 
negative remainder and so need to just normalize.  On the other hand, some 
systems will use div64 to do the division and, I think, it expects unsigned 
numbers.  The attached patch uses the conservative approach of expecting the 
div to be set up for unsigned numbers.

I came accross this when one of my tests set a time near 1 Jan 1970, i.e. it 
is a real problem.
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

[-- Attachment #2: ktime_conversion.patch --]
[-- Type: text/plain, Size: 910 bytes --]

 kernel/time.c |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

Index: linux-2.6.16-rc/kernel/time.c
===================================================================
--- linux-2.6.16-rc.orig/kernel/time.c
+++ linux-2.6.16-rc/kernel/time.c
@@ -702,16 +702,19 @@ void set_normalized_timespec(struct time
  *
  * Returns the timespec representation of the nsec parameter.
  */
-inline struct timespec ns_to_timespec(const nsec_t nsec)
+struct timespec ns_to_timespec(const nsec_t nsec)
 {
 	struct timespec ts;
 
-	if (nsec)
+	if (nsec) return (struct timespec){0, 0};
+
+	if (nsec < 0) {
+		ts.tv_sec = div_long_long_rem_signed(-nsec, NSEC_PER_SEC,
+						     &ts.tv_nsec);
+		set_normalized_timespec(&ts, -ts.tv_sec, -ts.tv_nsec);
+	} else
 		ts.tv_sec = div_long_long_rem_signed(nsec, NSEC_PER_SEC,
 						     &ts.tv_nsec);
-	else
-		ts.tv_sec = ts.tv_nsec = 0;
-
 	return ts;
 }
 

Re: new time code problem

[Thomas Gleixner]

On Tuesday 10 January 2006 23:58, George Anzinger wrote:
> The 64-bit conversion routine to convert 64-bit nsec time to a time spec.
> gives an unnormalized result if the value being converted is negative.  I
> think there are two ways to go about fixing this.  Most systems will give a
> negative remainder and so need to just normalize.  On the other hand, some
> systems will use div64 to do the division and, I think, it expects unsigned
> numbers.  The attached patch uses the conservative approach of expecting
> the div to be set up for unsigned numbers.
>
> I came accross this when one of my tests set a time near 1 Jan 1970, i.e.
> it is a real problem.

> 
>  kernel/time.c |   13 ++++++++-----
>  1 files changed, 8 insertions(+), 5 deletions(-)
> 
> Index: linux-2.6.16-rc/kernel/time.c
> ===================================================================
> --- linux-2.6.16-rc.orig/kernel/time.c
> +++ linux-2.6.16-rc/kernel/time.c
> @@ -702,16 +702,19 @@ void set_normalized_timespec(struct time
>   *
>   * Returns the timespec representation of the nsec parameter.
>   */
> -inline struct timespec ns_to_timespec(const nsec_t nsec)
> +struct timespec ns_to_timespec(const nsec_t nsec)
>  {
>         struct timespec ts;
>  
> -       if (nsec)
> +       if (nsec) return (struct timespec){0, 0};

Err, you mean propably

	if(!nsec)
		return (struct timespec){0, 0};

	tglx

  

Re: new time code problem

[George Anzinger]

Thomas Gleixner wrote:
> On Tuesday 10 January 2006 23:58, George Anzinger wrote:
> 
>>The 64-bit conversion routine to convert 64-bit nsec time to a time spec.
>>gives an unnormalized result if the value being converted is negative.  I
>>think there are two ways to go about fixing this.  Most systems will give a
>>negative remainder and so need to just normalize.  On the other hand, some
>>systems will use div64 to do the division and, I think, it expects unsigned
>>numbers.  The attached patch uses the conservative approach of expecting
>>the div to be set up for unsigned numbers.
>>
>>I came accross this when one of my tests set a time near 1 Jan 1970, i.e.
>>it is a real problem.
> 
> 
>> kernel/time.c |   13 ++++++++-----
>> 1 files changed, 8 insertions(+), 5 deletions(-)
>>
>>Index: linux-2.6.16-rc/kernel/time.c
>>===================================================================
>>--- linux-2.6.16-rc.orig/kernel/time.c
>>+++ linux-2.6.16-rc/kernel/time.c
>>@@ -702,16 +702,19 @@ void set_normalized_timespec(struct time
>>  *
>>  * Returns the timespec representation of the nsec parameter.
>>  */
>>-inline struct timespec ns_to_timespec(const nsec_t nsec)
>>+struct timespec ns_to_timespec(const nsec_t nsec)
>> {
>>        struct timespec ts;
>> 
>>-       if (nsec)
>>+       if (nsec) return (struct timespec){0, 0};
> 
> 
> Err, you mean propably
> 
> 	if(!nsec)
> 		return (struct timespec){0, 0};

Why yes I do.  I even found that and fixed it, but then failed to refresh the 
patch.  Thanks...

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [PATCH 1/10] NTP: Remove pps support

[Ulrich Windl]

John,

accidentially ;-) I did merge my PPSkit-light into SuSE's 2.6.13 tree. It wasn't a 
big issue to merge the patch, but that might not be sufficient. Originally I 
wanted to update the patch for a standard kernel tree, but I realized that I first 
have to get the sources. I cannot promise you when, but I'll try to apply my stuff 
to a recent 2.6 kernel.

So if there's a kernel source to merge my stuff with, tell me wich, but the source 
should be stable enough to give me time to finish the merge before the next one is 
out. I only have a slower modem at home, so I cannot refresh sources frequently.

Does a release candidate kernel have the nanosecond clock in now? I got that 
impression recently.

BTW: Leaving the old crap in the kernel would help me to merge my stuff (Looking 
for "anchors" in the sources).

Regards,
Ulrich

On 10 Jan 2006 at 15:20, john stultz wrote:

> On Thu, 2005-12-22 at 00:20 +0100, Roman Zippel wrote:
> > This removes the support for pps. It's completely unused within the
> > kernel and is basically in the way for further cleanups. It should be
> > easier to readd proper support for it after the rest has been converted
> > to NTP4.
> > Patch is originally done by John Stultz, I did some minor cleanups and
> > updated it.
> > 
> > Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
> 
> Hey Roman, sorry for the slow response, but I've been busy since getting
> back from the holiday.
> 
> Initially when I wrote this I was hoping to prod Ulrich into updating
> and sending his PPS driver for inclusion. But I believe he has just been
> too busy, so pulling this code is probably the right thing. 
> 
> Acked-by: John Stultz <johnstul@us.ibm.com>
> 
> 
> I do hope someone interested in PPS drivers will re-add the support code
> along with a driver that utilizes the interface at some point.
> 
> thanks
> -john
> 

Re: [PATCH 1/10] NTP: Remove pps support

[Roman Zippel]

Hi,

On Wed, 11 Jan 2006, Ulrich Windl wrote:

> accidentially ;-) I did merge my PPSkit-light into SuSE's 2.6.13 tree.

Maybe there is something more recent (I only know of the stuff at 
kernel.org), but that wasn't exactly merge material.

> Does a release candidate kernel have the nanosecond clock in now? I got that 
> impression recently.

Well, I did everything except to the user interface, so basically only 
STA_NANO is missing, but that requires userspace updates as well, so I 
haven't done it yet.

> BTW: Leaving the old crap in the kernel would help me to merge my stuff (Looking 
> for "anchors" in the sources).

It's not that much to add back and this way it can be done properly (i.e. 
with a config option).

bye, Roman