u-boot.git/drivers/rtc, branch v2022.01 Unnamed repository; edit this file 'description' to name the repository. 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>
rtc: rx8025: add support for EPSON RX8035. 2021-10-03T18:40:56+00:00 Mathew McBride matt@traverse.com.au 2021-09-17T06:46:02+00:00 9ca4ae2d2a7300e9d2bfdd0b818aacc854c7c617 The RX8035 is a newer model from EPSON which is very similar in operation to the RX8025. The changes mirror similar ones that will be in Linux 5.15: https://lore.kernel.org/all/20210709044518.28769-2-matt@traverse.com.au/ The UBOOT_DRIVER ID has also been corrected, previously it declared itself as rx8010sj_rtc which is a different driver. Signed-off-by: Mathew McBride <matt@traverse.com.au> 
The RX8035 is a newer model from EPSON which is
very similar in operation to the RX8025.

The changes mirror similar ones that will be
in Linux 5.15:
https://lore.kernel.org/all/20210709044518.28769-2-matt@traverse.com.au/

The UBOOT_DRIVER ID has also been corrected, previously
it declared itself as rx8010sj_rtc which is a different driver.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
rtc: rx8025: drop non-DM support 2021-10-03T18:40:56+00:00 Mathew McBride matt@traverse.com.au 2021-09-17T06:46:01+00:00 152ef916f8f3a8b650aa7ab1ea5b4e9555011536 A search of the tree showed there is only one user of this driver (soon to be two) - board/socrates The second user will be the Traverse Ten64 board. Both these boards have DM_RTC. Signed-off-by: Mathew McBride <matt@traverse.com.au> 
A search of the tree showed there is only one user
of this driver (soon to be two) - board/socrates

The second user will be the Traverse Ten64 board.

Both these boards have DM_RTC.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
treewide: Use OF_REAL instead of !OF_PLATDATA 2021-09-25T15:46:15+00:00 Simon Glass sjg@chromium.org 2021-08-07T13:24:04+00:00 95397385091da9d0d3acd7e69199ae23114ac22c Now that we have a 'positive' Kconfig option, use this instead of the negative one, which is harder to understand. Signed-off-by: Simon Glass <sjg@chromium.org> 
Now that we have a 'positive' Kconfig option, use this instead of the
negative one, which is harder to understand.

Signed-off-by: Simon Glass <sjg@chromium.org>
Remove including timestamp.h in version.h 2021-09-17T16:10:44+00:00 Pali Rohár pali@kernel.org 2021-08-02T13:18:38+00:00 121a165c51cd281e61c9d45c3919608af42ca9cd Header file version.h does not use anything from timestamp.h. Including of timestamp.h has side effect which cause recompiling object file at every make run because timestamp.h changes at every run. So remove timestamp.h from version.h and include timestamp.h in files which needs it. This change reduce recompilation time of final U-Boot binary when U-Boot source files were not changed as less source files needs to be recompiled. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> [trini: Add in lib/acpi/acpi_table.c and test/dm/acpi.c, rework a few others] Signed-off-by: Tom Rini <trini@konsulko.com> 
Header file version.h does not use anything from timestamp.h. Including of
timestamp.h has side effect which cause recompiling object file at every
make run because timestamp.h changes at every run.

So remove timestamp.h from version.h and include timestamp.h in files
which needs it.

This change reduce recompilation time of final U-Boot binary when U-Boot
source files were not changed as less source files needs to be recompiled.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Add in lib/acpi/acpi_table.c and test/dm/acpi.c, rework a few others]
Signed-off-by: Tom Rini <trini@konsulko.com>