u-boot.git/drivers/rtc, branch v2022.04 Unnamed repository; edit this file 'description' to name the repository. drivers: rtc: fix null pointer access in armada38x_rtc_reset 2022-03-04T07:38:05+00:00 Francois Berder fberder@outlook.fr 2022-02-28T09:31:45+00:00 2454de2c34531941756d259771fd0266ea2d5d0b Replace null pointer by pointer to device registers when calling armada38x_rtc_write. Signed-off-by: Francois Berder <fberder@outlook.fr> Reviewed-by: Stefan Roese <sr@denx.de> 
Replace null pointer by pointer to device registers when calling
armada38x_rtc_write.

Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Stefan Roese <sr@denx.de>
rtc: ds1307: Add bindings for microchip, mcp7940x 2022-02-17T13:17:07+00:00 Pali Rohár pali@kernel.org 2022-02-14T10:34:22+00:00 48c144f8ef9c6b35dc76b803bf8277131993381f Compatible string microchip,mcp7940x is used by Turris Mox DTS file in Linux kernel and U-Boot ds1307.c driver works fine with it. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> 
Compatible string microchip,mcp7940x is used by Turris Mox DTS file in
Linux kernel and U-Boot ds1307.c driver works fine with it.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
rtc: pcf2127: remove U-Boot specific compatible string 2022-02-01T09:38:07+00:00 Vladimir Oltean vladimir.oltean@nxp.com 2022-01-03T12:47:30+00:00 ad1ff53218a2abac184453ef35ec98ccdd530c9f Now that all in-tree boards have been converted to the compatible strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Michael Walle <michael@walle.cc> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com> 
Now that all in-tree boards have been converted to the compatible
strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one.

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
rtc: pcf2127: sync with Linux compatible strings 2022-02-01T09:38:07+00:00 Vladimir Oltean vladimir.oltean@nxp.com 2022-01-03T12:47:23+00:00 7c67ef3f3fd1c433abc5dab318258cc7077028af Allow this driver to be used by boards which inherit their device trees from Linux. Compatibility is temporarily retained with the old compatible string which is U-Boot specific, and will be removed after a few changes. Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Michael Walle <michael@walle.cc> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com> 
Allow this driver to be used by boards which inherit their device trees
from Linux. Compatibility is temporarily retained with the old
compatible string which is U-Boot specific, and will be removed after a
few changes.

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
rtc: ds1337: fix compatible string typo 2021-11-12T00:02:44+00:00 Clemens Gruber clemens.gruber@pqgruber.com 2021-11-05T13:46:50+00:00 6f84e809d9a373961d34f5b408bf44702b8c978c The driver supports the ds1339 as well, which was probably intended by the author but prevented by a typo. Fix the typo. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> 
The driver supports the ds1339 as well, which was probably intended by
the author but prevented by a typo. Fix the typo.

Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Merge tag 'u-boot-imx-20211020' of https://source.denx.de/u-boot/custodians/u-boot-imx 2021-10-20T18:24:09+00:00 Tom Rini trini@konsulko.com 2021-10-20T18:24:09+00:00 79b8849d4c1e73df2a79a1d5a5f6166d0dd67a12 u-boot-imx-20211020 ------------------- First PR from u-boot-imx for 2022.01 CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/9535 - new board: kontron-sl-mx8mm - imx8m: - fix secure boot - imx ESDHC: fixes - i.MX53: Support thum2, bmode and fixes for Menlo board usbarmory switch to Ethernet driver model - imx6 : - DDR calibration for Toradex boards - imx7: - Fixes - Updated gateworks boards (ventana / venice) # gpg verification failed. 
u-boot-imx-20211020
-------------------

First PR from u-boot-imx for 2022.01

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/9535

- new board: kontron-sl-mx8mm
- imx8m:
	- fix secure boot
- imx ESDHC: fixes
- i.MX53: Support thum2, bmode and fixes for Menlo board
	  usbarmory switch to Ethernet driver model
- imx6 :
	- DDR calibration for Toradex boards
- imx7:
	- Fixes
- Updated gateworks boards (ventana / venice)

