Re: set_rtc_time() cleanup / normalization

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Thu, May 15, 2003 at 10:32:12AM +0200, Geert Uytterhoeven wrote:
> On Thu, 15 May 2003, Richard Zidlicky wrote:
> > On Wed, May 14, 2003 at 05:42:24PM +0200, Gabriel Paubert wrote:
> > > On Tue, May 13, 2003 at 02:03:51PM +0200, Richard Zidlicky wrote:
> >
> > > > - RTC should be accessed by proper rtc device driver only
> > >
> > > This model is already broken by the fact that you read the time
> > > early in boot to get reasonable initial values. So I don't buy
> > > at all this argument.
> >
> > reading it early during boot is a bit different, no worry about
> > interrupts, long delays etc. Also this could be actually done
> > by accessing /dev/rtc.
>
> Actually this breaks on machines where the RTC is on i2c, since i2c wasn't
> initialized yet.

Well, that's tough, it should at least be read before the first
userspace program is sorted. Could it be read and passed from a
bootloader with a botinfo record (repeatedly read the clock until
you cross a second boundary and get the timebase at this point).

Something like BI_CLOCK
struct bi_clock {
	unsigned long timebase;
	unsigned long tv_sec;
}


Reading the clock is easy under OF, don't know about others.

	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

set_rtc_time() cleanup / normalization

[Wolfgang Denk]

Hi everybody,

I would like to find out if there is some consensus about the use  of
set_rtc_time() in the timer interrupt handler.

    Note: this question relates to a thread that was started by
    Stephen Johnson on Tue, 22 Apr 2003; see message:
    http://lists.linuxppc.org/linuxppc-embedded/200304/msg00233.html

The problem: some systems use RTC chips which  are  attached  to  the
system  using an I2C bus (or similar). To control the device you will
have to setup one or more I2C transactions, which usually  result  in
one or more interrupts which must be processed.

Depending on which architecture and/or board you are using, there may
or may not be a call to set_rtc_time()  be  performed  in  the  timer
interrupt  handler.  This  call  will  happen  every  11 minutes (659
seconds, to be precise) - see "arch/ppc/kernel/time.c".


I would like to know if there is a rationale  in  putting  this  call
into a general part of the source code.

Other architectures handle this differently. For example, in the  ARM
kernel   tree  the  timer  interrupt  implementation  is  essentially
board-specific (located in a include/asm/arch-.../time.h file).  Some
ARM  boards'  timer interrupt handlers do call set_rtc_time(), others
don't.

Shouldn't we do the same on PPC?

Or maybe we should delete this code completely? If somebody wants  to
sync the RTC against the system time a simple daemon or cron job (for
example calling "hwclock --systohc" every 11 minutes) would result in
more or less identical results.



More information:

Calling set_rtc_time() is useful only in a situation where  there  is
an  external reference time against which the system time is synchro-
nized. In such a configuration this call would make sure that the RTC
is kept in sync with the reference time. This allows  to  start  with
minimal  deviation  in case of a crash, where no orderly shutdown was
performed. In case of a normal shutcown / reboot the shutdown scripts
would take care of saving the system time to RTC anyway...

In all other cases such a call to set_rtc_time() is  not  needed,  or
even harmful.

Many embedded systems run in a configuration where they  use  a  high
precision RTC chip and want to have the system time kept in sync with
it.  In  such  a configuration, the call to set_rtc_time() is plainly
wrong and must be avoided.


Oliver Amft posted a solution which includes spawning a kernel thread
to perform the set_rtc_time() call outside the timer  inteerupt;  see
http://lists.linuxppc.org/linuxppc-embedded/200304/msg00272.html;  in
my opinion this is only a workaround, but  not  a  solution.  Limited
accuracy (scheduling delay for the thread) and code size overhead are
just two of the problems of such a solution.


All feedback welcome.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
PROGRAM - n.  A magic spell cast over a computer  allowing it to turn
one's input into error messages.
v. tr. - To engage in a pastime similar to banging one's head against
a wall, but with fewer opportunities for reward.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Dan Malek]

Wolfgang Denk wrote:

