rtc: use boolean values with device_init_wakeup()

device_init_wakeup() second argument is a bool type. Use proper boolean
values when calling it to match the type and to produce unambiguous code
whi

rtc: use boolean values with device_init_wakeup()

device_init_wakeup() second argument is a bool type. Use proper boolean
values when calling it to match the type and to produce unambiguous code
which is easier to understand.

Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: disable automatic clock input switching

The V3(s) will detect a valid external low frequency clock and if it is
not present will automatically switch to the internal one. This might
hide

rtc: sun6i: disable automatic clock input switching

The V3(s) will detect a valid external low frequency clock and if it is
not present will automatically switch to the internal one. This might
hide bugs and (hardware) configuration errors. It's even worse because
the internal RTC runs significantly slower (32.000Hz vs 32.768Hz).
Fortunately for us, the V3(s) has an (undocumented) bypass of this
switching and the driver already supports it by setting the
.has_auto_swt flag.

Signed-off-by: Michael Walle <[email protected]>
Acked-by: Chen-Yu Tsai <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: remove unnecessary message

The core already print a message once the rtc is successfully registered,
it is not necessary to print an other one.

Acked-by: Jernej Skrabec <jernej.skrabec@

rtc: sun6i: remove unnecessary message

The core already print a message once the rtc is successfully registered,
it is not necessary to print an other one.

Acked-by: Jernej Skrabec <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that mer

rtc: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: Add a determine_rate hook

The Allwinner sun6i RTC clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.

This is a bit odd, since set_parent

rtc: sun6i: Add a determine_rate hook

The Allwinner sun6i RTC clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.

This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidates to
trigger that parent change are either the assigned-clock-parents device
tree property or a call to clk_set_rate(), with determine_rate()
figuring out which parent is the best suited for a given rate.

The other trigger would be a call to clk_set_parent(), but it's far less
used, and it doesn't look like there's any obvious user for that clock.

Similarly, it doesn't look like the device tree using that clock driver
uses any of the assigned-clock properties on that clock.

So, the set_parent hook is effectively unused, possibly because of an
oversight. However, it could also be an explicit decision by the
original author to avoid any reparenting but through an explicit call to
clk_set_parent().

The latter case would be equivalent to setting the determine_rate
implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no
determine_rate implementation is provided, clk_round_rate() (through
clk_core_round_rate_nolock()) will call itself on the parent if
CLK_SET_RATE_PARENT is set, and will not change the clock rate
otherwise.

And if it was an oversight, then we are at least explicit about our
behavior now and it can be further refined down the line.

Cc: Alessandro Zummo <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Cc: Chen-Yu Tsai <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Cc: Samuel Holland <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Jernej Skrabec <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>

show more ...

rtc: sun6i: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_pr

rtc: sun6i: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.

Signed-off-by: Rob Herring <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: Always export the internal oscillator

On all variants of the hardware, the internal oscillator is one possible
parent for the AR100 clock. It needs to be exported so we can model that
re

rtc: sun6i: Always export the internal oscillator

On all variants of the hardware, the internal oscillator is one possible
parent for the AR100 clock. It needs to be exported so we can model that
relationship correctly in the devicetree.

Fixes: c56afc1844d6 ("rtc: sun6i: Expose internal oscillator through device tree")
Signed-off-by: Samuel Holland <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: add support for R329 RTC

Allwinner R329 has a RTC with a similar time storage with H616 but a
slightly different clock part.

As we have already handled the R329 RTC clocks in the CCU dr

rtc: sun6i: add support for R329 RTC

Allwinner R329 has a RTC with a similar time storage with H616 but a
slightly different clock part.

As we have already handled the R329 RTC clocks in the CCU driver, add a
compatible string to RTC driver to allow probing of the RTC.

Signed-off-by: Icenowy Zheng <[email protected]>
Signed-off-by: Samuel Holland <[email protected]>
Tested-by: Heiko Stuebner <[email protected]>
Reviewed-by: Heiko Stuebner <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Add NVMEM provider

The sun6i RTC provides 32 bytes of general-purpose data registers.
They can be used to save data in the always-on RTC power domain.
The registers are writable via 32-b

rtc: sun6i: Add NVMEM provider

The sun6i RTC provides 32 bytes of general-purpose data registers.
They can be used to save data in the always-on RTC power domain.
The registers are writable via 32-bit MMIO accesses only.

Expose them with a NVMEM provider so they can be used by other drivers.

Signed-off-by: Samuel Holland <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

Revert "clk: sunxi-ng: sun6i-rtc: Add support for H6"

