#
d91612d7 |
|
02-Feb-2022 |
Samuel Holland <samuel@sholland.org> |
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 <samuel@sholland.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220203021736.13434-6-samuel@sholland.org
|
#
91389c39 |
|
18-Nov-2021 |
Samuel Holland <samuel@sholland.org> |
clk: sunxi-ng: Allow the CCU core to be built as a module Like the individual CCU drivers, it can be beneficial for memory consumption of cross-platform configurations to only load the CCU core on the relevant platform. For example, a generic arm64 kernel sees the following improvement when building the CCU core and drivers as modules: before: text data bss dec hex filename 13882360 5251670 360800 19494830 12977ae vmlinux after: text data bss dec hex filename 13734787 5086442 360800 19182029 124b1cd vmlinux So the result is a 390KB total reduction in kernel image size. The one early clock provider (sun5i) requires the core to be built in. Now that loading the MMC driver will trigger loading the CCU core, the MMC timing mode functions do not need a compile-time fallback. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20211119033338.25486-5-samuel@sholland.org
|
#
f6f64ed8 |
|
24-Jul-2017 |
Chen-Yu Tsai <wens@csie.org> |
clk: sunxi-ng: Add interface to query or configure MMC timing modes. Starting with the A83T SoC, Allwinner introduced a new timing mode for its MMC clocks. The new mode changes how the MMC controller sample and output clocks are delayed to match chip and board specifics. There are two controls for this, one on the CCU side controlling how the clocks behave, and one in the MMC controller controlling what inputs to take and how to route them. In the old mode, the MMC clock had 2 child clocks providing the output and sample clocks, which could be delayed by a number of clock cycles measured from the MMC clock's parent. With the new mode, the 2 delay clocks are no longer active. Instead, the delays and associated controls are moved into the MMC controller. The output of the MMC clock is also halved. The difference in how things are wired between the modes means that the clock controls and the MMC controls must match. To achieve this in a clear, explicit way, we introduce two functions for the MMC driver to use: one queries the hardware for the current mode set, and the other allows the MMC driver to request a mode. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|