> All feedback welcome.

I agree.  I've never liked calling rtc update functions from the timer
interrupt.  This is significant overhead that should be avoided in
the timer interrupt.

Thanks.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Geert Uytterhoeven]

On Mon, 12 May 2003, Wolfgang Denk wrote:
> I would like to find out if there is some consensus about the use  of
> set_rtc_time() in the timer interrupt handler.
>
>     Note: this question relates to a thread that was started by
>     Stephen Johnson on Tue, 22 Apr 2003; see message:
>     http://lists.linuxppc.org/linuxppc-embedded/200304/msg00233.html
>
> The problem: some systems use RTC chips which  are  attached  to  the
> system  using an I2C bus (or similar). To control the device you will
> have to setup one or more I2C transactions, which usually  result  in
> one or more interrupts which must be processed.
>
> Depending on which architecture and/or board you are using, there may
> or may not be a call to set_rtc_time()  be  performed  in  the  timer
> interrupt  handler.  This  call  will  happen  every  11 minutes (659
> seconds, to be precise) - see "arch/ppc/kernel/time.c".
>
>
> I would like to know if there is a rationale  in  putting  this  call
> into a general part of the source code.
>
> Other architectures handle this differently. For example, in the  ARM
> kernel   tree  the  timer  interrupt  implementation  is  essentially
> board-specific (located in a include/asm/arch-.../time.h file).  Some
> ARM  boards'  timer interrupt handlers do call set_rtc_time(), others
> don't.
>
> Shouldn't we do the same on PPC?
>
> Or maybe we should delete this code completely? If somebody wants  to
> sync the RTC against the system time a simple daemon or cron job (for
> example calling "hwclock --systohc" every 11 minutes) would result in
> more or less identical results.

On m68k, we removed that part because it confused NTP. Richard Zidlicky can
probably tell more about that.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Tue, May 13, 2003 at 09:52:22AM +0200, Geert Uytterhoeven wrote:
>
> On Mon, 12 May 2003, Wolfgang Denk wrote:
> > I would like to find out if there is some consensus about the use  of
> > set_rtc_time() in the timer interrupt handler.
> >
> >     Note: this question relates to a thread that was started by
> >     Stephen Johnson on Tue, 22 Apr 2003; see message:
> >     http://lists.linuxppc.org/linuxppc-embedded/200304/msg00233.html
> >
> > The problem: some systems use RTC chips which  are  attached  to  the
> > system  using an I2C bus (or similar). To control the device you will
> > have to setup one or more I2C transactions, which usually  result  in
> > one or more interrupts which must be processed.
> >
> > Depending on which architecture and/or board you are using, there may
> > or may not be a call to set_rtc_time()  be  performed  in  the  timer
> > interrupt  handler.  This  call  will  happen  every  11 minutes (659
> > seconds, to be precise) - see "arch/ppc/kernel/time.c".
> >
> >
> > I would like to know if there is a rationale  in  putting  this  call
> > into a general part of the source code.
> >
> > Other architectures handle this differently. For example, in the  ARM
> > kernel   tree  the  timer  interrupt  implementation  is  essentially
> > board-specific (located in a include/asm/arch-.../time.h file).  Some
> > ARM  boards'  timer interrupt handlers do call set_rtc_time(), others
> > don't.
> >
> > Shouldn't we do the same on PPC?
> >
> > Or maybe we should delete this code completely? If somebody wants  to
> > sync the RTC against the system time a simple daemon or cron job (for
> > example calling "hwclock --systohc" every 11 minutes) would result in
> > more or less identical results.
>
> On m68k, we removed that part because it confused NTP. Richard Zidlicky can
> probably tell more about that.

I certainly would like to know the details of this. I believe it may
be fixing the symptom rather than the cause (an NTP bug).

	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Tue, May 13, 2003 at 10:53:28AM +0200, Geert Uytterhoeven wrote:
