kernel/linux.git/drivers/clk/imx, branch v5.10.257

clk: imx8mp: inform CCF of maximum frequency of clocks

2025-06-04T12:37:02+00:00

[ Upstream commit 06a61b5cb6a8638fa8823cd09b17233b29696fa2 ] The IMX8MPCEC datasheet lists maximum frequencies allowed for different modules. Some of these limits are universal, but some depend on whether the SoC is operating in nominal or in overdrive mode. The imx8mp.dtsi currently assumes overdrive mode and configures some clocks in accordance with this. Boards wishing to make use of nominal mode will need to override some of the clock rates manually. As operating the clocks outside of their allowed range can lead to difficult to debug issues, it makes sense to register the maximum rates allowed in the driver, so the CCF can take them into account. Reviewed-by: Peng Fan Signed-off-by: Ahmad Fatoum Link: https://lore.kernel.org/r/20250218-imx8m-clk-v4-6-b7697dc2dcd0@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

clk: imx8mp: Fix clkout1/2 support

2025-03-13T11:46:48+00:00

[ Upstream commit a9b7c84d22fb1687d63ca2a386773015cf59436b ] The CLKOUTn may be fed from PLL1/2/3, but the PLL1/2/3 has to be enabled first by setting PLL_CLKE bit 11 in CCM_ANALOG_SYS_PLLn_GEN_CTRL register. The CCM_ANALOG_SYS_PLLn_GEN_CTRL bit 11 is modeled by plln_out clock. Fix the clock tree and place the clkout1/2 under plln_sel instead of plain plln to let the clock subsystem correctly control the bit 11 and enable the PLL in case the CLKOUTn is supplied by PLL1/2/3. Fixes: 43896f56b59e ("clk: imx8mp: add clkout1/2 support") Signed-off-by: Marek Vasut Reviewed-by: Peng Fan Link: https://lore.kernel.org/r/20241112013718.333771-1-marex@denx.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D

2024-10-17T13:08:31+00:00

[ Upstream commit a54c441b46a0745683c2eef5a359d22856d27323 ] For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang. Signed-off-by: Peng Fan Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20240607133347.3291040-8-peng.fan@oss.nxp.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

clk: imx: imx8mp: fix clock tree update of TF-A managed clocks

2024-10-17T13:07:52+00:00

[ Upstream commit 3d29036853b9cb07ac49e8261fca82a940be5c41 ] On the i.MX8M*, the TF-A exposes a SiP (Silicon Provider) service for DDR frequency scaling. The imx8m-ddrc-devfreq driver calls the SiP and then does clk_set_parent on the DDR muxes to synchronize the clock tree. since commit 936c383673b9 ("clk: imx: fix composite peripheral flags"), these TF-A managed muxes have SET_PARENT_GATE set, which results in imx8m-ddrc-devfreq's clk_set_parent after SiP failing with -EBUSY: clk_set_parent(dram_apb_src, sys1_pll_40m);(busfreq-imx8mq.c) commit 926bf91248dd ("clk: imx8m: fix clock tree update of TF-A managed clocks") adds this method and enables 8mm, 8mn and 8mq. i.MX8MP also needs it. This is safe to do, because updating the Linux clock tree to reflect reality will always be glitch-free. Another reason to this patch is that powersave image BT music requires dram to be 400MTS, so clk_set_parent(dram_alt_src, sys1_pll_800m); is required. Without this patch, it will not succeed. Fixes: 936c383673b9 ("clk: imx: fix composite peripheral flags") Signed-off-by: Zhipeng Wang Reviewed-by: Ahmad Fatoum Signed-off-by: Peng Fan Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20240607133347.3291040-7-peng.fan@oss.nxp.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

clk: imx: imx8mq: correct error handling path

2023-11-20T10:06:47+00:00

[ Upstream commit 577ad169966e6e75b10e004389a3f79813e84b5d ] Avoid memory leak in error handling path. It does not make much sense for the SoC without clk driver, to make program behavior correct, let's fix it. Fixes: b80522040cd3 ("clk: imx: Add clock driver for i.MX8MQ CCM") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202309240551.e46NllPa-lkp@intel.com/ Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/20231001122618.194498-1-peng.fan@oss.nxp.com Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

clk: imx: Select MXC_CLK for CLK_IMX8QXP

2023-11-20T10:06:46+00:00

[ Upstream commit 317e69c49b4ceef8aebb47d771498ccb3571bdf9 ] If the i.MX8QXP clock provider is built-in but the MXC_CLK is built as module, build fails: aarch64-linux-ld: drivers/clk/imx/clk-imx8-acm.o: in function `imx8_acm_clk_probe': clk-imx8-acm.c:(.text+0x3d0): undefined reference to `imx_check_clk_hws' Fix that by selecting MXC_CLK in case of CLK_IMX8QXP. Fixes: c2cccb6d0b33 ("clk: imx: add imx8qxp clk driver") Closes: https://lore.kernel.org/all/8b77219e-b59e-40f1-96f1-980a0b2debcf@infradead.org/ Reported-by: Randy Dunlap Reviewed-by: Peng Fan Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