# gpg verification failed.
rtc: ds1307: Handle oscillator-stop bit correctly 2021-10-12T20:49:21+00:00 Mark Tomlinson mark.tomlinson@alliedtelesis.co.nz 2021-09-27T21:10:42+00:00 07c652400d4e67cd11ada02b84c60e73bb031130 The DS1307 driver was originally based on the DS1337 driver. However, the functionality of the clock set/get functions has diverged. In the original DS1337 driver, the set/get functions did the following: 1) Setting the clock ensured the oscillator was enabled. 2) Getting the clock checked and reset the oscillator-stop flag. The DS1307 does not have an oscillator-stop flag, but the driver tried (incorrectly) to emulate this by ensuring the oscillator was running. It really makes no sense to start a stopped clock without setting it. This patch makes the DS1307 driver behave like the original DS1337 driver again. For the DS1307 itself, this is just a removal of code, since there is no oscillator-fail bit to check or reset, and the clock is started when it is set. Since the DS1307 driver can now also be used for the DS1337 and DS1340 which do have this bit, add code to handle the oscillator-stop bit in the same was the original DS1337 driver did -- i.e. report that the oscillator had stopped and clear the flag. This means that setting the date using the date command (which does both a get and a set) will now clear the oscillator-stop flag in addition to setting and starting the clock. The old-style (non-DM) code has not been updated and will be removed in a future patch. Note that this older code does not support the DS1337, as there is a separate driver for this. Also note that the original (DM) code used the wrong control-register address for the DS1337. Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz> 
The DS1307 driver was originally based on the DS1337 driver. However,
the functionality of the clock set/get functions has diverged. In the
original DS1337 driver, the set/get functions did the following:
  1) Setting the clock ensured the oscillator was enabled.
  2) Getting the clock checked and reset the oscillator-stop flag.
The DS1307 does not have an oscillator-stop flag, but the driver tried
(incorrectly) to emulate this by ensuring the oscillator was running. It
really makes no sense to start a stopped clock without setting it.

This patch makes the DS1307 driver behave like the original DS1337
driver again. For the DS1307 itself, this is just a removal of code,
since there is no oscillator-fail bit to check or reset, and the clock
is started when it is set. Since the DS1307 driver can now also be used
for the DS1337 and DS1340 which do have this bit, add code to handle the
oscillator-stop bit in the same was the original DS1337 driver did --
i.e. report that the oscillator had stopped and clear the flag.

This means that setting the date using the date command (which does both
a get and a set) will now clear the oscillator-stop flag in addition to
setting and starting the clock.

The old-style (non-DM) code has not been updated and will be removed in
a future patch. Note that this older code does not support the DS1337,
as there is a separate driver for this. Also note that the original (DM)
code used the wrong control-register address for the DS1337.

Signed-off-by: Mark Tomlinson <mark.tomlinson@alliedtelesis.co.nz>
rtc: rv8803: add epson,rx8803 and epson,rx8900 compatible 2021-10-07T14:53:50+00:00 Heiko Thiery heiko.thiery@gmail.com 2021-09-23T09:14:32+00:00 e1918ce299a10797df0f0f8e3df992fd6ed89aa6 The RX8803 and RX8900 register layouts are compatible with the one of the RV8803. So add these to the compatibles. The same compatible strings are used and approved in linux kernel. Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Reviewed-by: Michael Walle <michael@walle.cc> 
The RX8803 and RX8900 register layouts are compatible with the one of
the RV8803. So add these to the compatibles.

The same compatible strings are used and approved in linux kernel.

Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Michael Walle <michael@walle.cc>
rtc: rx8025: revise single register write to use offset 2021-10-03T18:40:56+00:00 Mathew McBride matt@traverse.com.au 2021-09-17T06:46:04+00:00 701c04f331f8389c9def2f61ef2a5d7d3e3e5bfd Writing of individual registers was not functioning correctly as a 0 'offset' byte under DM-managed I2C was being appended in front of register we wanted to access. Signed-off-by: Mathew McBride <matt@traverse.com.au> 
Writing of individual registers was not functioning
correctly as a 0 'offset' byte under DM-managed
I2C was being appended in front of register we
wanted to access.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
rtc: rx8025: set date in a single i2c transaction 2021-10-03T18:40:56+00:00 Mathew McBride matt@traverse.com.au 2021-09-17T06:46:03+00:00 771fc0c0798a3c2f9d0c51cdf8f1f2eff90dbafb The RX8025/RX8035 does not like having it's time registers set byte-by-byte in separate I2C transactions. From the note at the top of the file, it appears target-dependent workarounds have been used in the past for this. Resolve this by setting the time registers in a single I2C transaction. As part of this, also ensure the '24/12' flag in the RTC is reset before writing the date (instead of after), otherwise the RX8035 will clear the seconds and minutes registers. Tested on Traverse Ten64 (NXP LS1088A) with RX8035. Signed-off-by: Mathew McBride <matt@traverse.com.au> 
The RX8025/RX8035 does not like having it's time registers
set byte-by-byte in separate I2C transactions.

From the note at the top of the file, it appears
target-dependent workarounds have been used in the
past for this.

Resolve this by setting the time registers in a single
I2C transaction.

As part of this, also ensure the '24/12' flag in the RTC
is reset before writing the date (instead of after), otherwise
the RX8035 will clear the seconds and minutes registers.

Tested on Traverse Ten64 (NXP LS1088A) with RX8035.

Signed-off-by: Mathew McBride <matt@traverse.com.au>