linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alessandro Zummo <azummo-lists@towertech.it>
To: Simon Richter <Simon.Richter@hogyros.de>
Cc: linuxppc-dev@ozlabs.org, lm-sensors@lm-sensors.org,
	linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org
Subject: Re: [RFC] RTC subsystem
Date: Thu, 22 Dec 2005 07:48:50 +0100	[thread overview]
Message-ID: <20051222074850.01d56f94@inspiron> (raw)
In-Reply-To: <43A9E2C9.7080300@hogyros.de>

On Thu, 22 Dec 2005 00:18:33 +0100
Simon Richter <Simon.Richter@hogyros.de> wrote:

> A good ntpd will adjust the speed rather than write to the clock; the
> ntpd shipped by most distributions can already handle multiple time sources.

 Yes, but there's the kernel who writes to the clock,
 for example http://lxr.linux.no/source/arch/arm/kernel/time.c?a=arm#L103 .

> >  later. The /dev/rtc interface only supports one clock.
> >  It can either be extended to have /dev/rtcX or we
> >  can extend the sysfs one to allow clock updating.
> 
> /dev is the way to go IMO. As far as I've understood sysfs, it carries
> meta information about devices and drivers only, the actual
> communication then happens through device nodes still.

 Ok. We can use dynamic device numbers and go for the /dev
 interface. 

> 
> >  NTP mode could then be adjusted to update one or more
> >  of the rtcs. Maybe each RTC could have an attribute
> >  (let's say /sys/class/rtc/rtcX/ntp) which tells the
> >  kernel whether to update it or not.
> 
> That's entirely a userspace thing. What the userspace needs to know from
> the kernel is whether the clock is writable and whether its speed can be
> adjusted.

 agreed. there are are also some variables of interest in
 http://lxr.linux.no/source/include/linux/timex.h?a=arm#L188
 some of them may be usefully exported in sysfs.
 
 
-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

  reply	other threads:[~2005-12-22  6:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-20 21:00 [RFC] RTC subsystem Alessandro Zummo
2005-12-21 12:18 ` Simon Richter
2005-12-21 15:07   ` Alessandro Zummo
2005-12-21 16:02     ` Simon Richter
2005-12-21 17:41       ` Alessandro Zummo
2005-12-21 23:18         ` Simon Richter
2005-12-22  6:48           ` Alessandro Zummo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-12-26 19:22 Alessandro Zummo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051222074850.01d56f94@inspiron \
    --to=azummo-lists@towertech.it \
    --cc=Simon.Richter@hogyros.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=lm-sensors@lm-sensors.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).