On 19/12/2016 at 01:38:54 +0100, Alexandre Belloni wrote :

On 11/12/2016 at 00:21:02 +0200, Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote :

quoted

=20
On 2016-12-10 23:50, Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote:

quoted

Texas Instrument's TPS65910 has support for compensating RTC crystal
inaccuracies. When enabled every hour RTC counter value will be compe=

nsated

quoted

quoted

with two's complement value.
=20
Vesa J=C3=A4=C3=A4skel=C3=A4inen (2):
   drivers: rtc: rtc-tps65910: Add RTC calibration support
   drivers: rtc: rtc-tps65910: use 'unsigned int' instead of 'unsigne=

d'

quoted

quoted

     in arguments
=20
  drivers/rtc/rtc-tps65910.c   | 135 ++++++++++++++++++++++++++++++++=

++++++++++-

quoted

quoted

  include/linux/mfd/tps65910.h |   1 +
  2 files changed, 135 insertions(+), 1 deletion(-)
=20

This version now uses 'offset' sysfs file for calibration purposes.
=20
It supports rounding so if one calculates absolute 'offset' compensatio=

n

quoted

value then it should give "optimal" calibration.
=20
I believe one should calculate compensation value like:
=20
offset =3D ((measured_freq/32768)-1)*10^9
=20
So if meaured_freq =3D=3D 32771.2768, then matching offset =3D=3D 10000=

0.

quoted

Or if mesured_freq =3D=3D 32764.7232, then matching offset =3D=3D -1000=

00.

quoted

=20
'offset' compensation value is following existing rtc.txt definition me=

aning

quoted

positive values causes time to slowdown and negative values to fasten u=

p.

quoted

Which I believe should be other way around to be more logical. This is =

easy

quoted

to swap if I just understood it wrongly.
=20

=20
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.
=20

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.

quoted

'offset' value calculation assumes "common" understanding how ppm value=

s are

quoted

used, eg. it is negated compensation value (expect now positive).
=20
Eg. if RTC crystal is off by +100ppm then 'offset' value must be 100ppm
(write 100000 to 'offset').
=20
I believe offset documentation in rtc.txt should be clarified on what v=

alue

quoted

means.
=20
'offset' value has limits due to RTC chip itself, if out-of-limits valu=

e is

quoted

given -ERANGE is returned.
=20

=20
That's fine.
=20

quoted

Due to RTC chip's implementation -- it loses RTC compensation enable bi=

t on

quoted

reset, so compensation value must be written on every boot at least onc=

e to

quoted

be active.
=20
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 b=

e

quoted

easily fixed, -EINVAL might do the trick.
=20

=20
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.
=20

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

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

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

--=20
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.
---=20
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 e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.