Re: [PATCH 1/2 v3] SGI RTC: add clocksource driver

[Dimitri Sivanich <sivanich@sgi.com>]

John,

Thanks for the reply.  I will address this in forthcoming patchsets.

On Thu, Nov 20, 2008 at 04:08:08PM -0800, john stultz wrote:
> On Thu, 2008-11-20 at 15:08 -0800, Andrew Morton wrote:
> > On Wed, 19 Nov 2008 15:23:50 -0600
> > Dimitri Sivanich <sivanich@sgi.com> wrote:
> > 
> > > This patch provides a driver for SGI RTC clocks and timers.
> > > 
> > > This provides a high resolution clock and timer source using the SGI
> > > system-wide synchronized RTC clock/timer hardware.
> [snip]
> > > +static struct clocksource clocksource_uv = {
> > > +	.name		= RTC_NAME,
> > > +	.rating		= 400,
> > > +	.read		= uv_read_rtc,
> > > +	.mask		= (cycle_t)UVH_RTC_REAL_TIME_CLOCK_MASK,
> > > +	.shift		= 0,
> > > +	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
> > > +};
> 
> Hey Dimitri,
> 	One issue with this clocksource is the shift value. The clocksource
> frequency is calculated from the mult/shift pair (f = mult/2^shift).
> When NTP steers the clock in the generic timekeeping code, it does so by
> tweaking the mult value up or down. However if the shift value is too
> low, that ends up being quite a large change to the frequency.
> 
> So in order to get fine grained frequency adjustments I'd recommend
> using a larger shift value (8 at least). Ideally you want the largest
> shift value possible, but some care is needed that it isn't too big,
> because larger shift values mean larger mult values, and you don't want
> to overflow on the multiplication.
> 
> A rule of thumb I use is to find a shift value so the resulting mult
> value won't overflow 1 second worth of cycles.
>