This reverts commit 1738890a3165ccd0da98ebd3e2d5f9b230d5afa8.

Commit 1738890a3165 ("clk: sunxi-ng: sun6i-rtc: Add support for H6")
breaks HDMI

Revert "clk: sunxi-ng: sun6i-rtc: Add support for H6"

This reverts commit 1738890a3165ccd0da98ebd3e2d5f9b230d5afa8.

Commit 1738890a3165 ("clk: sunxi-ng: sun6i-rtc: Add support for H6")
breaks HDMI output on Tanix TX6 mini board. Exact reason isn't known,
but because that commit doesn't actually improve anything, let's just
revert it.

Cc: [email protected]
Signed-off-by: Jernej Skrabec <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>

show more ...

clk: sunxi-ng: sun6i-rtc: Add support for H6

H6 supports IOSC calibration and an ext-osc32k input. Unlike newer SoCs,
it has a single parent for its fanout clock.

Add support for H6 in the CCU driv

clk: sunxi-ng: sun6i-rtc: Add support for H6

H6 supports IOSC calibration and an ext-osc32k input. Unlike newer SoCs,
it has a single parent for its fanout clock.

Add support for H6 in the CCU driver, replacing the support in the
existing early OF clock provider.

Signed-off-by: Samuel Holland <[email protected]>
Acked-by: Stephen Boyd <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

clk: sunxi-ng: Add support for the sun6i RTC clocks

The RTC power domain in sun6i and newer SoCs manages the 16 MHz RC
oscillator (called "IOSC" or "osc16M") and the optional 32 kHz crystal
oscillat

clk: sunxi-ng: Add support for the sun6i RTC clocks

The RTC power domain in sun6i and newer SoCs manages the 16 MHz RC
oscillator (called "IOSC" or "osc16M") and the optional 32 kHz crystal
oscillator (called "LOSC" or "osc32k"). Starting with the H6, this power
domain also handles the 24 MHz DCXO (called variously "HOSC", "dcxo24M",
or "osc24M") as well. The H6 also adds a calibration circuit for IOSC.

Later SoCs introduce further variations on the design:
- H616 adds an additional mux for the 32 kHz fanout source.
- R329 adds an additional mux for the RTC timekeeping clock, a clock
for the SPI bus between power domains inside the RTC, and removes the
IOSC calibration functionality.

Take advantage of the CCU framework to handle this increased complexity.
This driver is intended to be a drop-in replacement for the existing RTC
clock provider. So some runtime adjustment of the clock parents is
needed, both to handle hardware differences, and to support the old
binding which omitted some of the input clocks.

Signed-off-by: Samuel Holland <[email protected]>
Acked-by: Stephen Boyd <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Add Allwinner H616 support

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
The RTC clock parts a

rtc: sun6i: Add Allwinner H616 support

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
The RTC clock parts are handled in a separate driver now, so we skip
the clock parts in this driver completely.

Signed-off-by: Andre Przywara <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Add support for broken-down alarm registers

Newer versions of the Allwinner RTC, for instance as found in the H616
SoC, not only store the current day as a linear number, but also change

rtc: sun6i: Add support for broken-down alarm registers

Newer versions of the Allwinner RTC, for instance as found in the H616
SoC, not only store the current day as a linear number, but also change
the way the alarm is handled: There are now two registers, that
explicitly store the wakeup time, in the same format as the current
time.

Add support for that variant by writing the requested wakeup time
directly into the registers, instead of programming the seconds left, as
the old SoCs required.

Reviewed by: Jernej Skrabec <[email protected]>

Signed-off-by: Andre Przywara <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Add support for linear day storage

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_

rtc: sun6i: Add support for linear day storage

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Fix time overflow handling

Using "unsigned long" for UNIX timestamps is never a good idea, and
comparing the value of such a variable against U32_MAX does not do
anything useful on 32-bi

rtc: sun6i: Fix time overflow handling

Using "unsigned long" for UNIX timestamps is never a good idea, and
comparing the value of such a variable against U32_MAX does not do
anything useful on 32-bit systems.

Use the proper time64_t type when dealing with timestamps, and avoid
cutting down the time range unnecessarily. This also fixes the flawed
check for the alarm time being too far into the future.

The check for this condition is actually somewhat theoretical, as the
RTC counts till 2033 only anyways, and 2^32 seconds from now is not
before the year 2157 - at which point I hope nobody will be using this
hardware anymore.

Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Enable the bus clock when provided

H6 and newer variants of the RTC hardware have a bus clock gate in the
PRCM CCU. This was not known at the time H6 support was added, so it was
not inc

rtc: sun6i: Enable the bus clock when provided

