- 11 Jul, 2020 4 commits
-
-
Stephen Boyd authored
- 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()
-
Loic Poulain authored
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/84Signed-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/123Signed-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.orgSigned-off-by:
Stephen Boyd <sboyd@kernel.org>
-
Ilia Lin authored
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. Signed-off-by:Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1593766185-16346-4-git-send-email-loic.poulain@linaro.orgSigned-off-by:
-
Ilia Lin authored
The driver provides kernel level API for other drivers to access the MSM8996 L2 cache registers. Separating the L2 access code from the PMU driver and making it public to allow other drivers use it. The accesses must be separated with a single spinlock, maintained in this driver. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
- 29 Jun, 2020 1 commit
-
-
Wei Yongjun authored
In case of error, the function dev_get_regmap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 5e77b4ef ("clk: qcom: Add ipq6018 apss clock controller") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200628023055.50608-1-weiyongjun1@huawei.comSigned-off-by:
-
- 26 Jun, 2020 2 commits
-
-
Stephen Boyd authored
- 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 ...
-
Maxime Ripard authored
The driver for the DVP controller in the BCM2711 was missing the MODULE_* macros resulting in a modpost warning at compilation. Fixes: 1bc95972 ("clk: bcm: Add BCM2711 DVP driver") Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200626112513.90816-1-maxime@cerno.techSigned-off-by:
-
- 23 Jun, 2020 7 commits
-
-
Stephen Boyd authored
* clk-vc5: clk: vc5: Enable addition output configurations of the Versaclock dt: Add additional option bindings for IDT VersaClock clk: vc5: Allow Versaclock driver to support multiple instances
-
Adam Ford authored
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.comSigned-off-by:
-
Adam Ford authored
The VersaClock driver now supports some additional bindings to support child nodes which can configure optional settings like mode, voltage and slew. This patch updates the binding document to describe what is available in the driver. Signed-off-by:
-
Adam Ford authored
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: -
Stephen Boyd authored
- Enable CPU clks on Qualcomm IPQ6018 SoCs * clk-qcom: clk: qcom: smd: Add support for MSM8936 rpm clocks dt-bindings: clock: rpmcc: Document MSM8936 compatible clk: qcom: smd: Add support for SDM660 rpm clocks clk: qcom: Add ipq6018 apss clock controller clk: qcom: Add DT bindings for ipq6018 apss clock controller clk: qcom: Add ipq apss pll driver dt-bindings: clock: add ipq6018 a53 pll compatible
-
Vincent Knecht authored
Add missing definition of rpm clk for msm8936 soc (also used by msm8939) Signed-off-by:
Vincent Knecht <vincent.knecht@mailoo.org> Link: https://lore.kernel.org/r/20200613072745.1249003-2-vincent.knecht@mailoo.orgSigned-off-by:
-
Vincent Knecht authored
Acked-by:
-
- 22 Jun, 2020 7 commits
-
-
Konrad Dybcio authored
Add rpm smd clocks, PMIC and bus clocks which are required on SDM630/660 (and APQ variants) for clients to vote on. Signed-off-by:
Konrad Dybcio <konradybcio@gmail.com> Link: https://lore.kernel.org/r/20200622090252.36568-1-konradybcio@gmail.comSigned-off-by:
-
Stephen Boyd authored
* clk-doc: clk: add function documentation for clk_hw_round_rate()
-
Sarang Mairal authored
Information about usage and prerequisites for this API. Signed-off-by:
Sarang Mairal <sarangmairal@gmail.com> Link: https://lore.kernel.org/r/20200611021941.786-2-sarangmairal@gmail.comSigned-off-by:
-
Sivaprakash Murugesan authored
The CPU on Qualcomm ipq6018 devices are clocked primarily by a aplha PLL and xo which are connected to a mux and enable block. Add support for the mux and enable block which feeds the CPU on ipq6018 devices. Reviewed-by:
Sivaprakash Murugesan <sivaprak@codeaurora.org> Link: https://lore.kernel.org/r/1592800092-20533-5-git-send-email-sivaprak@codeaurora.orgSigned-off-by:
-
Sivaprakash Murugesan authored
Add dt-binding for ipq6018 apss clock controller Acked-by:
-
Sivaprakash Murugesan authored
The CPUs on Qualcomm ipq based devices are clocked by an alpha PLL. Add support for the apss pll found on ipq based devices which can support CPU frequencies above 1Ghz. Signed-off-by:
-
Sivaprakash Murugesan authored
cpus on ipq6018 are clocked by a53 pll, add device compatible for a53 pll found on ipq6018 devices. Reviewed-by:
-
- 20 Jun, 2020 19 commits
-
-
Stephen Boyd authored
* clk-socfpga: clk: socfpga: agilex: mpu_l2ram_clk should be mpu_ccu_clk clk: socfpga: agilex: add nand_x_clk and nand_ecc_clk dt-bindings: agilex: add NAND_X_CLK and NAND_ECC_CLK
-
Dinh Nguyen authored
Preliminary documentation documented the mpu_l2ram_clk, but since then, the mpu_l2ram_clk is no longer documented. It's now referred to as mpu_ccu_clk. Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Link: https://lore.kernel.org/r/20200616202417.14376-3-dinguyen@kernel.orgSigned-off-by:
-
Dinh Nguyen authored
And the nand_x_clk and nand_ecc_clk. Make the nand_x_clk be the main clock that is feeding the NAND IP and correct it's parent to be the l4_mp_clk. Signed-off-by:
-
Dinh Nguyen authored
Add the NAND_X_CLK and NAND_ECC_CLK clocks. Signed-off-by:
-
Maxime Ripard authored
The CPU clock has had so far a bunch of quirks to expose the clock tree properly, but since we reverted to exposing them through the MMIO driver, we can remove that code from the firmware driver. Acked-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by:
-
Maxime Ripard authored
The PLLB rate will be changed through the firmware clocks drivers and will change behind this drivers' back, so we don't want to cache the rate. Acked-by:
-
Maxime Ripard authored
While some clock types allow for each clock to specify its own custom flags, the PLLs can't. We will need this for the PLLB, so let's add it. Acked-by:
-
Maxime Ripard authored
This reverts commit 2256d893. Since we will be expanding the firmware clock driver, we'll need to remove the quirks to deal with the PLLB. However, we still want to expose the clock tree properly, so having that clock in the MMIO driver will allow that. Acked-by:
-
Maxime Ripard authored
We've registered the firmware clocks using their ID as name, but it's much more convenient to register them using their proper name. Since the firmware doesn't provide it, we have to duplicate it. Acked-by:
-
Maxime Ripard authored
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:
-
Maxime Ripard authored
While the firmware allows us to discover the available clocks, we need to discriminate those clocks to only register the ones meaningful to Linux. The firmware also doesn't provide a clock name, so having a list of the ID will help us to give clocks a proper name later on. Acked-by:
-
Maxime Ripard authored
For the upcoming registration of the clocks provided by the firmware, make sure it's exposed to the device tree providers. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
The raspberrypi_register_pllb has been returning an integer so far to notify whether the functions has exited successfully or not. However, the OF provider functions in the clock framework require access to the clk_hw structure so that we can expose those clocks to device tree consumers. Since we'll want that for the future clocks, let's return a clk_hw pointer instead of the return code. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
The driver only supports the pllb for now and all the clock framework hooks are a mix of the generic firmware interface and the specifics of the pllb. Since we will support more clocks in the future let's split the generic and specific hooks Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
The raspberrypi_fw_pll_is_on function doesn't only apply to PLL registered in the driver, but any clock exposed by the firmware. Since we also implement the is_prepared hook, make the function consistent with the other function names. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
The raspberry_clock_property only takes the clock ID as an argument, but now that we have a clock data structure it makes more sense to just pass that structure instead. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
The driver has really only supported one clock so far and has hardcoded the ID used in communications with the firmware in all the functions implementing the clock framework hooks. Let's store that in the clock data structure so that we can support more clocks later on. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
So far the driver has really only been providing a single clock, and stored both the data associated to that clock in particular with the data associated to the "controller". Since we will change that in the future, let's decouple the clock data from the provider data. Cc: Michael Turquette <mturquette@baylibre.com> Cc: linux-clk@vger.kernel.org Acked-by:
-
Maxime Ripard authored
The raspberrypi firmware clock driver has a min_rate / max_rate clamping by storing the info it needs in a private structure. However, the CCF already provides such a facility, so we can switch to it to remove the boilerplate. Reviewed-by:
-
