aboutsummaryrefslogtreecommitdiff
path: root/drivers/clk
AgeCommit message (Collapse)AuthorFilesLines
2022-09-19clk: imx: add i.MX93 clk gatePeng Fan3-0/+204
i.MX93 LPCG is different from i.MX8M CCGR. Although imx_clk_hw_gate4_flags is used here, it not strictly match i.MX93. i.MX93 has such design: - LPCG_DIRECT use BIT0 as on/off gate when LPCG_AUTHEN CPU_LPM is 0 - LPCG_LPM_CUR use BIT[2:0] as on/off gate when LPCG_AUTHEN CPU_LPM is 1 The current implementation suppose CPU_LPM is 0, and use LPCG_DIRECT BIT[1:0] as on/off gate. Although BIT1 is touched, actually BIT1 is reserved. And imx_clk_hw_gate4_flags use mask 0x3 to determine whether the clk is enabled or not, but i.MX93 LPCG only use BIT0 to control when CPU_LPM is 0. So clk disabled unused during kernel boot not able to gate off the unused clocks. To match i.MX93 LPCG, introduce imx93_clk_gate. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Ye Li <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-19clk: imx: clk-composite-93: check white_listPeng Fan3-5/+10
The CCM ROOT AUTHEN register WHITE_LIST indicate: Each bit in this field represent for one domain. Bit16~Bit31 represent for DOMAIN0~DOMAIN15 respectively. Only corresponding bit of the domains is set to 1 can change the registers of this Clock Root. i.MX93 DID is 3, so if BIT(3 + WHITE_LIST_SHIFT) is 0, the clk should be set to read only. To make the imx93_clk_composite_flags be reusable, add a new parameter named did(domain id); Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Ye Li <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-19clk: imx: clk-composite-93: check slice busyPeng Fan1-3/+160
i.MX93 CCM ROOT STAT register has a SLICE_BUSY bit: indication for clock generation logic is applying new setting. 0b - Clock generation logic is not busy. 1b - Clock generation logic is applying new setting. So when set parent/rate/gate, need check this bit. Introduce specific ops to do the work. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Ye Li <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-18clk: renesas: r8a779g0: Add EtherAVB clocksGeert Uytterhoeven1-0/+3
Add the module clocks used by the Ethernet AVB (EtherAVB-IF) blocks on the Renesas R-Car V4H (R8A779G0) SoC. Based on a larger patch in the BSP by Kazuya Mizuguchi. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/e9382b0d9acc84acc2357a6921a1459f3a32240e.1662714852.git.geert+renesas@glider.be
2022-09-18clk: renesas: r8a779g0: Add PFC/GPIO clocksGeert Uytterhoeven1-0/+4
Add the module clocks used by the Pin Function Controller (PFC) and General Purpose Input/Output (GPIO) blocks on the Renesas R-Car V4H (R8A779G0) SoC. Extracted from a larger patch in the BSP by Kazuya Mizuguchi. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/cc6a22f0ad49643e17b9921b27aa9cf0a3b8d57a.1662714852.git.geert+renesas@glider.be
2022-09-18clk: renesas: r8a779g0: Add I2C clocksGeert Uytterhoeven1-0/+6
Add the module clocks used by the I2C Bus Interfaces on the Renesas R-Car V4H (R8A779G0) SoC. Extracted from a larger patch in the BSP by Kazuya Mizuguchi. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/f4b94f37950f6e976b68d0b32c324fb026d8b696.1662714852.git.geert+renesas@glider.be
2022-09-18clk: renesas: r8a779g0: Add watchdog clockGeert Uytterhoeven1-0/+1
Add the module clock used by the RCLK Watchdog Timer on the Renesas R-Car V4H (R8A779G0) SoC. Extracted from a larger patch in the BSP by Kazuya Mizuguchi. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/a012e4449b976efbeaabebb983fa6cfc1b9329d3.1662714852.git.geert+renesas@glider.be
2022-09-16Merge tag 'v6.0-rc5' into i2c/for-mergewindowWolfram Sang3-7/+13
Linux 6.0-rc5
2022-09-15clk: tests: Add missing test case for rangesMaxime Ripard1-0/+53
Let's add a test on the rate range after a reparenting. This fails for now, but it's worth having it to document the corner cases we don't support yet. Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Naresh Kamboju <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: qcom: clk-rcg2: Take clock boundaries into consideration for gfx3dMaxime Ripard1-0/+9
The gfx3d clock is hand-crafting its own clk_rate_request in clk_gfx3d_determine_rate to pass to the parent of that clock. However, since the clk_rate_request is zero'd at creation, it will have a max_rate of 0 which will break any code depending on the clock boundaries. That includes the recent commit 948fb0969eae ("clk: Always clamp the rounded rate") which will clamp the rate given to clk_round_rate() to the current clock boundaries. For the gfx3d clock, it means that since both the min_rate and max_rate fields are set at zero, clk_round_rate() now always return 0. Let's initialize the min_rate and max_rate fields properly for that clock. Fixes: 948fb0969eae ("clk: Always clamp the rounded rate") Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: Stop forwarding clk_rate_requests to the parentMaxime Ripard6-16/+274
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: Introduce clk_core_has_parent()Maxime Ripard2-15/+65
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> [[email protected]: Move tmp declaration, fix conditional to check for current parent] Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: Introduce clk_hw_init_rate_request()Maxime Ripard2-10/+30
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: Set req_rate on reparentingMaxime Ripard2-0/+261
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: Take into account uncached clocks in clk_set_rate_range()Maxime Ripard2-1/+36
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: tests: Add some tests for orphan with multiple parentsMaxime Ripard1-0/+237
Let's leverage the dummy mux with multiple parents we have to create a mux whose default parent will never be registered, and thus will always be orphan by default. We can then create some tests to make sure that the clock API behaves properly in such a case, and that the transition to a non-orphan clock when we change the parent is done properly. Tested-by: Alexander Stein <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: tests: Add tests for mux with multiple parentsMaxime Ripard1-0/+121
We'll need to test a few corner cases that occur when we have a mux clock whose default parent is missing. For now, let's create the context structure and the trivial ops, along with a test suite that just tests trivial things for now, without considering the orphan case. Tested-by: Alexander Stein <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: tests: Add tests for single parent muxMaxime Ripard1-9/+185
We have a few tests for a mux with a single parent, testing the case where it used to be orphan. Let's leverage most of the code but register the clock properly to test a few trivial things. Tested-by: Alexander Stein <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: tests: Add tests for uncached clockMaxime Ripard1-1/+92
The clock framework supports clocks that can have their rate changed without the kernel knowing about it using the CLK_GET_RATE_NOCACHE flag. As its name suggests, this flag turns off the rate caching in the clock framework, reading out the rate from the hardware any time we need to read it. Let's add a couple of tests to make sure it works as intended. Tested-by: Alexander Stein <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: tests: Add reference to the orphan mux bug reportMaxime Ripard1-0/+3
Some more context might be useful for unit-tests covering a previously reported bug, so let's add a link to the discussion for that bug. Tested-by: Alexander Stein <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: tests: Add test suites descriptionMaxime Ripard1-0/+33
We start to have a few test suites, and we'll add more, so it will get pretty confusing to figure out what is supposed to be tested in what suite. Let's add some comments to explain what setup they create, and what we should be testing in every suite. Tested-by: Alexander Stein <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: Drop the rate range on clk_put()Maxime Ripard2-14/+141
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 <[email protected]> # imx8mp Tested-by: Marek Szyprowski <[email protected]> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: test: Switch to clk_hw_get_clkMaxime Ripard1-19/+55
Following the clk_hw->clk pointer is equivalent to calling clk_hw_get_clk(), but will make the job harder if we need to rework that part in the future. Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Naresh Kamboju <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-15clk: at91: sama5d2: Add Generic Clocks for UART/USARTSergiu Moga1-0/+10
Add the generic clocks for UART/USART in the sama5d2 driver to allow them to be registered in the Common Clock Framework. Signed-off-by: Sergiu Moga <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: add PolarFire SoC fabric clock supportConor Dooley2-0/+291
Add a driver to support the PLLs in PolarFire SoC's Clock Conditioning Circuitry, an instance of which is located in each ordinal corner of the FPGA. Only get_rate() is supported as these clocks are intended to be statically configured by the FPGA design. Currently, the DLLs are not supported by this driver. For more information on the hardware, see "PolarFire SoC FPGA Clocking Resources" in the link below. Link: https://onlinedocs.microchip.com/pr/GUID-8F0CC4C0-0317-4262-89CA-CE7773ED1931-en-US-1/index.html Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: update module authorship & licencingConor Dooley1-3/+7
Padmarao wrote the driver in its original, pre upstream form. Daire & myself have been responsible for getting it upstreamable and subsequent development. Move Daire out of the blurb & into a MODULE_AUTHOR entry & add entries for myself and Padmarao. While we are at it, convert the MODULE_LICENSE field to its preferred form of "GPL". Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: convert periph_clk to clk_gateConor Dooley1-66/+6
With the reset code moved to the recently added reset controller, there is no need for custom ops any longer. Remove the custom ops and the custom struct by converting to a clk_gate. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: convert cfg_clk to clk_dividerConor Dooley1-68/+8
The cfg_clk struct is now just a redefinition of the clk_divider struct with custom implentations of the ops, that implement an extra level of redirection. Remove the custom struct and replace it with clk_divider. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: delete 2 line mpfs_clk_register_foo()Conor Dooley1-27/+6
The register functions are now comprised of only a single operation each and no longer add anything to the driver. Delete them. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: simplify control reg accessConor Dooley1-25/+17
The control reg addresses are known when the clocks are registered, so we can, instead of assigning a base pointer to the structs, assign the control reg addresses directly. Accordingly, remove the interim variables used during reads/writes to those registers. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: move id & offset out of clock structsConor Dooley1-15/+15
The id and offset are the only thing differentiating the clock structs from "regular" clock structures. On the pretext of converting to more normal structures, move the id and offset out of the clock structs and into the hw structs instead. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: add MSS pll's set & round rateConor Dooley1-0/+54
The MSS pll is not a fixed frequency clock, so add set() & round_rate() support. Control is limited to a 7 bit output divider as other devices on the FPGA occupy the other three outputs of the PLL & prevent changing the multiplier. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: add reset controllerConor Dooley2-12/+99
Add a reset controller to PolarFire SoC's clock driver. This reset controller is registered as an aux device and read/write functions exported to the drivers namespace so that the reset controller can access the peripheral device reset register. Reviewed-by: Daire McNamara <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: make the rtc's ahb clock criticalConor Dooley1-1/+3
The onboard RTC's AHB bus clock must be kept running as the RTC will stop & lose track of time if the AHB interface clock is disabled. Fixes: 635e5e73370e ("clk: microchip: Add driver for Microchip PolarFire SoC") Signed-off-by: Conor Dooley <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-14clk: microchip: mpfs: fix clk_cfg array bounds violationConor Dooley1-1/+6
There is an array bounds violation present during clock registration, triggered by current code by only specific toolchains. This seems to fail gracefully in v6.0-rc1, using a toolchain build from the riscv- gnu-toolchain repo and with clang-15, and life carries on. While converting the driver to use standard clock structs/ops, kernel panics were seen during boot when built with clang-15: [ 0.581754] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b1 [ 0.591520] Oops [#1] [ 0.594045] Modules linked in: [ 0.597435] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc1-00011-g8e1459cf4eca #1 [ 0.606188] Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) [ 0.613012] epc : __clk_register+0x4a6/0x85c [ 0.617759] ra : __clk_register+0x49e/0x85c [ 0.622489] epc : ffffffff803faf7c ra : ffffffff803faf74 sp : ffffffc80400b720 [ 0.630466] gp : ffffffff810e93f8 tp : ffffffe77fe60000 t0 : ffffffe77ffb3800 [ 0.638443] t1 : 000000000000000a t2 : ffffffffffffffff s0 : ffffffc80400b7c0 [ 0.646420] s1 : 0000000000000001 a0 : 0000000000000001 a1 : 0000000000000000 [ 0.654396] a2 : 0000000000000001 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.662373] a5 : ffffffff803a5810 a6 : 0000000200000022 a7 : 0000000000000006 [ 0.670350] s2 : ffffffff81099d48 s3 : ffffffff80d6e28e s4 : 0000000000000028 [ 0.678327] s5 : ffffffff810ed3c8 s6 : ffffffff810ed3d0 s7 : ffffffe77ffbc100 [ 0.686304] s8 : ffffffe77ffb1540 s9 : ffffffe77ffb1540 s10: 0000000000000008 [ 0.694281] s11: 0000000000000000 t3 : 00000000000000c6 t4 : 0000000000000007 [ 0.702258] t5 : ffffffff810c78c0 t6 : ffffffe77ff88cd0 [ 0.708125] status: 0000000200000120 badaddr: 00000000000000b1 cause: 000000000000000d [ 0.716869] [<ffffffff803fb892>] devm_clk_hw_register+0x62/0xaa [ 0.723420] [<ffffffff80403412>] mpfs_clk_probe+0x1e0/0x244 In v6.0-rc1 and later, this issue is visible without the follow on patches doing the conversion using toolchains provided by our Yocto meta layer too. It fails on "clk_periph_timer" - which uses a different parent, that it tries to find using the macro: \#define PARENT_CLK(PARENT) (&mpfs_cfg_clks[CLK_##PARENT].cfg.hw) If parent is RTCREF, so the macro becomes: &mpfs_cfg_clks[33].cfg.hw which is well beyond the end of the array. Amazingly, builds with GCC 11.1 see no problem here, booting correctly and hooking the parent up etc. Builds with clang-15 do not, with the above panic. Change the macro to use specific offsets depending on the parent rather than the dt-binding's clock IDs. Fixes: 1c6a7ea32b8c ("clk: microchip: mpfs: add RTCREF clock control") CC: Nathan Chancellor <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-13clk: qcom: smd-rpm: Add clocks for MSM8909Stephan Gerhold1-1/+36
MSM8909 has mostly the same as clocks in RPM as MSM8916, but additionally the QPIC clock for the NAND flash controller. Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-13clk: qcom: gcc-msm8909: Increase delay for USB PHY resetStephan Gerhold1-1/+1
The USB PHY on MSM8909 works with the driver used on MSM8916 (phy-qcom-usb-hs.c). When turning the PHY on/off it is first reset using the standard reset controller API. On MSM8916 the reset is provided by the USB driver (ci_hdrc_msm_por_reset() in ci_hdrc_msm.c). While this seems to work on MSM8909 as well, the Qualcomm Linux sources suggest that the PHY should be reset using the GCC_USB2_HS_PHY_ONLY_BCR register instead. In general this is easy to set up in the device tree, thanks to the standard reset controller API. However, to conform to the specifications of the PHY the reset signal should be asserted for at least 10 us. This is handled correctly on MSM8916 in ci_hdrc_msm_por_reset(), but not within the GCC driver. Fix this by making use of the new "udelay" field of qcom_reset_map and set a delay of ~15 us between the assertion/deassertion of the USB PHY reset signal. Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-13clk: qcom: reset: Allow specifying custom reset delayStephan Gerhold2-1/+4
The amount of time required between asserting and deasserting the reset signal can vary depending on the involved hardware component. Sometimes 1 us might not be enough and a larger delay is necessary to conform to the specifications. Usually this is worked around in the consuming drivers, by replacing reset_control_reset() with a sequence of reset_control_assert(), waiting for a custom delay, followed by reset_control_deassert(). However, in some cases the driver making use of the reset is generic and can be used with different reset controllers. In this case the reset time requirement is better handled directly by the reset controller driver. Make this possible by adding an "udelay" field to the qcom_reset_map that allows setting a different reset delay (in microseconds). Signed-off-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-13clk: qcom: Add driver for MSM8909 GCCStephan Gerhold3-0/+2740
The Global Clock Controller (GCC) in the MSM8909 SoC provides clocks, resets and power domains for the various hardware blocks in the SoC. Add a driver for it to make it possible to enable additional functionality for the SoC. Work on this driver was originally started independently by Dominik, I picked it up and added missing clocks/resets, as well as various cleanup to bring it into shape for mainline. Co-developed-by: Dominik Kobinski <[email protected]> Signed-off-by: Dominik Kobinski <[email protected]> Signed-off-by: Stephan Gerhold <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-13clk: qcom: mmcc-msm8960: use parent_hws/_data instead of parent_namesDmitry Baryshkov1-119/+203
Convert the clock driver to specify parent data rather than parent names, to actually bind using 'clock-names' specified in the DTS rather than global clock names. Use parent_hws where possible to refer parent clocks directly, skipping the lookup. Signed-off-by: Dmitry Baryshkov <[email protected]> Tested-by: David Heidelberg <[email protected]> # tested on Nexus 7 (2013) Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-13clk: qcom: mmcc-msm8960: move clock parent tables downDmitry Baryshkov1-46/+46
Move clock parent tables down, after the PLL declrataions, so that we can use pll hw clock fields in the next commit. Signed-off-by: Dmitry Baryshkov <[email protected]> Tested-by: David Heidelberg <[email protected]> # tested on Nexus 7 (2013) Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.