>
> On Tue, 13 May 2003, Gabriel Paubert wrote:
> > On Tue, May 13, 2003 at 09:52:22AM +0200, Geert Uytterhoeven wrote:
> > > On Mon, 12 May 2003, Wolfgang Denk wrote:
> > > > I would like to find out if there is some consensus about the use  of
> > > > set_rtc_time() in the timer interrupt handler.
> > >
> > > On m68k, we removed that part because it confused NTP. Richard Zidlicky can
> > > probably tell more about that.
> >
> > I certainly would like to know the details of this. I believe it may
> > be fixing the symptom rather than the cause (an NTP bug).
>
> As far as I remember, NTP estimates the error of your RTC and uses that
> estimation to correct your time if no NTP server is available, but the
> estimation step fails if the kernel messes with the RTC behind NTP's back.

In this case NTP should never clear the STA_UNSYNC flag shen it
synchronized to the local clock (driver 127.127.0.0 IIRC) . The state
change from 0x41 to 0x01 should never happen for the kernel side of
the status flags, this would avoid creating the loop.

	Regards,
	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Wolfgang Denk]

In message <20030513102145.GA3997@iram.es> Gabriel Paubert wrote:
>
> > > I certainly would like to know the details of this. I believe it may
> > > be fixing the symptom rather than the cause (an NTP bug).
> >
> > As far as I remember, NTP estimates the error of your RTC and uses that
> > estimation to correct your time if no NTP server is available, but the
> > estimation step fails if the kernel messes with the RTC behind NTP's back.
>
> In this case NTP should never clear the STA_UNSYNC flag shen it
> synchronized to the local clock (driver 127.127.0.0 IIRC) . The state
> change from 0x41 to 0x01 should never happen for the kernel side of
> the status flags, this would avoid creating the loop.


There are eventually two problems:

* Probably there is a problem in NTP.

  The conficuration where the problem was observed was one where  NTP
  was  used  with  a  "server  127.127.1.0"  setting  with  no  other
  synchronization source.

* set_rtc_time() should never be called from timer interrupt.

  Setting the RTC will in many cases involce  transactions  over  I2C
  which  (1)  are  awfully  slow  and (2) involve interrup processing
  themselfs so they cannot be used in interrupt context.


I think we should remove this code from the timer interrupt handler.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Richard Zidlicky]

> > On m68k, we removed that part because it confused NTP. Richard Zidlicky can
> > probably tell more about that.

more specific, syncinc systime with NTP could confuse hwclock,
see eg the thread following

http://marc.theaimsgroup.com/?l=linux-kernel&m=100448857801670&w=2

