IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Introduce a bitfield to allow the drivers to announce the available
features for an RTC.
The main use case would be to better handle alarms, that could be present
or not or have a minute resolution or may need a correct week day to be set.
Use the newly introduced RTC_FEATURE_ALARM bit to then test whether alarms
are available instead of relying on the presence of ops->set_alarm.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210110231752.1418816-2-alexandre.belloni@bootlin.com
With CONFIG_I2C=m, the #ifdef section is disabled, as shown
by this warning:
drivers/rtc/rtc-rx6110.c:314:12: error: unused function 'rx6110_probe' [-Werror,-Wunused-function]
Change the driver to use IS_ENABLED() instead, which works
for both module and built-in subsystems.
Fixes: afa819c2c6 ("rtc: rx6110: add i2c support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201230145938.3254459-1-arnd@kernel.org
Pull RTC updates from Alexandre Belloni:
"Subsystem:
- Remove nvram ABI. There was no complaints about the deprecation for
the last 3 years.
- Improve RTC device allocation and registration
- Now available for ARCH=um
Drivers:
- at91rm9200: correction and sam9x60 support
- ds1307: improve ACPI support
- mxc: now DT only
- pcf2127: watchdog support now needs the reset-source property
- pcf8523: set range
- rx6110: i2c support"
* tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits)
rtc: pcf2127: only use watchdog when explicitly available
dt-bindings: rtc: add reset-source property
rtc: fix RTC removal
rtc: s3c: Remove dead code related to periodic tick handling
rtc: s3c: Disable all enable (RTC, tick) bits in the probe
rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
rtc: test: remove debug message
rtc: mxc{,_v2}: enable COMPILE_TEST
rtc: enable RTC framework on ARCH=um
rtc: pcf8523: use BIT
rtc: pcf8523: set range
rtc: pcf8523: switch to devm_rtc_allocate_device
rtc: destroy mutex when releasing the device
rtc: shrink devm_rtc_allocate_device()
rtc: rework rtc_register_device() resource management
rtc: nvmem: emit an error message when nvmem registration fails
rtc: add devm_ prefix to rtc_nvmem_register()
rtc: nvmem: remove nvram ABI
Documentation: list RTC devres helpers in devres.rst
rtc: omap: use devm_pinctrl_register()
...
The current RTC set_offset_nsec value is not really intuitive to
understand.
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
The offset is calculated from twrite based on the assumption that t2 -
twrite == 1s. That means for the MC146818 RTC the offset needs to be
negative so that the write happens 500ms before t2.
It's easier to understand when the whole calculation is based on t2. That
avoids negative offsets and the meaning is obvious:
t2 - twrite: The time defined by the chip when seconds increment
after the write.
twrite - tsched: The time for the transport to the point where the chip
is updated.
==> set_offset_nsec = t2 - tsched
ttransport = twrite - tsched
tRTCinc = t2 - twrite
==> set_offset_nsec = ttransport + tRTCinc
tRTCinc is a chip property and can be obtained from the data sheet.
ttransport depends on how the RTC is connected. It is close to 0 for
directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the
time required to send the update over the bus. This can be estimated or
even calibrated, but that's a different problem.
Adjust the implementation and update comments accordingly.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de
The offset which is used to steer the start of an RTC synchronization
update via rtc_set_ntp_time() is huge. The math behind this is:
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
twrite - tsched is the transport time for the write to hit the device.
t2 - twrite depends on the chip and is for most chips one second.
The rtc_set_ntp_time() calculation of tsched is:
tsched = t2 - 1sec - (t2 - twrite)
The default for the sync offset is 500ms which means that twrite - tsched
is 500ms assumed that t2 - twrite is one second.
This is 0.5 seconds off for RTCs which are directly accessible by IO writes
and probably for the majority of i2C/SPI based RTC off by an order of
magnitude. Set it to 5ms which should bring it closer to reality.
The default can be adjusted by drivers (rtc_cmos does so) and could be
adjusted further by a calibration method which is an orthogonal problem.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.960333166@linutronix.de
The offset for rtc_cmos must be -500ms to work correctly with the current
implementation of rtc_set_ntp_time() due to the following:
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
twrite - tsched is the transport time for the write to hit the device,
which is negligible for this chip because it's accessed directly.
t2 - twrite = 500ms according to the datasheet.
But rtc_set_ntp_time() calculation of tsched is:
tsched = t2 - 1sec - (t2 - twrite)
The default for the sync offset is 500ms which means that the write happens
at t2 - 1.5 seconds which is obviously off by a second for this device.
Make the offset -500ms so it works correct.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de
The MC146818 driver is prone to read garbage from the RTC. There are
several issues all related to the update cycle of the MC146818. The chip
increments seconds obviously once per second and indicates that by a bit in
a register. The bit goes high 244us before the actual update starts. During
the update the readout of the time values is undefined.
The code just checks whether the update in progress bit (UIP) is set before
reading the clock. If it's set it waits arbitrary 20ms before retrying,
which is ample because the maximum update time is ~2ms.
But this check does not guarantee that the UIP bit goes high and the actual
update happens during the readout. So the following can happen
0.997 UIP = False
-> Interrupt/NMI/preemption
0.998 UIP -> True
0.999 Readout <- Undefined
To prevent this rework the code so it checks UIP before and after the
readout and if set after the readout try again.
But that's not enough to cover the following:
0.997 UIP = False
Readout seconds
-> NMI (or vCPU scheduled out)
0.998 UIP -> True
update completes
UIP -> False
1.000 Readout minutes,....
UIP check succeeds
That can make the readout wrong up to 59 seconds.
To prevent this, read the seconds value before the first UIP check,
validate it after checking UIP and after reading out the rest.
It's amazing that the original i386 code had this actually correct and
the generic implementation of the MC146818 driver got it wrong in 2002 and
it stayed that way until today.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.594826678@linutronix.de
rtc_register_device() is a managed interface but it doesn't use devres
by itself - instead it marks an rtc_device as "registered" and the devres
callback for devm_rtc_allocate_device() takes care of resource release.
This doesn't correspond with the design behind devres where managed
structures should not be aware of being managed. The correct solution
here is to register a separate devres callback for unregistering the
device.
While at it: rename rtc_register_device() to devm_rtc_register_device()
and add it to the list of managed interfaces in devres.rst. This way we
can avoid any potential confusion of driver developers who may expect
there to exist a corresponding unregister function.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl
Some users check the return value of devm_rtc_nvmem_register() only in
order to emit an error message and then continue probing. This is fine
as an rtc can function without exposing nvmem but let's generalize it:
let's make the registration function emit the error message so that
users don't have to.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-7-brgl@bgdev.pl
The RTC core only reads the alarm from the hardware at boot time, to know
whether an alarm was already set before booting. It keeps track of all the
alarms after that so there is no need to ever read the auxiliary alarm.
Commit 3822d1bb0d ("rtc: sc27xx: Always read normal alarm when
registering RTC device") already effectively removed the capability to read
the auxiliary alarm as .read_alarm is always called with rtc->registered set
to false.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20201117212201.1288608-1-alexandre.belloni@bootlin.com
