- Enable CPU clks on Qualcomm MSM8996 SoCs
* clk-qcom:
clk: qcom: Add CPU clock driver for msm8996
dt-bindings: clk: qcom: Add bindings for CPU clock for msm8996
soc: qcom: Separate kryo l2 accessors from PMU driver
clk: qcom: Fix return value check in apss_ipq6018_probe()
Each of the CPU clusters (Power and Perf) on msm8996 are
clocked via 2 PLLs, a primary and alternate. There are also
2 Mux'es, a primary and secondary all connected together
as shown below
+-------+
XO | |
+------------------>0 |
| |
PLL/2 | SMUX +----+
+------->1 | |
| | | |
| +-------+ | +-------+
| +---->0 |
| | |
+---------------+ | +----------->1 | CPU clk
|Primary PLL +----+ PLL_EARLY | | +------>
| +------+-----------+ +------>2 PMUX |
+---------------+ | | | |
| +------+ | +-->3 |
+--^+ ACD +-----+ | +-------+
+---------------+ +------+ |
|Alt PLL | |
| +---------------------------+
+---------------+ PLL_EARLY
The primary PLL is what drives the CPU clk, except for times
when we are reprogramming the PLL itself (for rate changes) when
we temporarily switch to an alternate PLL. A subsequent patch adds
support to switch between primary and alternate PLL during rate
changes.
The primary PLL operates on a single VCO range, between 600MHz
and 3GHz. However the CPUs do support OPPs with frequencies
between 300MHz and 600MHz. In order to support running the CPUs
at those frequencies we end up having to lock the PLL at twice
the rate and drive the CPU clk via the PLL/2 output and SMUX.
So for frequencies above 600MHz we follow the following path
Primary PLL --> PLL_EARLY --> PMUX(1) --> CPU clk
and for frequencies between 300MHz and 600MHz we follow
Primary PLL --> PLL/2 --> SMUX(1) --> PMUX(0) --> CPU clk
ACD stands for Adaptive Clock Distribution and is used to
detect voltage droops.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Rajendra Nayak: Initial RFC - https://lkml.org/lkml/2016/9/29/84
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Ilia Lin: - reworked clock registering
- Added clock-tree diagram
- non-builtin support
- clock notifier on rate change
- https://lkml.org/lkml/2018/5/24/123
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Loic Poulain: - fixed driver remove / clk deregistering
- Removed useless memory barriers
- devm usage when possible
- Fixed Kconfig depends
Link: https://lore.kernel.org/r/1593766185-16346-3-git-send-email-loic.poulain@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
HHI_VIID_CLK_CNTL[19] is not part of the public S805 datasheet. However,
the GXBB driver defines this bit as a gate called "vclk2" and in the
3.10 kernel GPL code dump the following line can found:
WRITE_LCD_CBUS_REG_BITS(HHI_VIID_CLK_CNTL, 0, 19, 1); //disable vclk2_en
Add this gate clock to the Meson8/Meson8b/Meson8m2 clock controller to
complete the VCLK2 clock tree.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200629203904.2989007-3-martin.blumenstingl@googlemail.com
This reverts commit 82f4b67f01.
According to a subsequent revert in the vendor kernel, the original
change was based on unclear documentation and was in fact incorrect.
Emprically, my board's HS200 eMMC at 200MHZ apparently gets lucky with a
phase where this had no impact, but limiting max-frequency to 150MHz to
match the nominal capability of the I/O pins made it virtually unusable,
constantly throwing errors and retuning. With this revert, it starts
behaving perfectly at 150MHz too.
Fixes: 82f4b67f01 ("clk: rockchip: fix wrong mmc sample phase shift for rk3328")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/c80eb52e34c03f817586b6b7912fbd4e31be9079.1589475794.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
- Make defines for bcm63xx-gate clks to use in DT
- Support gate clks on BCM6318 SoCs
- Add HDMI clks for BCM2711 SoCs
- Support BCM2711 SoC firmware clks
* clk-bcm: (42 commits)
clk: bcm: dvp: Add missing module informations
clk: bcm: rpi: Remove the quirks for the CPU clock
clk: bcm2835: Don't cache the PLLB rate
clk: bcm2835: Allow custom CCF flags for the PLLs
Revert "clk: bcm2835: remove pllb"
clk: bcm: rpi: Give firmware clocks a name
clk: bcm: rpi: Discover the firmware clocks
clk: bcm: rpi: Add an enum for the firmware clocks
clk: bcm: rpi: Add DT provider for the clocks
clk: bcm: rpi: Make the PLLB registration function return a clk_hw
clk: bcm: rpi: Split pllb clock hooks
clk: bcm: rpi: Rename is_prepared function
clk: bcm: rpi: Pass the clocks data to the firmware function
clk: bcm: rpi: Add clock id to data
clk: bcm: rpi: Create a data structure for the clocks
clk: bcm: rpi: Use CCF boundaries instead of rolling our own
clk: bcm: rpi: Make sure the clkdev lookup is removed
clk: bcm: rpi: Switch to clk_hw_register_clkdev
clk: bcm: rpi: Remove pllb_arm_lookup global pointer
clk: bcm: rpi: Make sure pllb_arm is removed
...
The (struct __prci_data).hw_clks.hws is an array with dynamic elements.
Using struct_size(pd, hw_clks.hws, ARRAY_SIZE(__prci_init_clocks))
instead of sizeof(*pd) to get the correct memory size of
struct __prci_data for sifive/fu540-prci. After applying this
modifications, the kernel runs smoothly with CONFIG_SLAB_FREELIST_RANDOM
enabled on the HiFive unleashed board.
Fixes: 30b8e27e3b ("clk: sifive: add a driver for the SiFive FU540 PRCI IP block")
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Drop CLK_IS_CRITICAL from fclk_div2. This was added because we didn't
know the relation between this clock and RGMII Ethernet. It turns out
that fclk_div2 is used as "timing adjustment clock" to generate the RX
delay on the MAC side - which was enabled by u-boot on Odriod-C1. When
using the RX delay on the PHY side or not using a RX delay at all then
this clock can be disabled.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200620161422.24114-1-martin.blumenstingl@googlemail.com
The existing driver is expecting the Versaclock to be pre-programmed,
and only sets the output frequency. Unfortunately, not all devices
are pre-programmed, and the Versaclock chip has more options beyond
just the frequency.
This patch enables the following additional features:
- Programmable voltage: 1.8V, 2.5V, or 3.3V
- Slew Percentage of normal: 85%, 90%, or 100%
- Output Type: LVPECL, CMOS, HCSL, or LVDS
Signed-off-by: Adam Ford <aford173@gmail.com>
Link: https://lore.kernel.org/r/20200603154329.31579-3-aford173@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Currently, the Versaclock driver is only expecting one instance and
uses hard-coded names for the various clock names. Unfortunately,
this is a problem when there is more than one instance of the driver,
because the subsequent instantiations of the driver use the identical
name. Each clock after the fist fails to load, because the clock
subsystem cannot handle two clocks with identical name.
This patch removes the hard-coded name arrays and uses kasprintf to
assign clock names based on names of their respective node and parent
node which gives each clock a unique identifying name.
For a verasaclock node with a name like:
versaclock5: versaclock_som@6a
The updated clock names would appear like:
versaclock_som.mux
versaclock_som.out0_sel_i2cb
versaclock_som.pfd
versaclock_som.pll
versaclock_som.fod3
versaclock_som.out4
versaclock_som.fod2
versaclock_som.out3
versaclock_som.fod1
versaclock_som.out2
versaclock_som.fod0
versaclock_som.out1
Signed-off-by: Adam Ford <aford173@gmail.com>
Link: https://lore.kernel.org/r/20200603154329.31579-1-aford173@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The RaspberryPi4 firmware actually exposes more clocks than are currently
handled by the driver and we will need to change some of them directly
based on the pixel rate for the display related clocks, or the load for the
GPU.
Since the firmware implements DVFS, this rate change can have a number of
side-effects, including adjusting the various PLL voltages or the PLL
parents. The firmware also implements thermal throttling, so even some
thermal pressure can change those parameters behind Linux back.
DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc
clocks, so updating any of them using the MMIO driver (and thus behind the
firmware's back) can lead to troubles, the arm clock obviously being the
most problematic.
In order to make Linux play as nice as possible with those constraints, it
makes sense to rely on the firmware clocks as much as possible. However,
the firmware doesn't seem to provide some equivalents to their MMIO
counterparts, so we can't really replace that driver entirely.
Fortunately, the firmware has an interface to discover the clocks it
exposes.
Let's use it to discover, register the clocks in the clocks framework and
then expose them through the device tree for consumers to use them.
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/438d73962741a8c5f7c689319b7443b930a87fde.1592210452.git-series.maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
