Hi,
On Wed, 28 May 2008, Andrew Morton wrote:
> > I am not sure who actually claims maintenance of kernel/time/ntp.c, but
> > it looks, Thomas, you seem to be our current time overseer -- could you
> > please speak out on this change? I'd like this change to get applied
> > somewhere reasonable -- is it -mm?
>
> Roman does most of the NTP work afaik. I consider Thomas's git-hrt
> tree to be the route via which NTP changes get into linux-next and
> mainline.
That function is a little misplaced, we already have a driver/rtc dir,
where this should go in the long term and ntp.c only providing the
trigger, that time is stable. There it would also be possible to better
take into account any quirks needed to update the chip.
bye, Roman
Hi,
> > Roman does most of the NTP work afaik. I consider Thomas's git-hrt
> > tree to be the route via which NTP changes get into linux-next and
> > mainline.
>
> That function is a little misplaced, we already have a driver/rtc dir,
> where this should go in the long term and ntp.c only providing the
> trigger, that time is stable. There it would also be possible to better
> take into account any quirks needed to update the chip.
I posted a separate change to implement a backend using the RTC class
device. I think this is the right solution till all the platforms are
moved away from legacy RTC drivers.
I think you are right about the long-term implications and apart from any
possible quirks I think the interface could get improved as there are RTC
chips we support nowadays that provide sub-second resolution.
Maciej
On Mon, 9 Jun 2008 19:18:52 +0100 (BST)
"Maciej W. Rozycki" <[email protected]> wrote:
> Hi,
>
> > > Roman does most of the NTP work afaik. I consider Thomas's git-hrt
> > > tree to be the route via which NTP changes get into linux-next and
> > > mainline.
> >
> > That function is a little misplaced, we already have a driver/rtc dir,
> > where this should go in the long term and ntp.c only providing the
> > trigger, that time is stable. There it would also be possible to better
> > take into account any quirks needed to update the chip.
>
> I posted a separate change to implement a backend using the RTC class
> device. I think this is the right solution till all the platforms are
> moved away from legacy RTC drivers.
>
> I think you are right about the long-term implications and apart from any
> possible quirks I think the interface could get improved as there are RTC
> chips we support nowadays that provide sub-second resolution.
>
Are there any objections to the patch under discussion?
Thanks.
From: "Maciej W. Rozycki" <[email protected]>
This is a change that makes the 11-minute RTC update be run in the process
context. This is so that update_persistent_clock() can sleep, which may
be required for certain types of RTC hardware -- most notably I2C devices.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Roman Zippel <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Alessandro Zummo <[email protected]>
Cc: David Brownell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
kernel/time/ntp.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff -puN kernel/time/ntp.c~ntp-let-update_persistent_clock-sleep kernel/time/ntp.c
--- a/kernel/time/ntp.c~ntp-let-update_persistent_clock-sleep
+++ a/kernel/time/ntp.c
@@ -10,13 +10,13 @@
#include <linux/mm.h>
#include <linux/time.h>
-#include <linux/timer.h>
#include <linux/timex.h>
#include <linux/jiffies.h>
#include <linux/hrtimer.h>
#include <linux/capability.h>
#include <linux/math64.h>
#include <linux/clocksource.h>
+#include <linux/workqueue.h>
#include <asm/timex.h>
/*
@@ -218,11 +218,11 @@ void second_overflow(void)
/* Disable the cmos update - used by virtualization and embedded */
int no_sync_cmos_clock __read_mostly;
-static void sync_cmos_clock(unsigned long dummy);
+static void sync_cmos_clock(struct work_struct *work);
-static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0);
+static DECLARE_DELAYED_WORK(sync_cmos_work, sync_cmos_clock);
-static void sync_cmos_clock(unsigned long dummy)
+static void sync_cmos_clock(struct work_struct *work)
{
struct timespec now, next;
int fail = 1;
@@ -258,13 +258,13 @@ static void sync_cmos_clock(unsigned lon
next.tv_sec++;
next.tv_nsec -= NSEC_PER_SEC;
}
- mod_timer(&sync_cmos_timer, jiffies + timespec_to_jiffies(&next));
+ schedule_delayed_work(&sync_cmos_work, timespec_to_jiffies(&next));
}
static void notify_cmos_timer(void)
{
if (!no_sync_cmos_clock)
- mod_timer(&sync_cmos_timer, jiffies + 1);
+ schedule_delayed_work(&sync_cmos_work, 0);
}
#else
_
On Mon, 9 Jun 2008 14:59:23 -0700
Andrew Morton <[email protected]> wrote:
> Are there any objections to the patch under discussion?
>
> Thanks.
>
>
> From: "Maciej W. Rozycki" <[email protected]>
>
> This is a change that makes the 11-minute RTC update be run in the process
> context. This is so that update_persistent_clock() can sleep, which may
> be required for certain types of RTC hardware -- most notably I2C devices.
>
> Signed-off-by: Maciej W. Rozycki <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Roman Zippel <[email protected]>
> Cc: Rik van Riel <[email protected]>
> Cc: Alessandro Zummo <[email protected]>
> Cc: David Brownell <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
Acked-by: Alessandro Zummo <[email protected]>
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it