Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Perry E. Metzger <perry@piermont.com>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 09/09/2006 10:27:55
Perry E. Metzger wrote:
> David Laight <david@l8s.co.uk> writes:
>   
>> On Thu, Sep 07, 2006 at 11:04:31AM -0400, Perry E. Metzger wrote:
>>     
>>> Most of the battery backed up RTC chips in use have very coarse
>>> precision compared to the kernel. That is, they read out only to the
>>> nearest 1 second. They often have quite good accuracy, however.
>>>       
>> Some of them also have 'trim' registers that can be set to improve
>> the long term accuracy.  So if the time is corrected, and you
>> remembered when it was last corrected, some simple maths [1] gives
>> an update for the trim register.
>>     
>
> I was wondering about that. Garrett recently removed all our (unused)
> hook based support for updating the trim registers -- maybe we should
> bring that back.
>   

I don't mind putting the hook back.  But it should be required for chip
drivers to supply a stub.  That is just stupid.  Leaving it NULL should
be permissible.  We can add those entry points without impacting other
drivers at any time, as soon as someone writes code that will make use
of them.

Until there is at least something in the code to use the calibration
points, it doesn't make sense to even put in the hooks.

>   
>> The current situation for systems not using NTP is stupid, we rewrite
>> the time from a low-quality uncalibrated source (the system clock)
>> over that of a device that is meant to have reasonable long term
>> accuracy.
>>     
>
> Perhaps it would be best if we only wrote back the system clock to the
> battery clock if the system clock knows it is being NTP conditioned,
> and otherwise conditioned the system clock based on the battery clock.
>   

I'm not sure.  Some times battery clocks are worse, sometimes better. 
Depends on the platform, I think.  I don't think there is a clear cut
answer here.

    -- Garrett
> Perry
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191