Although workarounds are possible, there are some more reasons
to dislike the hwclk update code in arch/*kernel/time.c:

- RTC should be accessed by proper rtc device driver only
- magic updates may confuse hwclock, adjtimex and other programs,
  some programs need to use workarounds to avoid triggering it.
- everything it does can be done much better by userspace
  accessing /dev/rtc
- implements policy and thus doesn´t belong into kernel
- getting rid of it saves a few clock cycles on every timer
  interrupt
- nobody can positively expect it to work, iirc many HW
  variants were never supported -> nothing can break if
  it is killed


Richard

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Paul Mackerras]

Wolfgang Denk writes:

> I would like to find out if there is some consensus about the use  of
> set_rtc_time() in the timer interrupt handler.

The consensus so far seems to be that we shouldn't call set_rtc_time
in the timer interrupt handler.  Is anyone willing to speak up with a
reason why we should keep it?  If not, we'll take it out.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Eugene Surovegin]

At 04:05 PM 5/13/2003, Paul Mackerras wrote:

>Wolfgang Denk writes:
>
> > I would like to find out if there is some consensus about the use  of
> > set_rtc_time() in the timer interrupt handler.
>
>The consensus so far seems to be that we shouldn't call set_rtc_time
>in the timer interrupt handler.  Is anyone willing to speak up with a
>reason why we should keep it?

Because there are systems which rely on this behavior?
For example, all our embedded systems use this feature.

Wolfgang said that "... many embedded systems run in a configuration
where they use a high precision RTC chip...".

All embedded systems I saw used cheap RTC parts with poor accuracy.

I think we mix two different issues here:

1) call set_rtc_time() from timer interrupt every 11 min if clock is
synched (e.g. by NTP)
    I don't see any problems with this.

2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
just cannot
    be called from the interrupt context.
    Why just don't fix actual RTC code in each case ?
    It may be useful to provide some *generic* facility for such cases.

Eugene.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Wolfgang Denk]

In message <5.1.0.14.2.20030513161846.03805338@mail.ebshome.net>
Eugene Surovegin wrote:
>
> >The consensus so far seems to be that we shouldn't call set_rtc_time
> >in the timer interrupt handler.  Is anyone willing to speak up with a
> >reason why we should keep it?
>
> Because there are systems which rely on this behavior?
> For example, all our embedded systems use this feature.
>
> Wolfgang said that "... many embedded systems run in a configuration
> where they use a high precision RTC chip...".
>
> All embedded systems I saw used cheap RTC parts with poor accuracy.
>
> I think we mix two different issues here:
>
> 1) call set_rtc_time() from timer interrupt every 11 min if clock is
> synched (e.g. by NTP)
>     I don't see any problems with this.

There are many problems with this approch, for a summary see
http://lists.linuxppc.org/linuxppc-dev/200305/msg00034.html

The main reason to remove it is thatit's broken (i. e. causes  kernel
crashes) on many hardware configurations.

> 2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
> just cannot
>     be called from the interrupt context.
>     Why just don't fix actual RTC code in each case ?
>     It may be useful to provide some *generic* facility for such cases.

Do you have any recommendation HOW to implement such a "fix"?

The argument to put the set_rtc_time() call into the timer  interrupt
was  accuracy;  if  you  have to remove it from interrupt context the
only solution I've seen so far is to pay  for  an  additional  kernel
thread - more overhead, and you just removed the only argument to put
it into the timer interrupt at all.

It just makes no sense to me.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free.         - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Matt Porter]

On Tue, May 13, 2003 at 05:30:13PM -0700, Eugene Surovegin wrote:
> >The main reason to remove it is thatit's broken (i. e. causes  kernel
> >crashes) on many hardware configurations.
>
> Well, properly implemented set_rtc_time will not cause kernel crashes.
> I doesn't crash on our hardware. Guess why?

Well, I didn't want to "me too" as an opponent of doing this in the
kernel but I guess I need to.  This type of thing doesn't *need* to
be in the kernel because it can be implemented in userspace.

<snip>

> >and you just removed the only argument to put
> >it into the timer interrupt at all.
>
> Well, I don't see such placement as an optimization, just as some place
> from where it can be done easily without requiring cron, hwclock or other
> usermode stuff.

If cron and hwclock are too heavyweight for your fs then this is
screaming for a simple busybox solution.  I haven't looked at
busybox in a while, most of it might even be there already in a
slimmed down form factor.

Regards,
--
Matt Porter
mporter@kernel.crashing.org

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Eugene Surovegin]

At 10:58 PM 5/13/2003, Dan Malek wrote:
>Eugene Surovegin wrote:
>
>>Why PPC arch should be different in this respect from other archs (like
>>i386, alpha, mips, mips64, sparc...)?
>
>PPC is different only that it follows the i386 model.  IIRC, the others
>have some selectable (or removed) feature for keeping the rtc updated.
>When you have an inflexible and essentially memory mapped device (like
>on i386) it makes sense to not have any options.  With embedded systems,
>you have a variety of options that don't always fit this model.

Exactly, I use this feature on our systems, somebody doesn't use it at all.

So far, the only *real* issue I've seen here is that some RTC drivers weren't
written correctly.

When I wrote RTC driver for out hw, simple grep through the code revealed
the fact, that ppc_md.set_rtc_time was called from interrupt context.
It's not a rocket science.

So all this surprise about kernel setting RTC is a little strange for me.
And yes, kernel *will* crash if you write a buggy driver.

I don't understand why instead of fixing those drivers we should remove
this feature altogether.

>>Frankly, I expect my tipb to behave exactly the same as my Intel box.
>
>Why would you want such a superior architecture like tipb to work
>so poorly? :-)

Well, I just use tipb as an example of box running PPC kernel which has the
same setup as my Intel box running the same kernel version.

>The tipb isn't the issue, but if you look carefully
>at all of these systems they all use user space programs to ensure
>the rtc and system date/time/timezone are set properly.
>
>>Maybe we should raise this issue on lkml?
>
>They won't care.  One, it's not x86, two, it's architecture specific.

Well, it's not entirely arch specific.
This behavior is *documented* (see hwclock(8) man pages for example).

Eugene.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Wolfgang Denk]

In message <5.1.0.14.2.20030513214040.02a6e6d0@mail.ebshome.net> you wrote:
>
> There is other thing which bothers me.
> Why PPC arch should be different in this respect from other archs (like
> i386, alpha, mips, mips64, sparc...)?

Because other architectures  already  are  different  than  PPC.  For
example  on  ARM  the  implementation is board-dependend. Some boards
don't call set_rtc_time() in their timer interrupt handlers.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Don't tell me how hard you work.  Tell me how much you get done.
                                                     -- James J. Ling

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Benjamin Herrenschmidt]

>
> 2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
> just cannot
>     be called from the interrupt context.
>     Why just don't fix actual RTC code in each case ?
>     It may be useful to provide some *generic* facility for such cases.

It may just not be fixable cleanly. If you RTC is on a bus which requires
some semaphoring for access (i2c does on pmac, though so far, the RTC isn't
on i2c on these, I admit), or which is just so slow that you really do NOT
want to block the machine in an interrupt that long ?

Actually, the later is the most nasty. Also, since set_rtc_time() is used for
both interrupt call and non-interrupt call, it cannot make assumptions about
beeing able to schedule or not, thus causing the same latency problem when
called via /dev/rtc, possibly a good DOS attack tool, but more simply, it
just suck that way...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Wed, May 14, 2003 at 10:32:33AM +0200, Benjamin Herrenschmidt wrote:
>
> >
> > 2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
> > just cannot
> >     be called from the interrupt context.
> >     Why just don't fix actual RTC code in each case ?
> >     It may be useful to provide some *generic* facility for such cases.
>
> It may just not be fixable cleanly. If you RTC is on a bus which requires
> some semaphoring for access (i2c does on pmac, though so far, the RTC isn't
> on i2c on these, I admit), or which is just so slow that you really do NOT
> want to block the machine in an interrupt that long ?
>
> Actually, the later is the most nasty. Also, since set_rtc_time() is used for
> both interrupt call and non-interrupt call, it cannot make assumptions about
> beeing able to schedule or not, thus causing the same latency problem when
> called via /dev/rtc, possibly a good DOS attack tool, but more simply, it
> just suck that way...

Well, on all these aspects, I am strongly on Eugene's side. I believe
the implementation has to be refined, but that the functionality cannot
be removed.

It seems that we are only two, ok. In any case, it will stay that way
in my source trees. I have reasonably fast RTC (15 microseconds to write
them) so it's never a big issue of course.

I also suspect that people strongly object to a CONFIG option.

	Gabriel.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Eugene Surovegin]

At 01:32 AM 5/14/2003, Benjamin Herrenschmidt wrote:

> >
> > 2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
> > just cannot
> >     be called from the interrupt context.
> >     Why just don't fix actual RTC code in each case ?
> >     It may be useful to provide some *generic* facility for such cases.
>
>It may just not be fixable cleanly. If you RTC is on a bus which requires
>some semaphoring for access (i2c does on pmac, though so far, the RTC isn't
>on i2c on these, I admit), or which is just so slow that you really do NOT
>want to block the machine in an interrupt that long ?

Well, fix was already suggested. Just use some kernel thread to actually
update RTC.

>Actually, the later is the most nasty. Also, since set_rtc_time() is used for
>both interrupt call and non-interrupt call, it cannot make assumptions about
>beeing able to schedule or not, thus causing the same latency problem when
>called via /dev/rtc, possibly a good DOS attack tool, but more simply, it
>just suck that way...

Well, maybe we need to functions, one that can be called from interrupt
context,
the other - usual one. Or we can test in_interrupt() in set_rtc_time and
act accordingly (although solution with two functions seems more clean).

Eugene.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Tue, May 13, 2003 at 04:33:50PM -0700, Eugene Surovegin wrote:
>
> At 04:05 PM 5/13/2003, Paul Mackerras wrote:
>
> >Wolfgang Denk writes:
> >
> >> I would like to find out if there is some consensus about the use  of
> >> set_rtc_time() in the timer interrupt handler.
> >
> >The consensus so far seems to be that we shouldn't call set_rtc_time
> >in the timer interrupt handler.  Is anyone willing to speak up with a
> >reason why we should keep it?
>
> Because there are systems which rely on this behavior?
> For example, all our embedded systems use this feature.
>
> Wolfgang said that "... many embedded systems run in a configuration
> where they use a high precision RTC chip...".
>
> All embedded systems I saw used cheap RTC parts with poor accuracy.
>
> I think we mix two different issues here:
>
> 1) call set_rtc_time() from timer interrupt every 11 min if clock is
> synched (e.g. by NTP)
>    I don't see any problems with this.
>
> 2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
> just cannot
>    be called from the interrupt context.
>    Why just don't fix actual RTC code in each case ?
>    It may be useful to provide some *generic* facility for such cases.

Absolutely agreed. I believe that this is set_rtc_time and get_rtc_time
that should be fixed. I have BTW a small bugfix to submit.

I believe that in the end we shall have two read functions:
- one __init__ for boot time which should fill two global variables:
a second value and the value of the timebase at the second transition.
There performance is irrelevant.
- one to read it on the fly while the kernel is running,

I would not mind if the hctosys and systohc functions were accesible
through adjtimex BTW. This would make the rtc driver unnecessary for
most cases and on my machines it does not work properly in any cases
since they are nonstandard PreP, the interrupt pin of the RTC is
not wired at all.

	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Wed, May 14, 2003 at 09:05:52AM +1000, Paul Mackerras wrote:
>
> Wolfgang Denk writes:
>
> > I would like to find out if there is some consensus about the use  of
> > set_rtc_time() in the timer interrupt handler.
>
> The consensus so far seems to be that we shouldn't call set_rtc_time
> in the timer interrupt handler.  Is anyone willing to speak up with a
> reason why we should keep it?  If not, we'll take it out.

Ask on the ntp lists first, I bet you'll upset a lot of people
if you suggest it.

	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Dan Malek]

Gabriel Paubert wrote:

> Ask on the ntp lists first, I bet you'll upset a lot of people
> if you suggest it.

I'll bet no one is using it on a system that has an unpredictable
latency, interrupt generating, i2c RTC, either. :-)

The solution is to do like other architectures and allow (as Tom
suggested) a selectable rtc update function.  Although I may use
a particular RTC driver, I may not want the update function that
comes along with it.  All we need is an indirect function pointer
to the get/set functions that is initialized by the board set
up functions.  By default they should be null functions, if you
want something else, put a pointer there.

The fact is the current rtc update functions are not suitable for
embedded boards that have to meet latency guarantees.  They simply
add overhead, often in a bad way, even if implemented correctly.
Installing any kind of real-time enhancement (like RTLinux or RTAI)
will cause a failure of the rtc update model because the update thread of
control can be easily preempted.

The solution is easy, you can find examples in other architectures,
and we don't have to argue about it.

Thanks.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Gabriel Paubert]

On Wed, May 14, 2003 at 12:28:29PM -0400, Dan Malek wrote:
>
> Gabriel Paubert wrote:
>
> >Ask on the ntp lists first, I bet you'll upset a lot of people
> >if you suggest it.
>
> I'll bet no one is using it on a system that has an unpredictable
> latency, interrupt generating, i2c RTC, either. :-)

Never take bets with NTP :-) It is one of the most portable (and actually
ported) protocols and set of programs in existence.

> The solution is to do like other architectures and allow (as Tom
> suggested) a selectable rtc update function.  Although I may use
> a particular RTC driver, I may not want the update function that
> comes along with it.  All we need is an indirect function pointer
> to the get/set functions that is initialized by the board set
> up functions.  By default they should be null functions, if you
> want something else, put a pointer there.

And to go against the existing documentation of hwclock(8) so that
the behaviour depends on the architecture, the exact RTC chip model,
the phase of the moon:

"The Linux kernel has a mode wherein it copies the System Time to the
Hardware Clock every 11 minutes.  This is a good mode to use when you are
using  something  sophisticated  like  ntp to keep your System Time
synchronized. (ntp is a way to keep your System Time synchronized either
to a time server somewhere on the network or to a radio clock hooked up
to  your system.   See  RFC 1305)."

I personally believe that explicitly implementing something which goes
against the existing documentation is one of the worst things that
can happen, espcecially since (after a few years of experience with
the linux hackers) I don't expect anybody to send patches to update
the documentation to reflect this fact. So we are heading towards
justified user complaints (it ain't working as documented).

> The fact is the current rtc update functions are not suitable for
> embedded boards that have to meet latency guarantees.  They simply
> add overhead, often in a bad way, even if implemented correctly.

There are clean solutions to this. I'm ready to code them if you don't
believe me (but I'll need the docs or at least the references for the
most esoteric chips). I'm away for 3 weeks starting next week (including
some holidays and I won't have net access most of the time), but I shall
try to prepare something on my laptop while off-line.

> Installing any kind of real-time enhancement (like RTLinux or RTAI)
> will cause a failure of the rtc update model because the update thread of
> control can be easily preempted.

Doesn't matter if the clock is as slow as it I imagine for i2c. You
obviously can't expect an absolute precision of the clock much better
than its access time. Most (all) RTC clocks run off a 32768Hz clock
(abouy 31us cycle time) and often the first divider stages can't even be
reset, so the ultimate precision you can expect is of the order of a few
hundred microseconds (I don't remember the exact figures, need to
check the docs).

And even for the RTlinux, I am thinking of solutions. Don't tell me
that you can't prevent preemption for about the time of a single bus
access.

> The solution is easy, you can find examples in other architectures,
> and we don't have to argue about it.

Deliberately implementing something which departs from the existing
documentation or makes the subtle details of behaviour dependant
on the architecture or RTC chip you have? I'd rather avoid that
at all costs.

	Regards,
	Gabriel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Wolfgang Denk]

In message <20030515180427.GB20958@iram.es> Gabriel Paubert wrote:
>
> And to go against the existing documentation of hwclock(8) so that
> the behaviour depends on the architecture, the exact RTC chip model,
> the phase of the moon:

hwclock(8) does not correctly describe the current  situation.  There
are  already  several  boards where the documentation and the code do
not match. [Please note that I avoid writing  "the  documentation  is
wrong" - I think it is, but YMMV.]

> I personally believe that explicitly implementing something which goes
> against the existing documentation is one of the worst things that
> can happen, espcecially since (after a few years of experience with

If the documentation is wrong, or does not make sense,  it  would  be
even  worse  to  stick  with it just because it is "existing documen-
tation".


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A wise person makes his  own  decisions,  a  weak  one  obeys  public
opinion.                                           -- Chinese proverb

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: set_rtc_time() cleanup / normalization

[Benjamin Herrenschmidt]

On Thu, 2003-05-15 at 20:44, Gabriel Paubert wrote:

> Hmm, in this case. My current plan is to implement the documented
> behaviour, whatever it takes (time, among other things), since
> I am deeply convinced that it is the correct behaviour.
>
> So far, all the arguments that I've seen in favor of removing
> thos code boil down to the fact that developers are too lazy
> to implement it correctly.

Ok, so here are my concerns, if you can address them cleanly, I'm
ok with that ;)

I want things like PMU or Cuda based RTC (or i2c based one) to
be able to schedule in get/set_rtc_time(), thus those shouldn't be
called at interrupt time. Maybe a flag "rtc_irq_safe" in ppc_md that
when clear would cause you to defer processing to a work queue ? Or
maybe we can simply unconditionally defer ?

We need also to move the initial reading of the RTC a bit later
in the boot process, I'm not too sure what would happen if we
schedule that early, and we may want to wait for things like i2c
to be available.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/