Revert "clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz"

2023-10-10T19:53:36+00:00

This reverts commit 972acd701b1982da9cdbeb892bf17eeef2094508 which is commit 72d00e560d10665e6139c9431956a87ded6e9880 upstream. Marek writes: The commit message states 'Cc: stable@vger.kernel.org # v5.18+' and the commit should only be applied to Linux 5.18.y and newer, on anything older it breaks PLL configuration due to missing prerequisite patches. Reported-by: Marek Vasut Cc: Ahmad Fatoum Cc: Marco Felsch Cc: Abel Vesa Link: https://lore.kernel.org/r/4e5fa5b2-66b8-8f0b-ccb9-c2b774054e4e@denx.de Signed-off-by: Greg Kroah-Hartman

clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz

2023-09-19T10:20:25+00:00

commit 72d00e560d10665e6139c9431956a87ded6e9880 upstream. Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates"), the driver has the ability to dynamically compute PLL parameters to approximate the requested rates. This is not always used, because the logic is as follows: - Check if the target rate is hardcoded in the frequency table - Check if varying only kdiv is possible, so switch over is glitch free - Compute rate dynamically by iterating over pdiv range If we skip the frequency table for the 1443x PLL, we find that the computed values differ to the hardcoded ones. This can be valid if the hardcoded values guarantee for example an earlier lock-in or if the divisors are chosen, so that other important rates are more likely to be reached glitch-free. For rates (393216000 and 361267200, this doesn't seem to be the case: They are only approximated by existing parameters (393215995 and 361267196 Hz, respectively) and they aren't reachable glitch-free from other hardcoded frequencies. Dropping them from the table allows us to lock-in to these frequencies exactly. This is immediately noticeable because they are the assigned-clock-rates for IMX8MN_AUDIO_PLL1 and IMX8MN_AUDIO_PLL2, respectively and a look into clk_summary so far showed that they were a few Hz short of the target: imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary audio_pll2_out 0 0 0 361267196 0 0 50000 N audio_pll1_out 1 1 0 393215995 0 0 50000 Y and afterwards: imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary audio_pll2_out 0 0 0 361267200 0 0 50000 N audio_pll1_out 1 1 0 393216000 0 0 50000 Y This change is equivalent to adding following hardcoded values: /* rate mdiv pdiv sdiv kdiv */ PLL_1443X_RATE(393216000, 655, 5, 3, 23593), PLL_1443X_RATE(361267200, 497, 33, 0, -16882), Fixes: 053a4ffe2988 ("clk: imx: imx8mm: fix audio pll setting") Cc: stable@vger.kernel.org # v5.18+ Signed-off-by: Ahmad Fatoum Signed-off-by: Marco Felsch Link: https://lore.kernel.org/r/20230807084744.1184791-2-m.felsch@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Greg Kroah-Hartman

clk: imx: composite-8m: fix clock pauses when set_rate would be a no-op

2023-09-19T10:20:14+00:00

[ Upstream commit 4dd432d985ef258e3bc436e568fba4b987b59171 ] Reconfiguring the clock divider to the exact same value is observed on an i.MX8MN to often cause a longer than usual clock pause, probably because the divider restarts counting whenever the register is rewritten. This issue doesn't show up normally, because the clock framework will take care to not call set_rate when the clock rate is the same. However, when we reconfigure an upstream clock, the common code will call set_rate with the newly calculated rate on all children, e.g.: - sai5 is running normally and divides Audio PLL out by 16. - Audio PLL rate is increased by 32Hz (glitch-free kdiv change) - rates for children are recalculated and rates are set recursively - imx8m_clk_composite_divider_set_rate(sai5) is called with 32/16 = 2Hz more - imx8m_clk_composite_divider_set_rate computes same divider as before - divider register is written, so it restarts counting from zero and MCLK is briefly paused, so instead of e.g. 40ns, MCLK is low for 120ns. Some external clock consumers can be upset by such unexpected clock pauses, so let's make sure we only rewrite the divider value when the value to be written is actually different. Fixes: d3ff9728134e ("clk: imx: Add imx composite clock") Signed-off-by: Ahmad Fatoum Reviewed-by: Peng Fan Link: https://lore.kernel.org/r/20230807082201.2332746-1-a.fatoum@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin

clk: imx8mp: fix sai4 clock

2023-09-19T10:20:14+00:00

[ Upstream commit c30f600f1f41dcf5ef0fb02e9a201f9b2e8f31bd ] The reference manual don't mention a SAI4 hardware block. This would be clock slice 78 which is skipped (TRM, page 237). Remove any reference to this clock to align the driver with the reality. Fixes: 9c140d992676 ("clk: imx: Add support for i.MX8MP clock driver") Acked-by: Stephen Boyd Signed-off-by: Marco Felsch Link: https://lore.kernel.org/r/20230731142150.3186650-1-m.felsch@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin