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

From: Dimitri Sivanich
Date: Fri Nov 21 2008 - 12:23:21 EST


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@xxxxxxx> 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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/