On 19/12/2016 at 01:38:54 +0100, Alexandre Belloni wrote :
> On 11/12/2016 at 00:21:02 +0200, Vesa Jääskeläinen wrote :
> > 
> > On 2016-12-10 23:50, Vesa Jääskeläinen wrote:
> > > Texas Instrument's TPS65910 has support for compensating RTC crystal
> > > inaccuracies. When enabled every hour RTC counter value will be 
> > > compensated
> > > with two's complement value.
> > > 
> > > Vesa Jääskeläinen (2):
> > >    drivers: rtc: rtc-tps65910: Add RTC calibration support
> > >    drivers: rtc: rtc-tps65910: use 'unsigned int' instead of 'unsigned'
> > >      in arguments
> > > 
> > >   drivers/rtc/rtc-tps65910.c   | 135 
> > > ++++++++++++++++++++++++++++++++++++++++++-
> > >   include/linux/mfd/tps65910.h |   1 +
> > >   2 files changed, 135 insertions(+), 1 deletion(-)
> > > 
> > This version now uses 'offset' sysfs file for calibration purposes.
> > 
> > It supports rounding so if one calculates absolute 'offset' compensation
> > value then it should give "optimal" calibration.
> > 
> > I believe one should calculate compensation value like:
> > 
> > offset = ((measured_freq/32768)-1)*10^9
> > 
> > So if meaured_freq == 32771.2768, then matching offset == 100000.
> > Or if mesured_freq == 32764.7232, then matching offset == -100000.
> > 
> > 'offset' compensation value is following existing rtc.txt definition meaning
> > positive values causes time to slowdown and negative values to fasten up.
> > Which I believe should be other way around to be more logical. This is easy
> > to swap if I just understood it wrongly.
> > 
> 
> The hardware vendors are using positive offsets to slow the RTC and
> negative offsets to hasten it so that's what we exposed to userspace as
> it avoids a conversion.
> 

To be clear, that is unfortunately not the case for the TPS65910.

Usually, the offset is related to a number of clock cycles (or ticks)
that are added in a second (slowing the RTC). On the tps65910, it is the
number that is added to the counter (hastening the RTC).

One or the other would feel backward for someone anyway. I'll try to
clarify that in the documentation.


> > 'offset' value calculation assumes "common" understanding how ppm values are
> > used, eg. it is negated compensation value (expect now positive).
> > 
> > Eg. if RTC crystal is off by +100ppm then 'offset' value must be 100ppm
> > (write 100000 to 'offset').
> > 
> > I believe offset documentation in rtc.txt should be clarified on what value
> > means.
> > 
> > 'offset' value has limits due to RTC chip itself, if out-of-limits value is
> > given -ERANGE is returned.
> > 
> 
> That's fine.
> 
> > Due to RTC chip's implementation -- it loses RTC compensation enable bit on
> > reset, so compensation value must be written on every boot at least once to
> > be active.
> > 
> > When compensation is not enabled "cat offset" returns value. There is
> > currently no way to know from users space (without i2cget -f) whether
> > compensation is enabled or not. If this should not be the case it can be
> > easily fixed, -EINVAL might do the trick.
> > 
> 
> If compensation is not enabled, simply return 0 so userspace actually
> has a way to know it is not currently in effect. Anyway, you'll have to
> write a value to enable it again.
> You are probably already able to calculate that value anyway so I'm not
> sure of the benefit of using the RTC to remember it across resets.
> 

After reviewing the patch, it is fine apart from that part.

> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups 
"rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rtc-linux+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to