The RTC core is always calling rtc_valid_tm after the read_time callback.
It is not necessary to call it just before returning from the callback.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Avoid allocating memory for struct nvmem_config as it is only necessary at
the nvmem registration.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Call rtc_nvmem_register instead of letting the core do it and stop using
the nvmem_config member of struct rtc_device.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Make Epson RX8130 device tree and ACPI aware.
Fixes: ee0981be77 ("rtc: ds1307: Add support for Epson RX8130CE")
Signed-off-by: Bastian Stender <bst@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The current code for checking and fixing the weekday in ds1307_probe
faces some issues:
- This check is applied to all chips even if its applicable (AFAIK)
to mcp794xx only
- The check uses MCP794XX constants for registers and bits even though
it's executed also on other chips (ok, this could be fixed easily)
- It relies on tm_wday being properly populated when core calls set_time
and set_alarm. This is not guaranteed at all.
First two issue we could solve by moving the check to the
mcp794xx-specific initialization (where also VBATEN flag is set).
The proposed alternative is in the set_alarm path for mcp794xx only and
calculates the alarm weekday based on the current weekday in the RTC
timekeeping regs and the difference between alarm date and current date.
So we are fine with any weekday even if it doesn't match the date.
Still there are cases where this could fail, e.g.:
- rtc date/time + weekday have power-on-reset default values
- alarm is set to actual date/time + x
- set_time is called (may change diff between rtc weekday and actual
weekday)
But similar issues we have with the current code too:
- rtc date/time + weekday have power-on-reset default values
- alarm is set to rtc date/time + x
- set_time is called before the alarm triggers
Using random rtc date/time with relative alarms simply can interfere
with set_time. I'm not totally convinced of either option yet.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Alignment should always match open parenthesis.
Also remove two unnecessary blank lines
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Use sizeof where possible to ensure we don't read/write more than the
allocated buffer.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
ds1307->regs is never used before being read or initialized locally. There
is no point in keeping a copy in memory.
Also limit the size of the read buffer to what is really used, rename buf
to regs for consistency and use sizeof() where possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This adds support for reading and writing date/time from/to ds1341 chip.
ds1341 chip has other features - alarms, input clock (can be used instead
of intercal oscillator for better accuracy), output clock ("square wave
generation"). However, not all of that is available at the same time.
Same chip pins, CLKIN/nINTA and SQW/nINTB, can be used either for
input/output clocks, or for alarm interrupts. Role of these pins on
particular board depends on hardware wiring.
We can add device tree properties that describe if each of pins is wired
as clock, or as interrupt, or left unconnected, and enable support for
corresponding functionality based on that. But that is cumbersome, requires
hardware for testing, and has to deal with bit enabling/disabling output
clock also affects which pins alarm interrupts are routed to.
Another factor is that there are hardware setups (i.e. ZII RDU2) that
power DS1341 from SuperCap, which makes power saving critical. For such
setups, kernel driver should leave register bits that control mentioned
pins in the state configured by bootloader.
Given all that, it was decided to limit support to "only date/time" for
now. That is enough for common use case. Full (and cumbersome)
implementation can be added later if ever needed.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Remove member nvram_offset from struct ds1307 and use the value stored
in struct chip_desc directly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Factor out offset to struct chip_desc and remove it from struct ds1307.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Factor out rtc_ops to struct chip_desc and use ds13xx_rtc_ops as default.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Factor out irq_handler to struct chip_desc and use ds1307_irq as default.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Change the usage of variable want_irq to reflect its name. Don't set
it to true in case wakeup is enabled but no interrupt number is given.
In addition set variable ds1307_can_wakeup_device if chip->alarm
is set only.
This allows to simplify the code and make it better understandable.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Instead of storing the trickle_charger_setup value in struct chip_desc
we can let function ds1307_trickle_init return it because it's used
in the probe function only.
This allows us to constify struct chip_desc variables in a next step.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Factor out the bbsqi bit to struct chip_desc.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The irq number is used in the probe function only, so we don't have
to store it in struct ds1307.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Current max_register setting breaks reading nvram on certain chips and
also reading the standard registers on RX8130 where register map starts
at 0x10.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Fixes: 11e5890b53 "rtc: ds1307: convert driver to regmap"
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Commit 8b44f5be20 ("ARM: dts: armada: replace isil,irq2-can-wakeup-machine with wakeup-source property")
removed the last usage of "isil,irq2-can-wakeup-machine" almost
two years ago. So I think we can get rid of supporting this
legacy binding.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Instead of adding a binary sysfs attribute from the driver (which suffers
from a race condition as the attribute appears after the device), use the
core to register an nvmem device.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This removes a possible race condition and crash and allows for further
improvement of the driver.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The ds1308 variant is very similar to the already supported ds1338
variant, it have more debug registers and a square wave clock output.
Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The driver has lots of places with chip-specific code what doesn't
necessarily facilitate maintenance.
Let's describe chip-specific differences in century bit handling
in struct chip_desc to improve this.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
After the switch to regmap we can now make use of regmap_update_bits
to simplify read/modify/write ops.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Add support for yet another RTC chip, Epson RX8130CE. This time around,
the chip has slightly permutated registers and also the register starts
at 0x10 instead of 0x0 .
So far, we only support the RTC and NVRAM parts of the chip, Alarm and
Timer is not supported.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This patch extends the fixes for ds1337, ds1339, ds3231 in commit
8bc2a40730 ("rtc: ds1307: add support for the DT property
'wakeup-source'") to mcp794xx devices, so that those parts can similarly be
used as a wakeup source without an IRQ to the processor.
Tested on Raspberry Pi ZeroW with MCP79400.
Signed-off-by: David Lowe <dave-lowe@ntlworld.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This patch converts the ds1307 driver to using regmap. It's a rather
big patch and I can test with DS3231 only. With this chip it's
working fine.
I'd appreciate if people with other supported hardware could test as
well.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The m41t0 variant is very similar to the already supported m41t00
variant, with the notable exception of the oscillator fail bit.
The data sheet notes:
If the oscillator fail (OF) bit is internally set to a '1,' this
indicates that the oscillator has either stopped, or was stopped
for some period of time and can be used to judge the validity of
the clock and date data.
The bit will get cleared with a regular write of the system time,
so no changes are needed to clear it.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This patch enables ACPI support for rtc-ds1307 driver.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported
by the ds1307 driver.
Acked-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Add an option to properly support the century bit of ds1337 and compatibles
and ds1340.
Because the driver had a bug until now, it is not possible to switch users
to the fixed code directly as RTCs in the field will wrongly have the
century bit set.
Acked-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Since commit d68778b80d ("rtc: initialize output parameter for read
alarm to "uninitialized"") there is no need to explicitly set
unsupported members to -1. So drop the respective assignments from
drivers.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The reset value of weekday is 0x1. This is wrong since
the reset values of the day/month/year make up to Jan 1 2001.
When computed weekday comes out to be Monday. On a scale
of 1-7(Sunday - Saturday) it should be 0x2. So we should not
be relying on the reset value.
Hence compute the wday using the current date/month/year values.
Check if reset wday is any different from the computed wday,
If different then set the wday which we computed using
date/month/year values.
Document Referred:
http://ww1.microchip.com/downloads/en/DeviceDoc/20002266F.pdf
Fixes: 1d1945d261 "drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips"
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This flag is a no-op now (see commit 47b0eeb3dc "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Michael Tatarinov <kukabu@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
If a previously-set alarm was disabled and then triggered, it may still
be pending when a new alarm is configured.
Then, if the alarm is enabled before the pending alarm is cleared, then
an interrupt is immediately raised.
Unfortunately, when the alarm is cleared and enabled during the same I²C
block write, the chip (at least the DS1339 I have) considers that the
alarm is enabled before it is cleared, and raises an interrupt.
This patch ensures that the pending alarm is cleared before the alarm is
enabled.
Signed-off-by: Nicolas Boullis <nboullis@debian.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The i2c_smbus_read_i2c_block_data function returns 0 on success, not the
number of bytes written.
Hence, when there are 32 bytes or less to send, the
ds1307_native_smbus_write_block_data function returns 0 on success,
while it returns the number of bytes when there are more than 32.
The ds1307_write_block_data always returns the number of bytes on
success.
Signed-off-by: Nicolas Boullis <nboullis@debian.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
With commit 8bc2a40730 ("rtc: ds1307: add support for the
DT property 'wakeup-source'") we lost the ability for rtc irq
functionality for devices that are actually hooked on a real IRQ
line and have capability to wakeup as well. This is not an expected
behavior. So, instead of just not requesting IRQ, skip the IRQ
requirement only if interrupts are not defined for the device.
Fixes: 8bc2a40730 ("rtc: ds1307: add support for the DT property 'wakeup-source'")
Reported-by: Tony Lindgren <tony@atomide.com>
Cc: Michael Lange <linuxstuff@milaw.biz>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
while retrieving temperature from ds3231, the result may be overflow
since s16 is too small for a multiplication with 250.
ie. if temp_buf[0] == 0x2d, the result (s16 temp) will be negative.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Tested-by: Michael Tatarinov <kukabu@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
DS3231 has programmable square-wave output signal.
This enables to use this feature as a clock provider of
common clock framework.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Andrea Greco