H6 and newer variants of the RTC hardware have a bus clock gate in the
PRCM CCU. This was not known at the time H6 support was added, so it was
not included in the H6 RTC binding, nor in the H6 PRCM CCU driver. Now
that this clock gate is documented, it is included in the A100 and D1
PRCM CCU drivers. Therefore, the RTC driver needs to have a consumer for
the clock gate to prevent Linux from disabling it.

Patch-changes: 3
- New patch for compatibility with new CCU drivers

Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Maxime Ripard <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Allow probing without an early clock provider

Some SoCs have an RTC supported by this RTC driver, but do not have an
early clock provider declared here. Currently, this prevents the RTC

rtc: sun6i: Allow probing without an early clock provider

Some SoCs have an RTC supported by this RTC driver, but do not have an
early clock provider declared here. Currently, this prevents the RTC
driver from probing, because it expects a global struct to already be
allocated. Fix probing the driver by copying the missing pieces from the
clock provider setup function, replacing them with the devm variants.

Signed-off-by: Samuel Holland <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: rework rtc_register_device() resource management

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

rtc: rework rtc_register_device() resource management

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 <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: Fix memleak in sun6i_rtc_clk_init

When clk_hw_register_fixed_rate_with_accuracy() fails,
clk_data should be freed. It's the same for the subsequent
two error paths, but we should also un

rtc: sun6i: Fix memleak in sun6i_rtc_clk_init

When clk_hw_register_fixed_rate_with_accuracy() fails,
clk_data should be freed. It's the same for the subsequent
two error paths, but we should also unregister the already
registered clocks in them.

Signed-off-by: Dinghao Liu <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rtc: sun6i: let the core handle rtc range

Let the rtc core check the date/time against the RTC range.

Tested-by: Paul Kocialkowski <[email protected]>
Link: https://lore.kernel.org/r/20

rtc: sun6i: let the core handle rtc range

Let the rtc core check the date/time against the RTC range.

Tested-by: Paul Kocialkowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: switch to rtc_time64_to_tm/rtc_tm_to_time64

Call the 64bit versions of rtc_tm time conversion.

Tested-by: Paul Kocialkowski <[email protected]>
Link: https://lore.kernel.org

rtc: sun6i: switch to rtc_time64_to_tm/rtc_tm_to_time64

Call the 64bit versions of rtc_tm time conversion.

Tested-by: Paul Kocialkowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: Make external 32k oscillator optional

Some boards, like OrangePi PC2 (H5), OrangePi Plus 2E (H3) and Tanix TX6
(H6) don't have external 32kHz oscillator. Till H6, it didn't really
matter

rtc: sun6i: Make external 32k oscillator optional

Some boards, like OrangePi PC2 (H5), OrangePi Plus 2E (H3) and Tanix TX6
(H6) don't have external 32kHz oscillator. Till H6, it didn't really
matter if external oscillator was enabled because HW detected error and
fall back to internal one. H6 has same functionality but it's the first
SoC which have "auto switch bypass" bit documented and always enabled in
driver. This prevents RTC to work correctly if external crystal is not
present on board. There are other side effects - all peripherals which
depends on this clock also don't work (HDMI CEC for example).

Make clocks property optional. If it is present, select external
oscillator. If not, stay on internal.

Signed-off-by: Jernej Skrabec <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: Add support for RTC clocks on R40

When support for the R40 in the rtc-sun6i driver was split out for a
separate compatible string, only the RTC half was covered, and not the
clock half.

rtc: sun6i: Add support for RTC clocks on R40

When support for the R40 in the rtc-sun6i driver was split out for a
separate compatible string, only the RTC half was covered, and not the
clock half. Unfortunately this results in the whole driver not working,
as the RTC half expects the clock half to have been initialized.

Add support for the clock part as well. The clock part is like the H3,
but does not need to export the internal oscillator, nor does it have
a gateable LOSC external output.

This fixes issues with WiFi and Bluetooth not working on the BPI M2U.

Fixes: d6624cc75021 ("rtc: sun6i: Add R40 compatible")
Cc: <[email protected]> # 5.3.x
Signed-off-by: Chen-Yu Tsai <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

rtc: sun6i: Remove struct device from sun6i_rtc_dev

struct device in struct sun6i_rtc_dev is not used, remove it.

Signed-off-by: Nobuhiro Iwamatsu <[email protected]>
Link: https://lore.kernel.o

rtc: sun6i: Remove struct device from sun6i_rtc_dev

struct device in struct sun6i_rtc_dev is not used, remove it.

Signed-off-by: Nobuhiro Iwamatsu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...