summaryrefslogtreecommitdiff
path: root/drivers/clk/clk.c
AgeCommit message (Collapse)AuthorFilesLines
2022-12-12Merge branches 'clk-mediatek', 'clk-trace', 'clk-qcom' and 'clk-microchip' ↵Stephen Boyd1-0/+32
into clk-next - Tracepoints for clk_rate_request structures * clk-mediatek: clk: mediatek: fix dependency of MT7986 ADC clocks clk: mediatek: Change PLL register API for MT8186 clk: mediatek: Add new clock driver to handle FHCTL hardware dt-bindings: clock: mediatek: Add new bindings of MediaTek frequency hopping clk: mediatek: Export PLL operations symbols clk: mediatek: mt8186-topckgen: Add GPU clock mux notifier clk: mediatek: mt8186-mfg: Propagate rate changes to parent clk: mediatek: mt8195-topckgen: Drop flags for main/univpll fixed factors clk: mediatek: mt8192: Drop flags for main/univpll fixed factors clk: mediatek: mt6795-topckgen: Drop flags for main/sys/univpll fixed factors clk: mediatek: mt8173: Drop flags for main/sys/univpll fixed factors clk: mediatek: mt8183: Drop flags for sys/univpll fixed factors clk: mediatek: mt8183: Compress top_divs array entries clk: mediatek: mt8186-topckgen: Drop flags for main/univpll fixed factors clk: mediatek: clk-mtk: Allow specifying flags on mtk_fixed_factor clocks * clk-trace: clk: Add trace events for rate requests clk: Store clk_core for clk_rate_request * clk-qcom: (69 commits) clk: qcom: rpmh: add support for SM6350 rpmh IPA clock clk: qcom: mmcc-msm8974: use parent_hws/_data instead of parent_names clk: qcom: mmcc-msm8974: move clock parent tables down clk: qcom: mmcc-msm8974: use ARRAY_SIZE instead of specifying num_parents clk: qcom: gcc-msm8974: use parent_hws/_data instead of parent_names clk: qcom: gcc-msm8974: move clock parent tables down clk: qcom: gcc-msm8974: use ARRAY_SIZE instead of specifying num_parents dt-bindings: clocks: qcom,mmcc: define clocks/clock-names for MSM8974 dt-bindings: clock: split qcom,gcc-msm8974,-msm8226 to the separate file clk: qcom: gcc-ipq4019: switch to devm_clk_notifier_register clk: qcom: rpmh: remove usage of platform name clk: qcom: rpmh: rename VRM clock data clk: qcom: rpmh: rename ARC clock data clk: qcom: rpmh: support separate symbol name for the RPMH clocks clk: qcom: rpmh: remove platform names from BCM clocks clk: qcom: rpmh: drop all _ao names clk: qcom: rpmh: reuse common duplicate clocks clk: qcom: rpmh: group clock definitions together clk: qcom: rpm: drop the platform from clock definitions clk: qcom: rpm: drop the _clk suffix completely ... * clk-microchip: clk: microchip: enable the MPFS clk driver by default if SOC_MICROCHIP_POLARFIRE clk: microchip: check for null return of devm_kzalloc()
2022-12-08clk: Add trace events for rate requestsMaxime Ripard1-0/+31
It is currently fairly difficult to follow what clk_rate_request are issued, and how they have been modified once done. Indeed, there's multiple paths that can be taken, some functions are recursive and will just forward the request to its parent, etc. Adding a lot of debug prints is just not very convenient, so let's add trace events for the clock requests, one before they are submitted and one after they are returned. That way we can simply toggle the tracing on without modifying the kernel code and without affecting performances or the kernel logs too much. Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-rate-request-tracing-v2-2-5170b363c413@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-12-08clk: Store clk_core for clk_rate_requestMaxime Ripard1-0/+1
The struct clk_rate_request is meant to store the context around a rate request such as the parent, boundaries, and so on. However, it doesn't store the clock the rate request is submitted to, which makes debugging difficult. Let's add a pointer to the relevant clk_core instance in order to improve the debugging of rate requests in a subsequent patch. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-rate-request-tracing-v2-1-5170b363c413@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-28clk: Initialize max_rate in struct clk_rate_requestMaxime Ripard1-0/+1
Since commit b46fd8dbe8ad ("clk: Zero the clk_rate_request structure"), the clk_core_init_rate_req() function clears the struct clk_rate_request passed as argument. However, the default value for max_rate isn't 0 but ULONG_MAX, and we end up creating a clk_rate_request instance where the maximum rate is 0. Let's initialize max_rate to ULONG_MAX properly. Fixes: b46fd8dbe8ad ("clk: Zero the clk_rate_request structure") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-3-f3ef80518140@cerno.tech Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-28clk: Initialize the clk_rate_request even if clk_core is NULLMaxime Ripard1-1/+4
Since commit c35e84b09776 ("clk: Introduce clk_hw_init_rate_request()"), users that used to initialize their clk_rate_request by initializing their local structure now rely on clk_hw_init_rate_request(). This function is backed by clk_core_init_rate_req(), which will skip the initialization if either the pointer to struct clk_core or to struct clk_rate_request are NULL. However, the core->parent pointer might be NULL because the clock is orphan, and we will thus end up with our local struct clk_rate_request left untouched. And since clk_hw_init_rate_request() doesn't return an error, we will then call a determine_rate variant with that unitialized structure. In order to avoid this, let's clear our clk_rate_request if the pointer to it is valid but the pointer to struct clk_core isn't. Fixes: c35e84b09776 ("clk: Introduce clk_hw_init_rate_request()") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-2-f3ef80518140@cerno.tech Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-28clk: Remove WARN_ON NULL parent in clk_core_init_rate_req()Maxime Ripard1-1/+1
If a clock has CLK_SET_RATE_PARENT, but core->parent is NULL (most likely because it's orphan), callers of clk_core_init_rate_req() will blindly call this function leading to a very verbose warning. Since it's a fairly common situation, let's just remove the WARN_ON but keep the check that prevents us from dereferencing the pointer. Interestingly, it fixes a regression on the Mediatek MT8195 where the GPU would stall during a clk_set_rate for its main clock. We couldn't come up with a proper explanation since the condition is essentially the same. It was then assumed that it could be timing related since printing the warning stacktrace takes a while, but we couldn't replicate the failure by using fairly large (10ms) mdelays. Fixes: 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent") Reported-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-1-f3ef80518140@cerno.tech Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-16Merge tag 'clk-for-linus' of ↵Linus Torvalds1-65/+221
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull more clk updates from Stephen Boyd: "This is the final part of the clk patches for this merge window. The clk rate range series needed another week to fully bake. Maxime fixed the bug that broke clk notifiers and prevented this from being included in the first pull request. He also added a unit test on top to make sure it doesn't break so easily again. The majority of the series fixes up how the clk_set_rate_*() APIs work, particularly around when the rate constraints are dropped and how they move around when reparenting clks. Overall it's a much needed improvement to the clk rate range APIs that used to be pretty broken if you looked sideways. Beyond the core changes there are a few driver fixes for a compilation issue or improper data causing clks to fail to register or have the wrong parents. These are good to get in before the first -rc so that the system actually boots on the affected devices" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (31 commits) clk: tegra: Fix Tegra PWM parent clock clk: at91: fix the build with binutils 2.27 clk: qcom: gcc-msm8660: Drop hardcoded fixed board clocks clk: mediatek: clk-mux: Add .determine_rate() callback clk: tests: Add tests for notifiers clk: Update req_rate on __clk_recalc_rates() clk: tests: Add missing test case for ranges clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3d clk: Introduce the clk_hw_get_rate_range function clk: Zero the clk_rate_request structure clk: Stop forwarding clk_rate_requests to the parent clk: Constify clk_has_parent() clk: Introduce clk_core_has_parent() clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock clk: Add our request boundaries in clk_core_init_rate_req clk: Introduce clk_hw_init_rate_request() clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its caller clk: Change clk_core_init_rate_req prototype clk: Set req_rate on reparenting clk: Take into account uncached clocks in clk_set_rate_range() ...
2022-10-14Merge branch 'clk-rate-range' into clk-nextStephen Boyd1-65/+221
- Various clk rate range fixes - Drop clk rate range constraints on clk_put() (redux) * clk-rate-range: (28 commits) clk: mediatek: clk-mux: Add .determine_rate() callback clk: tests: Add tests for notifiers clk: Update req_rate on __clk_recalc_rates() clk: tests: Add missing test case for ranges clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3d clk: Introduce the clk_hw_get_rate_range function clk: Zero the clk_rate_request structure clk: Stop forwarding clk_rate_requests to the parent clk: Constify clk_has_parent() clk: Introduce clk_core_has_parent() clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock clk: Add our request boundaries in clk_core_init_rate_req clk: Introduce clk_hw_init_rate_request() clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its caller clk: Change clk_core_init_rate_req prototype clk: Set req_rate on reparenting clk: Take into account uncached clocks in clk_set_rate_range() clk: tests: Add some tests for orphan with multiple parents clk: tests: Add tests for mux with multiple parents clk: tests: Add tests for single parent mux ...
2022-10-11clk: Update req_rate on __clk_recalc_rates()Maxime Ripard1-28/+11
Commit cb1b1dd96241 ("clk: Set req_rate on reparenting") introduced a new function, clk_core_update_orphan_child_rates(), that updates the req_rate field on reparenting. It turns out that that function will interfere with the clock notifying done by __clk_recalc_rates(). This ends up reporting the new rate in both the old_rate and new_rate fields of struct clk_notifier_data. Since clk_core_update_orphan_child_rates() is basically __clk_recalc_rates() without the notifiers, and with the req_rate field update, we can drop clk_core_update_orphan_child_rates() entirely, and make __clk_recalc_rates() update req_rate. However, __clk_recalc_rates() is being called in several code paths: when retrieving a rate (most likely through clk_get_rate()), when changing parents (through clk_set_rate() or clk_hw_reparent()), or when updating the orphan status (through clk_core_reparent_orphans_nolock(), called at registration). Updating req_rate on reparenting or initialisation makes sense, but we shouldn't do it on clk_get_rate(). Thus an extra flag has been added to update or not req_rate depending on the context. Fixes: cb1b1dd96241 ("clk: Set req_rate on reparenting") Link: https://lore.kernel.org/linux-clk/0acc7217-762c-7c0d-45a0-55c384824ce4@samsung.com/ Link: https://lore.kernel.org/linux-clk/Y0QNSx+ZgqKSvPOC@sirena.org.uk/ Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Reported-by: Mark Brown <broonie@kernel.org> Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221010-rpi-clk-fixes-again-v1-1-d87ba82ac404@cerno.tech Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-08Merge tag 'clk-for-linus' of ↵Linus Torvalds1-29/+2
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "We have some late breaking reports that a patch series to rework clk rate range support broke boot on some devices, so I've left that branch out of this. Hopefully we can get to that next week, or punt on it and let it bake another cycle. That means we don't really have any changes to the core framework this time around besides a few typo fixes. Instead this is all clk driver updates and fixes. The usual suspects are here (again), with Qualcomm dominating the diffstat. We look to have gained support for quite a few new Qualcomm SoCs and Dmitry worked on updating many of the existing Qualcomm drivers to use clk_parent_data. After that we have MediaTek drivers getting some much needed updates, in particular to support GPU DVFS. There are also quite a few Samsung clk driver patches, but that's mostly because there was a maintainer change and so last release we missed some of those patches. Overall things look normal, but I'm slowly reviewing core framework code nowadays and that shows given the rate range patches had to be yanked last minute. Let's hope this situation changes soon. New Drivers: - Support for Renesas VersaClock7 clock generator family - Add Spreadtrum UMS512 SoC clk support - New clock drivers for MediaTek Helio X10 MT6795 - Display clks for Qualcomm SM6115, SM8450 - GPU clks for Qualcomm SC8280XP - Qualcomm MSM8909 and SM6375 global and SMD RPM clk drivers Deleted Drivers: - Remove DaVinci DM644x and DM646x clk driver support Updates: - Convert Baikal-T1 CCU driver to platform driver - Split reset support out of primary Baikal-T1 CCU driver - Add some missing clks required for RPiVid Video Decoder on RaspberryPi - Mark PLLC critical on bcm2835 - More devm helpers for fixed rate registration - Various PXA168 clk driver fixes - Add resets for MediaTek MT8195 PCIe and USB - Miscellaneous of_node_put() fixes - Nuke dt-bindings/clk path (again) by moving headers to dt-bindings/clock - Convert gpio-clk-gate binding to YAML - Various fixes to AMD/Xilinx Zynqmp clk driver - Graduate AMD/Xilinx "clocking wizard" driver from staging - Add missing DPI1_HDMI clock in MT8195 VDOSYS1 - Clock driver changes to support GPU DVFS on MT8183, MT8192, MT8195 - Fix GPU clock topology on MT8195 - Propogate rate changes from GPU clock gate up the tree - Clock mux notifiers for GPU-related PLLs - Conversion of more "simple" drivers to mtk_clk_simple_probe() - Hook up mtk_clk_simple_remove() for "simple" MT8192 clock drivers - Fixes to previous |struct clk| to |struct clk_hw| conversion on MediaTek - Shrink MT8192 clock driver by deduplicating clock parent lists - Change order between 'sim_enet_root_clk' and 'enet_qos_root_clk' clocks for i.MX8MP - Drop unnecessary newline in i.MX8MM dt-bindings - Add more MU1 and SAI clocks dt-bindings Ids - Introduce slice busy bit check for i.MX93 composite clock - Introduce white list bit check for i.MX93 composite clock - Add new i.MX93 clock gate - Add MU1 and MU2 clocks to i.MX93 clock provider - Add SAI IPG clocks to i.MX93 clock provider - add generic clocks for U(S)ART available on SAMA5D2 SoCs - reset controller support for Polarfire clocks - .round_rate and .set rate support for clk-mpfs - code cleanup for clk-mpfs - PLL support for PolarFire SoC's Clock Conditioning Circuitry - Add watchdog, I2C, pin control/GPIO, and Ethernet clocks on R-Car V4H - Add SDHI, Timer (CMT/TMU), and SPI (MSIOF) clocks on R-Car S4-8 - Add I2C clocks and resets on RZ/V2M - Document clock support for the RZ/Five SoC - mux-variant clock using the table variant to select parents - clock controller for the rv1126 soc - conversion of rk3128 to yaml and relicensing of the yaml bindings to gpl2+MIT (following dt-binding guildelines) - Exynos7885: add FSYS, TREX and MFC clock controllers - Exynos850: add IS and AUD (audio) clock controllers with bindings - ExynosAutov9: add FSYS clock controllers with bindings - ExynosAutov9: correct clock IDs in bindings of Peric 0 and 1 clock controllers, due to duplicated entries. This is an acceptable ABI break: recently developed/added platform so without legacies, acked by known users/developers - ExynosAutov9: add few missing Peric 0/1 gates - ExynosAutov9: correct register offsets of few Peric 0/1 clocks - Minor code improvements (use of_device_get_match_data() helper, code style) - Add Krzysztof Kozlowski as co-maintainer of Samsung SoC clocks, as he already maintainers that architecture/platform - Keep Qualcomm GDSCs enabled when PWRSTS_RET flag is there, solving retention issues during suspend of USB on Qualcomm sc7180/sc7280 and SC8280XP - Qualcomm SM6115 and QCM2260 are moved to reuse PLL configuration - Qualcomm SDM660 SDCC1 moved to floor clk ops - Support for the APCS PLLs for Qualcomm IPQ8064, IPQ8074 and IPQ6018 was added/fixed - The Qualcomm MSM8996 CPU clocks are updated with support for ACD - Support for Qualcomm SDM670 GCC and RPMh clks was added - Transition to parent_data, parent_hws and use of ARRAY_SIZE() for num_parents was done for many Qualcomm SoCs - Support for per-reset defined delay on Qualcomm was introduced" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (283 commits) clk: qcom: gcc-sm6375: Ensure unsigned long type clk: qcom: gcc-sm6375: Remove unused variables clk: qcom: kpss-xcc: convert to parent data API clk: introduce (devm_)hw_register_mux_parent_data_table API clk: allow building lan966x as a module clk: clk-xgene: simplify if-if to if-else clk: ast2600: BCLK comes from EPLL clk: clocking-wizard: Depend on HAS_IOMEM clk: clocking-wizard: Use dev_err_probe() helper clk: nxp: fix typo in comment clk: pxa: add a check for the return value of kzalloc() clk: vc5: Add support for IDT/Renesas VersaClock 5P49V6975 dt-bindings: clock: vc5: Add 5P49V6975 clk: mvebu: armada-37xx-tbg: Remove the unneeded result variable clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe clk: Renesas versaclock7 ccf device driver dt-bindings: Renesas versaclock7 device tree bindings clk: ti: Balance of_node_get() calls for of_find_node_by_name() clk: imx: scu: fix memleak on platform_device_add() fails clk: vc5: Use regmap_{set,clear}_bits() where appropriate ...
2022-10-01clk: Remove never used devm_of_clk_del_provider()Andy Shevchenko1-26/+0
For the entire history of the devm_of_clk_del_provider) existence (since 2017) it was never used. Remove it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220623115719.52683-1-andriy.shevchenko@linux.intel.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Introduce the clk_hw_get_rate_range functionMaxime Ripard1-0/+16
Some clock providers are hand-crafting their clk_rate_request, and need to figure out the current boundaries of their clk_hw to fill it properly. Let's create such a function for clock providers. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-24-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Zero the clk_rate_request structureMaxime Ripard1-0/+2
In order to make sure we don't carry anything over from an already existing clk_rate_request pointer we would pass to clk_core_init_rate_req(), let's zero the entire structure before initializing it. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-23-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Stop forwarding clk_rate_requests to the parentMaxime Ripard1-7/+77
If the clock cannot modify its rate and has CLK_SET_RATE_PARENT, clk_mux_determine_rate_flags(), clk_core_round_rate_nolock() and a number of drivers will forward the clk_rate_request to the parent clock. clk_core_round_rate_nolock() will pass the pointer directly, which means that we pass a clk_rate_request to the parent that has the rate, min_rate and max_rate of the child, and the best_parent_rate and best_parent_hw fields will be relative to the child as well, so will point to our current clock and its rate. The most common case for CLK_SET_RATE_PARENT is that the child and parent clock rates will be equal, so the rate field isn't a worry, but the other fields are. Similarly, if the parent clock driver ever modifies the best_parent_rate or best_parent_hw, this will be applied to the child once the call to clk_core_round_rate_nolock() is done. best_parent_hw is probably not going to be a valid parent, and best_parent_rate might lead to a parent rate change different to the one that was initially computed. clk_mux_determine_rate_flags() and the affected drivers will copy the request before forwarding it to the parents, so they won't be affected by the latter issue, but the former is still going to be there and will lead to erroneous data and context being passed to the various clock drivers in the same sub-tree. Let's create two new functions, clk_core_forward_rate_req() and clk_hw_forward_rate_request() for the framework and the clock providers that will copy a request from a child clock and update the context to match the parent's. We also update the relevant call sites in the framework and drivers to use that new function. Let's also add a test to make sure we avoid regressions there. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-22-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Constify clk_has_parent()Maxime Ripard1-1/+1
clk_has_parent() doesn't modify the clocks being passed, so let's make it const. Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-21-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Introduce clk_core_has_parent()Maxime Ripard1-15/+22
We will need to know if a clk_core pointer has a given parent in other functions, so let's create a clk_core_has_parent() function that clk_has_parent() will call into. For good measure, let's add some unit tests as well to make sure it works properly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-20-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> [sboyd@kernel.org: Move tmp declaration, fix conditional to check for current parent] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Switch from __clk_determine_rate to clk_core_round_rate_nolockMaxime Ripard1-3/+10
clk_mux_determine_rate_flags() will call into __clk_determine_rate() with a clk_hw pointer, while it has access to the clk_core pointer already. This leads to back and forth between clk_hw and clk_core, while __clk_determine_rate will only call clk_core_round_rate_nolock() with the clk_core pointer it retrieved from the clk_hw. Let's simplify things a bit by calling into clk_core_round_rate_nolock directly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-19-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Add our request boundaries in clk_core_init_rate_reqMaxime Ripard1-6/+1
The expectation is that a new clk_rate_request is initialized through a call to clk_core_init_rate_req(). However, at the moment it only fills the parent rate and clk_hw pointer, but omits the other fields such as the clock rate boundaries. Some users of that function will update them after calling it, but most don't. As we are passed the clk_core pointer, we have access to those boundaries in clk_core_init_rate_req() however, so let's just fill it there and remove it from the few callers that do it right. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-18-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Introduce clk_hw_init_rate_request()Maxime Ripard1-0/+20
clk-divider instantiates clk_rate_request internally for its round_rate implementations to share the code with its determine_rate implementations. However, it's missing a few fields (min_rate, max_rate) that would be initialized properly if it was using clk_core_init_rate_req(). Let's create the clk_hw_init_rate_request() function for clock providers to be able to share the code to instation clk_rate_requests with the framework. This will also be useful for some tests introduced in later patches. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-17-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock() to its ↵Maxime Ripard1-5/+3
caller The clk_rate_request structure is used internally as an argument for the clk_core_determine_round_nolock() and clk_core_round_rate_nolock(). In both cases, the clk_core_init_rate_req() function is used to initialize the clk_rate_request structure. However, the expectation on who gets to call that function is inconsistent between those two functions. Indeed, clk_core_determine_round_nolock() will assume the structure is properly initialized and will just use it. On the other hand, clk_core_round_rate_nolock() will call clk_core_init_rate_req() itself, expecting the caller to have filled only a minimal set of parameters (rate, min_rate and max_rate). If we ignore the calling convention inconsistency, this leads to a second inconsistency for drivers: * If they get called by the framework through clk_core_round_rate_nolock(), the rate, min_rate and max_rate fields will be filled by the caller, and the best_parent_rate and best_parent_hw fields will get filled by clk_core_init_rate_req(). * If they get called by a driver through __clk_determine_rate (and thus clk_core_round_rate_nolock), only best_parent_rate and best_parent_hw are being explicitly set by the framework. Even though we can reasonably expect rate to be set, only one of the 6 in-tree users explicitly set min_rate and max_rate. * If they get called by the framework through clk_core_determine_round_nolock(), then we have two callpaths. Either it will be called by clk_core_round_rate_nolock() itself, or it will be called by clk_calc_new_rates(), which will properly initialize rate, min_rate, max_rate itself, and best_parent_rate and best_parent_hw through clk_core_init_rate_req(). Even though the first and third case seems equivalent, they aren't when the clock has CLK_SET_RATE_PARENT. Indeed, in such a case clk_core_round_rate_nolock() will call itself on the current parent clock with the same clk_rate_request structure. The clk_core_init_rate_req() function will then be called on the parent clock, with the child clk_rate_request pointer and will fill the best_parent_rate and best_parent_hw fields with the parent context. When the whole recursion stops and the call returns, the initial caller will end up with a clk_rate_request structure with some information of the child clock (rate, min_rate, max_rate) and some others of the last clock up the tree whose child had CLK_SET_RATE_PARENT (best_parent_hw, best_parent_rate). In the most common case, best_parent_rate is going to be equal on all the parent clocks so it's not a big deal. However, best_parent_hw is going to point to a clock that never has been a valid parent for that clock which is definitely confusing. In order to fix the calling inconsistency, let's move the clk_core_init_rate_req() calls to the callers, which will also help a bit with the clk_core_round_rate_nolock() recursion. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-16-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Change clk_core_init_rate_req prototypeMaxime Ripard1-4/+6
The expectation is that a clk_rate_request structure is supposed to be initialized using clk_core_init_rate_req(), yet the rate we want to request still needs to be set by hand. Let's just pass the rate as a function argument so that callers don't have any extra work to do. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-15-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Set req_rate on reparentingMaxime Ripard1-0/+22
If a non-rate clock started by default with a parent that never registered, core->req_rate will be 0. The expectation is that whenever the parent will be registered, req_rate will be updated with the new value that has just been computed. However, if that clock is a mux, clk_set_parent() can also make that clock no longer orphan. In this case however, we never update req_rate. The natural solution to this would be to update core->rate and core->req_rate in clk_reparent() by calling clk_recalc(). However, this doesn't work in all cases. Indeed, clk_recalc() is called by __clk_set_parent_before(), __clk_set_parent() and clk_core_reparent(). Both __clk_set_parent_before() and __clk_set_parent will call clk_recalc() with the enable_lock taken through a call to clk_enable_lock(), the underlying locking primitive being a spinlock. clk_recalc() calls the backing driver .recalc_rate hook, and that implementation might sleep if the underlying device uses a bus with accesses that might sleep, such as i2c. In such a situation, we would end up sleeping while holding a spinlock, and thus in an atomic section. In order to work around this, we can move the core->rate and core->req_rate update to the clk_recalc() calling sites, after the enable_lock has been released if it was taken. The only situation that could still be problematic is the clk_core_reparent() -> clk_reparent() case that doesn't have any locking. clk_core_reparent() is itself called by clk_hw_reparent(), which is then called by 4 drivers: * clk-stm32mp1.c, stm32/clk-stm32-core.c and tegra/clk-tegra210-emc.c use it in their set_parent implementation. The set_parent hook is only called by __clk_set_parent() and clk_change_rate(), both of them calling it without the enable_lock taken. * clk/tegra/clk-tegra124-emc.c calls it as part of its set_rate implementation. set_rate is only called by clk_change_rate(), again without the enable_lock taken. In both cases we can't end up in a situation where the clk_hw_reparent() caller would hold a spinlock, so it seems like this is a good workaround. Let's also add some unit tests to make sure we cover the original bug. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-14-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Take into account uncached clocks in clk_set_rate_range()Maxime Ripard1-1/+5
clk_set_rate_range() will use the last requested rate for the clock when it calls into the driver set_rate hook. However, if CLK_GET_RATE_NOCACHE is set on that clock, the last requested rate might not be matching the current rate of the clock. In such a case, let's read out the rate from the hardware and use that in our set_rate instead. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-13-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Clarify clk_get_rate() expectationsMaxime Ripard1-2/+3
As shown by a number of clock users already, clk_get_rate() can be called whether or not the clock is enabled. Similarly, a number of clock drivers will return a rate of 0 whenever the rate cannot be figured out. Since it was a bit ambiguous before, let's make it clear in the clk_get_rate() documentation. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-6-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Skip clamping when rounding if there's no boundariesMaxime Ripard1-1/+13
Commit 948fb0969eae ("clk: Always clamp the rounded rate") recently started to clamp the request rate in the clk_rate_request passed as an argument of clk_core_determine_round_nolock() with the min_rate and max_rate fields of that same request. While the clk_rate_requests created by the framework itself always have those fields set, some drivers will create it themselves and don't always fill min_rate and max_rate. In such a case, we end up clamping the rate with a minimum and maximum of 0, thus always rounding the rate to 0. Let's skip the clamping if both min_rate and max_rate are set to 0 and complain so that it gets fixed. Fixes: 948fb0969eae ("clk: Always clamp the rounded rate") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-4-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-15clk: Drop the rate range on clk_put()Maxime Ripard1-14/+31
When clk_put() is called we don't make another clk_set_rate() call to re-evaluate the rate boundaries. This is unlike clk_set_rate_range() that evaluates the rate again each time it is called. However, clk_put() is essentially equivalent to clk_set_rate_range() since after clk_put() completes the consumer's boundaries shouldn't be enforced anymore. Let's add a call to clk_set_rate_range() in clk_put() to make sure those rate boundaries are dropped and the clock provider drivers can react. In order to be as non-intrusive as possible, we'll just make that call if the clock had non-default boundaries. Also add a few tests to make sure this case is covered. Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate") Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220816112530.1837489-3-maxime@cerno.tech Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-31Revert "clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops"Stephen Boyd1-28/+0
This reverts commit 35b0fac808b95eea1212f8860baf6ad25b88b087. Alexander reports that it causes boot failures on i.MX8M Plus based boards (specifically imx8mp-tqma8mpql-mba8mpxl.dts). Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Chen-Yu Tsai <wenst@chromium.org> Fixes: 35b0fac808b9 ("clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops") Link: https://lore.kernel.org/r/12115951.O9o76ZdvQC@steina-w Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220831175326.2523912-1-sboyd@kernel.org
2022-08-24clk: do not initialize retClaudiu Beznea1-1/+1
There is no need to initialize ret. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20220630151205.3935560-2-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-24clk: remove extra empty lineClaudiu Beznea1-1/+0
Remove extra empty line. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20220630151205.3935560-1-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: Fix comment typoJason Wang1-1/+1
The double `to' is duplicated in the comment, remove one. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20220811140030.28886-1-wangborong@cdjrlc.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: core: Fix runtime PM sequence in clk_core_unprepare()Chen-Yu Tsai1-2/+1
In the original commit 9a34b45397e5 ("clk: Add support for runtime PM"), the commit message mentioned that pm_runtime_put_sync() would be done at the end of clk_core_unprepare(). This mirrors the operations in clk_core_prepare() in the opposite order. However, the actual code that was added wasn't in the order the commit message described. Move clk_pm_runtime_put() to the end of clk_core_unprepare() so that it is in the correct order. Fixes: 9a34b45397e5 ("clk: Add support for runtime PM") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20220822081424.1310926-3-wenst@chromium.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-08-23clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate opsChen-Yu Tsai1-0/+28
In the previous commits that added CLK_OPS_PARENT_ENABLE, support for this flag was only added to rate change operations (rate setting and reparent) and disabling unused subtree. It was not added to the clock gate related operations. Any hardware driver that needs it for these operations will either see bogus results, or worse, hang. This has been seen on MT8192 and MT8195, where the imp_ii2_* clk drivers set this, but dumping debugfs clk_summary would cause it to hang. Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)") Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20220822081424.1310926-2-wenst@chromium.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-06-23clk: Remove never used devm_clk_*unregister()Andy Shevchenko1-48/+0
For the entire history of the devm_clk_*unregister() existence they were used only once (*) in 2015. Remove them. *) The commit 264e3b75de4e ("clk: s2mps11: Simplify s2mps11_clk_probe unwind paths") exactly supports the point of the change proposed here. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220622171147.85603-1-andriy.shevchenko@linux.intel.com Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-04-23clk: using pm_runtime_resume_and_get instead of pm_runtime_get_syncMinghao Chi1-8/+1
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220418110455.2559264-1-chi.minghao@zte.com.cn [sboyd@kernel.org: Drop local ret variable too] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-04-03Revert "clk: Drop the rate range on clk_put()"Stephen Boyd1-28/+14
This reverts commit 7dabfa2bc4803eed83d6f22bd6f045495f40636b. There are multiple reports that this breaks boot on various systems. The common theme is that orphan clks are having rates set on them when that isn't expected. Let's revert it out for now so that -rc1 boots. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Reported-by: Tony Lindgren <tony@atomide.com> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Link: https://lore.kernel.org/r/366a0232-bb4a-c357-6aa8-636e398e05eb@samsung.com Cc: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220403022818.39572-1-sboyd@kernel.org
2022-03-29Merge branches 'clk-range', 'clk-uniphier', 'clk-apple' and 'clk-qcom' into ↵Stephen Boyd1-40/+91
clk-next - Make clk_set_rate_range() re-evaluate the limits each time - Introduce various clk_set_rate_range() tests - Add clk_drop_range() to drop a previously set range - Support for NCO blocks on Apple SoCs * clk-range: clk: Drop the rate range on clk_put() clk: test: Test clk_set_rate_range on orphan mux clk: Initialize orphan req_rate clk: bcm: rpi: Run some clocks at the minimum rate allowed clk: bcm: rpi: Set a default minimum rate clk: bcm: rpi: Add variant structure clk: Add clk_drop_range clk: Always set the rate on clk_set_range_rate clk: Use clamp instead of open-coding our own clk: Always clamp the rounded rate clk: Enforce that disjoints limits are invalid clk: Introduce Kunit Tests for the framework clk: Fix clk_hw_get_clk() when dev is NULL * clk-uniphier: clk: uniphier: Fix fixed-rate initialization * clk-apple: clk: clk-apple-nco: Allow and fix module building MAINTAINERS: Add clk-apple-nco under ARM/APPLE MACHINE clk: clk-apple-nco: Add driver for Apple NCO dt-bindings: clock: Add Apple NCO * clk-qcom: (61 commits) clk: qcom: gcc-msm8994: Fix gpll4 width dt-bindings: clock: fix dt_binding_check error for qcom,gcc-other.yaml clk: qcom: Add display clock controller driver for SM6125 dt-bindings: clock: add QCOM SM6125 display clock bindings clk: qcom: Fix sorting of SDX_GCC_65 in Makefile and Kconfig clk: qcom: gcc: Add emac GDSC support for SM8150 clk: qcom: gcc: sm8150: Fix some identation issues clk: qcom: gcc: Add UFS_CARD and UFS_PHY GDSCs for SM8150 clk: qcom: gcc: Add PCIe0 and PCIe1 GDSC for SM8150 clk: qcom: clk-rcg2: Update the frac table for pixel clock clk: qcom: clk-rcg2: Update logic to calculate D value for RCG clk: qcom: smd: Add missing MSM8998 RPM clocks clk: qcom: smd: Add missing RPM clocks for msm8992/4 dt-bindings: clock: qcom: rpmcc: Add RPM Modem SubSystem (MSS) clocks clk: qcom: gcc-ipq806x: add CryptoEngine resets dt-bindings: reset: add ipq8064 ce5 resets clk: qcom: gcc-ipq806x: add CryptoEngine clocks dt-bindings: clock: add ipq8064 ce5 clk define clk: qcom: gcc-ipq806x: add additional freq for sdc table clk: qcom: clk-rcg: add clk_rcg_floor_ops ops ...
2022-03-26clk: Drop the rate range on clk_put()Maxime Ripard1-14/+28
When clk_put() is called we don't make another clk_set_rate() call to re-evaluate the rate boundaries. This is unlike clk_set_rate_range() that evaluates the rate again each time it is called. However, clk_put() is essentially equivalent to clk_set_rate_range() since after clk_put() completes the consumer's boundaries shouldn't be enforced anymore. Let's add a call to clk_set_rate_range() in clk_put() to make sure those rate boundaries are dropped and the clock provider drivers can react. Also add a few tests to make sure this case is covered. Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220325161144.1901695-4-maxime@cerno.tech [sboyd@kernel.org: Reword commit text] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-25clk: Initialize orphan req_rateMaxime Ripard1-0/+13
When registering a clock that doesn't have a recalc_rate implementation, and doesn't have its parent registered yet, we initialize the clk_core rate and 'req_rate' fields to 0. The rate field is later updated when the parent is registered in clk_core_reparent_orphans_nolock() using __clk_recalc_rates(), but the 'req_rate' field is never updated. This leads to an issue in clk_set_rate_range() and clk_put(), since those functions will call clk_set_rate() with the content of 'req_rate' to provide drivers with the opportunity to change the rate based on the new boundaries. In this case, we would call clk_set_rate() with a rate of 0, effectively enforcing the minimum allowed for this clock whenever we would call one of those two functions, even though the actual rate might be within range. Let's fix this by setting 'req_rate' in clk_core_reparent_orphans_nolock() with the rate field content just updated by the call to __clk_recalc_rates(). Fixes: 1c8e600440c7 ("clk: Add rate constraints to clocks") Reported-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # T30 Nexus7 Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220325161144.1901695-2-maxime@cerno.tech [sboyd@kernel.org: Reword comment] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-12clk: Always set the rate on clk_set_range_rateMaxime Ripard1-22/+23
When we change a clock minimum or maximum using clk_set_rate_range(), clk_set_min_rate() or clk_set_max_rate(), the current code will only trigger a new rate change if the rate is outside of the new boundaries. However, a clock driver might want to always keep the clock rate to one of its boundary, for example the minimum to keep the power consumption as low as possible. Since they don't always get called though, clock providers don't have the opportunity to implement this behaviour. Let's trigger a clk_set_rate() on the previous requested rate every time clk_set_rate_range() is called. That way, providers that care about the new boundaries have a chance to adjust the rate, while providers that don't care about those new boundaries will return the same rate than before, which will be ignored by clk_set_rate() and won't result in a new rate change. Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-7-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-12clk: Use clamp instead of open-coding our ownMaxime Ripard1-5/+1
The code in clk_set_rate_range() will, if the current rate is outside of the new range, force it to the minimum or maximum. Since it's running under the condition that the rate is either lower than the minimum, or higher than the maximum, this is equivalent to using clamp, while being less readable. Let's switch to using clamp instead. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-6-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-12clk: Always clamp the rounded rateMaxime Ripard1-0/+2
The current core while setting the min and max rate properly in the clk_request structure will not make sure that the requested rate is within these boundaries, leaving it to each and every driver to make sure it is. It's not clear if this was on purpose or not, but this introduces some inconsistencies within the API. For example, a user setting a range and then calling clk_round_rate() with a value outside of that range will get the same value back (ignoring any driver adjustements), effectively ignoring the range that was just set. Another one, arguably worse, is that it also makes clk_round_rate() and clk_set_rate() behave differently if there's a range and the rate being used for both is outside that range. As we have seen, the rate will be returned unchanged by clk_round_rate(), but clk_set_rate() will error out returning -EINVAL. Let's make sure the framework will always clamp the rate to the current range found on the clock, which will fix both these inconsistencies. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-5-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-12clk: Enforce that disjoints limits are invalidMaxime Ripard1-0/+24
If we were to have two users of the same clock, doing something like: clk_set_rate_range(user1, 1000, 2000); clk_set_rate_range(user2, 3000, 4000); The second call would fail with -EINVAL, preventing from getting in a situation where we end up with impossible limits. However, this is never explicitly checked against and enforced, and works by relying on an undocumented behaviour of clk_set_rate(). Indeed, on the first clk_set_rate_range will make sure the current clock rate is within the new range, so it will be between 1000 and 2000Hz. On the second clk_set_rate_range(), it will consider (rightfully), that our current clock is outside of the 3000-4000Hz range, and will call clk_core_set_rate_nolock() to set it to 3000Hz. clk_core_set_rate_nolock() will then call clk_calc_new_rates() that will eventually check that our rate 3000Hz rate is outside the min 3000Hz max 2000Hz range, will bail out, the error will propagate and we'll eventually return -EINVAL. This solely relies on the fact that clk_calc_new_rates(), and in particular clk_core_determine_round_nolock(), won't modify the new rate allowing the error to be reported. That assumption won't be true for all drivers, and most importantly we'll break that assumption in a later patch. It can also be argued that we shouldn't even reach the point where we're calling clk_core_set_rate_nolock(). Let's make an explicit check for disjoints range before we're doing anything. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-4-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-12clk: Fix clk_hw_get_clk() when dev is NULLMaxime Ripard1-1/+2
Any registered clk_core structure can have a NULL pointer in its dev field. While never actually documented, this is evidenced by the wide usage of clk_register and clk_hw_register with a NULL device pointer, and the fact that the core of_clk_hw_register() function also passes a NULL device pointer. A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that case will result in a NULL pointer derefence when it calls dev_name() on that NULL device pointer. Add a test for this case and use NULL as the dev_id if the device pointer is NULL. Fixes: 30d6f8c15d2c ("clk: add api to get clk consumer from clk_hw") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220225143534.405820-2-maxime@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-02-26clk: Mark clk_core_evict_parent_cache_subtree() 'target' constStephen Boyd1-1/+1
Clarify that the 'target' clk isn't being modified, instead it's being searched for. Mark it const so the function can't modify it. Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220217220554.2711696-3-sboyd@kernel.org
2022-02-26clk: Mark 'all_lists' as constStephen Boyd1-2/+2
This list array doesn't change at runtime. Mark it const to move to RO memory. Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20220217220554.2711696-2-sboyd@kernel.org
2022-01-13Merge tag 'clk-for-linus' of ↵Linus Torvalds1-11/+69
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "We have a couple patches in the framework core this time around but they're mostly minor cleanups and some debugfs stuff. The real work that's in here is the typical pile of clk driver updates and new SoC support. Per usual (or maybe just recent trends), Qualcomm gains a handful of SoC drivers additions and has the largest diffstat. After that there are quite a few updates to the Allwinner (sunxi) drivers to support modular drivers and Renesas is heavily updated to add more support for various clks. Overall it looks pretty normal. New Drivers: - Add MDMA and BDMA clks to Ingenic JZ4760 and JZ4770 - MediaTek mt7986 SoC basic support - Clock and reset driver for Toshiba Visconti SoCs - Initial clock driver for the Exynos7885 SoC (Samsung Galaxy A8) - Allwinner D1 clks - Lan966x Generic Clock Controller driver and associated DT bindings - Qualcomm SDX65, SM8450, and MSM8976 GCC clks - Qualcomm SDX65 and SM8450 RPMh clks Updates: - Set suppress_bind_attrs to true for i.MX8ULP driver - Switch from do_div to div64_ul for throughout all i.MX drivers - Fix imx8mn_clko1_sels for i.MX8MN - Remove unused IPG_AUDIO_ROOT from i.MX8MP - Switch parent for audio_root_clk to audio ahb in i.MX8MP driver - Removal of all remaining uses of __clk_lookup() in drivers/clk/samsung - Refactoring of the CPU clocks registration to use common interface - An update of the Exynos850 driver (support for more clock domains) required by the E850-96 development board - Prep for runtime PM and generic power domains on Tegra - Support modular Allwinner clk drivers via platform bus - Lan966x clock driver extended to support clock gating - Add serial (SCI1), watchdog (WDT), timer (OSTM), SPI (RSPI), and thermal (TSU) clocks and resets on Renesas RZ/G2L - Rework SDHI clock handling in the Renesas R-Car Gen3 and RZ/G2 clock drivers, and in the Renesas SDHI driver - Make the Cortex-A55 (I) clock on Renesas RZ/G2L programmable - Document support for the new Renesas R-Car S4-8 (R8A779F0) SoC - Add support for the new Renesas R-Car S4-8 (R8A779F0) SoC - Add GPU clock and resets on Renesas RZ/G2L - Add clk-provider.h to various Qualcomm clk drivers - devm version of clk_hw_register_gate() - kerneldoc fixes in a couple drivers" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (131 commits) clk: visconti: Remove pointless NULL check in visconti_pll_add_lookup() clk: mediatek: add mt7986 clock support clk: mediatek: add mt7986 clock IDs dt-bindings: clock: mediatek: document clk bindings for mediatek mt7986 SoC clk: mediatek: clk-gate: Use regmap_{set/clear}_bits helpers clk: mediatek: clk-gate: Shrink by adding clockgating bit check helper clk: x86: Fix clk_gate_flags for RV_CLK_GATE clk: x86: Use dynamic con_id string during clk registration ACPI: APD: Add a fmw property clk-name drivers: acpi: acpi_apd: Remove unused device property "is-rv" x86: clk: clk-fch: Add support for newer family of AMD's SOC clk: ingenic: Add MDMA and BDMA clocks dt-bindings: clk/ingenic: Add MDMA and BDMA clocks clk: bm1880: remove kfrees on static allocations clk: Drop unused COMMON_CLK_STM32MP157_SCMI config clk: st: clkgen-mux: search reg within node or parent clk: st: clkgen-fsyn: search reg within node or parent clk: Enable/Disable runtime PM for clk_summary MAINTAINERS: Add entries for Toshiba Visconti PLL and clock controller clk: visconti: Add support common clock driver and reset driver ...
2022-01-12Merge branches 'clk-doc', 'clk-renesas', 'clk-at91', 'clk-cleanup' and ↵Stephen Boyd1-11/+69
'clk-debugfs' into clk-next * clk-doc: clk: Gemini: fix struct name in kernel-doc clk: zynq: pll: Fix kernel-doc warnings clk: imx: pllv1: fix kernel-doc notation for struct clk_pllv1 * clk-renesas: (31 commits) clk: renesas: r9a07g044: Add GPU clock and reset entries clk: renesas: r9a07g044: Add mux and divider for G clock clk: renesas: r9a07g044: Rename CLK_PLL3_DIV4 macro clk: renesas: cpg-mssr: Add support for R-Car S4-8 clk: renesas: rcar-gen4: Introduce R-Car Gen4 CPG driver dt-bindings: clock: Add r8a779f0 CPG Core Clock Definitions dt-bindings: power: Add r8a779f0 SYSC power domain definitions clk: renesas: r9a07g044: Add TSU clock and reset entry mmc: renesas_sdhi: Simplify an expression mmc: renesas_sdhi: Use devm_clk_get_optional() to obtain CD clock dt-bindings: clock: renesas,cpg-mssr: Document r8a779f0 clk: renesas: cpg-mssr: propagate return value of_genpd_add_provider_simple() clk: renesas: cpg-mssr: Check return value of pm_genpd_init() clk: renesas: rzg2l: propagate return value of_genpd_add_provider_simple() clk: renesas: rzg2l: Check return value of pm_genpd_init() clk: renesas: r9a07g044: Add RSPI clock and reset entries clk: renesas: r9a07g044: Change core clock "I" from DEF_FIXED->DEF_DIV clk: renesas: rzg2l: Add CPG_PL1_DDIV macro mmc: renesas_sdhi: Parse DT for SDnH mmc: renesas_sdhi: Use dev_err_probe when getting clock fails ... * clk-at91: clk: lan966x: Extend lan966x clock driver for clock gating support dt-bindings: clock: lan966x: Extend includes with clock gates dt-bindings: clock: lan966x: Extend for clock gate support clk: gate: Add devm_clk_hw_register_gate() clk: lan966x: Add lan966x SoC clock driver dt-bindings: clock: lan966x: Add LAN966X Clock Controller dt-bindings: clock: lan966x: Add binding includes for lan966x SoC clock IDs * clk-cleanup: clk: stm32mp1: remove redundant assignment to pointer data clk: __clk_core_init() never takes NULL clk: clk_core_get() can also return NULL clk/ti/adpll: Make const pointer error a static const array * clk-debugfs: clk: Enable/Disable runtime PM for clk_summary clk: Emit a stern warning with writable debugfs enabled clk: Add write operation for clk_parent debugfs node
2022-01-06clk: Enable/Disable runtime PM for clk_summaryTaniya Das1-0/+2
The registers for some clocks in the SOC area, which are under the power domain are required to be enabled before accessing them. During the clk_summary if the power-domains are not enabled they could result into NoC errors. Thus ensure the register access of the clock controller is done with pm_untime_get/put functions. Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/1640018638-19436-3-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-12-11clk: Emit a stern warning with writable debugfs enabledStephen Boyd1-0/+18
We don't want vendors to be enabling this part of the clk code and shipping it to customers. Exposing the ability to change clk frequencies and parents via debugfs is potentially damaging to the system if folks don't know what they're doing. Emit a strong warning so that the message is clear: don't enable this outside of development systems. Fixes: 37215da5553e ("clk: Add support for setting clk_rate via debugfs") Cc: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20211210014237.2130300-1-sboyd@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-12-10clk: Add write operation for clk_parent debugfs nodeSam Protsenko1-1/+41
Useful for testing mux clocks. One can write the index of the parent to be set into clk_parent node, starting from 0. Example # cd /sys/kernel/debug/clk/mout_peri_bus # cat clk_possible_parents dout_shared0_div4 dout_shared1_div4 # cat clk_parent dout_shared0_div4 # echo 1 > clk_parent # cat clk_parent dout_shared1_div4 CLOCK_ALLOW_WRITE_DEBUGFS has to be defined in drivers/clk/clk.c in order to use this feature. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Michael Turquette <mturquette@baylibre.com> Link: https://lore.kernel.org/r/20211013172042.10884-1-semen.protsenko@linaro.org [sboyd@kernel.org: Collapse ifdefs] Signed-off-by: Stephen Boyd <sboyd@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-21 15:23:30 +0300