summaryrefslogtreecommitdiff
path: root/drivers/clk
AgeCommit message (Collapse)AuthorFilesLines
2022-12-31clk: imx: imx8mp: add shared clk gate for usb suspend clkLi Jun1-1/+3
commit ed1f4ccfe947a3e1018a3bd7325134574c7ff9b3 upstream. 32K usb suspend clock gate is shared with usb_root_clk, this shared clock gate was initially defined only for usb suspend clock, usb suspend clk is kept on while system is active or system sleep with usb wakeup enabled, so usb root clock is fine with this situation; with the commit cf7f3f4fa9e5 ("clk: imx8mp: fix usb_root_clk parent"), this clock gate is changed to be for usb root clock, but usb root clock will be off while usb is suspended, so usb suspend clock will be gated too, this cause some usb functionalities will not work, so define this clock to be a shared clock gate to conform with the real HW status. Fixes: 9c140d9926761 ("clk: imx: Add support for i.MX8MP clock driver") Cc: stable@vger.kernel.org # v5.19+ Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/1664549663-20364-2-git-send-email-jun.li@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-31clk: st: Fix memory leak in st_of_quadfs_setup()Xiu Jianfeng1-2/+3
[ Upstream commit cfd3ffb36f0d566846163118651d868e607300ba ] If st_clk_register_quadfs_pll() fails, @lock should be freed before goto @err_exit, otherwise will cause meory leak issue, fix it. Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://lore.kernel.org/r/20221122133614.184910-1-xiujianfeng@huawei.com Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: socfpga: Fix memory leak in socfpga_gate_init()Xiu Jianfeng1-1/+4
[ Upstream commit 0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b ] Free @socfpga_clk and @ops on the error path to avoid memory leak issue. Fixes: a30a67be7b6e ("clk: socfpga: Don't have get_parent for single parent ops") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://lore.kernel.org/r/20221123031622.63171-1-xiujianfeng@huawei.com Acked-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: samsung: Fix memory leak in _samsung_clk_register_pll()Xiu Jianfeng1-0/+1
[ Upstream commit 5174e5b0d1b669a489524192b6adcbb3c54ebc72 ] If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it. Fixes: 3ff6e0d8d64d ("clk: samsung: Add support to register rate_table for samsung plls") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://lore.kernel.org/r/20221123032015.63980-1-xiujianfeng@huawei.com Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: qcom: clk-krait: fix wrong div2 functionsChristian Marangi1-0/+2
[ Upstream commit d676d3a3717cf726d3affedbe5ba98fc4ccad7b3 ] Currently div2 value is applied to the wrong bits. This is caused by a bug in the code where the shift is done only for lpl, for anything else the mask is not shifted to the correct bits. Fix this by correctly shift if lpl is not supported. Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: qcom: lpass-sc7180: Fix pm_runtime usageDouglas Anderson1-8/+16
[ Upstream commit ff1ccf59eaffd192efe21f7de9fb0c130faf1b1b ] The sc7180 lpass clock controller's pm_runtime usage wasn't broken quite as spectacularly as the sc7280's pm_runtime usage, but it was still broken. Putting some printouts in at boot showed me this (with serial console enabled, which makes the prints slow and thus changes timing): [ 3.109951] DOUG: my_pm_clk_resume, usage=1 [ 3.114767] DOUG: my_pm_clk_resume, usage=1 [ 3.664443] DOUG: my_pm_clk_suspend, usage=0 [ 3.897566] DOUG: my_pm_clk_suspend, usage=0 [ 3.910137] DOUG: my_pm_clk_resume, usage=1 [ 3.923217] DOUG: my_pm_clk_resume, usage=0 [ 4.440116] DOUG: my_pm_clk_suspend, usage=-1 [ 4.444982] DOUG: my_pm_clk_suspend, usage=0 [ 14.170501] DOUG: my_pm_clk_resume, usage=1 [ 14.176245] DOUG: my_pm_clk_resume, usage=0 ...or this w/out serial console: [ 0.556139] DOUG: my_pm_clk_resume, usage=1 [ 0.556279] DOUG: my_pm_clk_resume, usage=1 [ 1.058422] DOUG: my_pm_clk_suspend, usage=-1 [ 1.058464] DOUG: my_pm_clk_suspend, usage=0 [ 1.186250] DOUG: my_pm_clk_resume, usage=1 [ 1.186292] DOUG: my_pm_clk_resume, usage=0 [ 1.731536] DOUG: my_pm_clk_suspend, usage=-1 [ 1.731557] DOUG: my_pm_clk_suspend, usage=0 [ 10.288910] DOUG: my_pm_clk_resume, usage=1 [ 10.289496] DOUG: my_pm_clk_resume, usage=0 It seems to be doing roughly the right sequence of calls, but just like with sc7280 this is more by luck than anything. Having a usage of -1 is just not OK. Let's fix this like we did with sc7280. Signed-off-by: Douglas Anderson <dianders@chromium.org> Fixes: ce8c195e652f ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: qcom: lpass-sc7280: Fix pm_runtime usageDouglas Anderson1-34/+21
[ Upstream commit d470be3c4f30b4666e43eef6bab80f543563cdb0 ] The pm_runtime usage in lpass-sc7280 was broken in quite a few ways. Specifically: 1. At the end of probe it called "put" twice. This is a no-no and will end us up with a negative usage count. Even worse than calling "put" twice, it never called "get" once. Thus after bootup it could be seen that the runtime usage of the devices managed by this driver was -2. 2. In some error cases it manually called pm_runtime_disable() even though it had previously used devm_add_action_or_reset() to set this up to be called automatically. This meant that in these error cases we'd double-call pm_runtime_disable(). 3. It forgot to call undo pm_runtime_use_autosuspend(), which can sometimes have subtle problems (and the docs specifically mention that you need to undo this function). Overall the above seriously calls into question how this driver is working. It seems like a combination of "it doesn't", "by luck", and "because of the weirdness of runtime_pm". Specifically I put a printout to the serial console every time the runtime suspend/resume was called for the two devices created by this driver (I wrapped the pm_clk calls). When I had serial console enabled, I found that the calls got resumed at bootup (when the clk core probed and before our double-put) and then never touched again. That's no good. [ 0.829997] DOUG: my_pm_clk_resume, usage=1 [ 0.835487] DOUG: my_pm_clk_resume, usage=1 When I disabled serial console (speeding up boot), I got a different pattern, which I guess (?) is better: [ 0.089767] DOUG: my_pm_clk_resume, usage=1 [ 0.090507] DOUG: my_pm_clk_resume, usage=1 [ 0.151885] DOUG: my_pm_clk_suspend, usage=-2 [ 0.151914] DOUG: my_pm_clk_suspend, usage=-2 [ 1.825747] DOUG: my_pm_clk_resume, usage=-1 [ 1.825774] DOUG: my_pm_clk_resume, usage=-1 [ 1.888269] DOUG: my_pm_clk_suspend, usage=-2 [ 1.888282] DOUG: my_pm_clk_suspend, usage=-2 These different patterns have to do with the fact that the core PM Runtime code really isn't designed to be robust to negative usage counts and sometimes may happen to stumble upon a behavior that happens to "work". For instance, you can see that __pm_runtime_suspend() will treat any non-zero value (including negative numbers) as if the device is in use. In any case, let's fix the driver to be correct. We'll hold a pm_runtime reference for the whole probe and then drop it (once!) at the end. We'll get rid of manual pm_runtime_disable() calls in the error handling. We'll also switch to devm_pm_runtime_enable(), which magically handles undoing pm_runtime_use_autosuspend() as of commit b4060db9251f ("PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()"). While we're at this, let's also use devm_pm_clk_create() instead of rolling it ourselves. Note that the above changes make it obvious that lpassaudio_create_pm_clks() was doing more than just creating clocks. It was also setting up pm_runtime parameters. Let's rename it. All of these problems were found by code inspection. I started looking at this driver because it was involved in a deadlock that I reported a while ago [1]. Though I bisected the deadlock to commit 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support"), it was never really clear why that patch affected it other than a luck of timing changes. I'll also note that by fixing the timing (as done in this change) we also seem to aboid the deadlock, which is a nice benefit. Also note that some of the fixes here are much the same type of stuff that Dmitry did in commit 72cfc73f4663 ("clk: qcom: use devm_pm_runtime_enable and devm_pm_clk_create"), but I guess lpassaudiocc-sc7280.c didn't exist then. [1] https://lore.kernel.org/r/20220922154354.2486595-1-dianders@chromium.org Fixes: a9dd26639d05 ("clk: qcom: lpass: Add support for LPASS clock controller for SC7280") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221104064055.1.I00a0e4564a25489e85328ec41636497775627564@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: visconti: Fix memory leak in visconti_register_pll()Xiu Jianfeng1-0/+1
[ Upstream commit b55226f8553d255f5002c751c7c6ba9291f34bf2 ] @pll->rate_table has allocated memory by kmemdup(), if clk_hw_register() fails, it should be freed, otherwise it will cause memory leak issue, this patch fixes it. Fixes: b4cbe606dc36 ("clk: visconti: Add support common clock driver and reset driver") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://lore.kernel.org/r/20221122152353.204132-1-xiujianfeng@huawei.com Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: mediatek: fix dependency of MT7986 ADC clocksDaniel Golle1-1/+1
[ Upstream commit a46315295489933209e902638cd287aeb5f982ab ] It seems like CLK_INFRA_ADC_FRC_CK always need to be enabled for CLK_INFRA_ADC_26M_CK to work. Instead of adding this dependency to the mtk-thermal and mt6577_auxadc drivers, add dependency to the clock driver clk-mt7986-infracfg.c. Fixes: ec97d23c8e22 ("clk: mediatek: add mt7986 clock support") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/5e55012567da74870e1fb2edc2dc513b5821e523.1666801017.git.daniel@makrotopia.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx8mn: fix imx8mn_enet_phy_sels clocks listDario Binacchi1-2/+2
[ Upstream commit 2626cf67f20b28446dfc3a5b9493dd535cdb747b ] According to the "Clock Root" table of the reference manual (document IMX8MNRM Rev 2, 07/2022): Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX]) ... ... ... ENET_PHY_REF_CLK_ROOT 0xAA80 000 - 24M_REF_CLK 001 - SYSTEM_PLL2_DIV20 010 - SYSTEM_PLL2_DIV8 011 - SYSTEM_PLL2_DIV5 100 - SYSTEM_PLL2_DIV2 101 - AUDIO_PLL1_CLK 110 - VIDEO_PLL_CLK 111 - AUDIO_PLL2_CLK ... ... ... while the imx8mn_enet_phy_sels list didn't contained audio_pll1_out for source select bits 101b. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Acked-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221117113637.1978703-6-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx8mn: fix imx8mn_sai2_sels clocks listDario Binacchi1-1/+1
[ Upstream commit 34d996747a74e3a86990f9f9c48de09159d78edb ] According to the "Clock Root" table of the reference manual (document IMX8MNRM Rev 2, 07/2022): Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX]) ... ... ... SAI2_CLK_ROOT 0xA600 000 - 24M_REF_CLK 001 - AUDIO_PLL1_CLK 010 - AUDIO_PLL2_CLK 011 - VIDEO_PLL_CLK 100 - SYSTEM_PLL1_DIV6 110 - EXT_CLK_2 111 - EXT_CLK_3 ... ... ... while the imx8mn_sai2_sels list contained clk_ext3 and clk_ext4 for source select bits 110b and 111b. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Acked-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221117113637.1978703-5-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx: rename video_pll1 to video_pllDario Binacchi1-48/+48
[ Upstream commit bedcf9d1dcf88ed38731f0ac9620e5a421e1e9d6 ] Unlike audio_pll1 and audio_pll2, there is no video_pll2. Further, the name used in the RM is video_pll. So, let's rename "video_pll1" to "video_pll" to be consistent with the RM and avoid misunderstandings. The IMX8MN_VIDEO_PLL1* constants have not been removed to ensure backward compatibility of the patch. No functional changes intended. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Acked-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221117113637.1978703-4-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx: replace osc_hdmi with dummyDario Binacchi1-6/+6
[ Upstream commit e7fa365ff66f16772dc06b480cd78f858d10856b ] There is no occurrence of the hdmi oscillator in the reference manual (document IMX8MNRM Rev 2, 07/2022). Further, if we consider the indexes 76-81 and 134 of the "Clock Root" table of chapter 5 of the RM, there is no entry for the source select bits 101b, which is the setting referenced by "osc_hdmi". Fix by renaming "osc_hdmi" with "dummy", a clock which has already been used for missing source select bits. Tested on the BSH SystemMaster (SMM) S2 board. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Acked-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221117113637.1978703-3-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx8mn: rename vpu_pll to m7_alt_pllDario Binacchi1-8/+8
[ Upstream commit a429c60baefd95ab43a2ce7f25d5b2d7a2e431df ] The IMX8MN platform does not have any video processing unit (VPU), and indeed in the reference manual (document IMX8MNRM Rev 2, 07/2022) there is no occurrence of its pll. From an analysis of the code and the RM itself, I think vpu pll is used instead of m7 alternate pll, probably for copy and paste of code taken from modules of similar architectures. As an example for all, if we consider the second row of the "Clock Root" table of chapter 5 (Clocks and Power Management) of the RM: Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX]) ... ... ... ARM_M7_CLK_ROOT 0x8080 000 - 24M_REF_CLK 001 - SYSTEM_PLL2_DIV5 010 - SYSTEM_PLL2_DIV4 011 - M7_ALT_PLL_CLK 100 - SYSTEM_PLL1_CLK 101 - AUDIO_PLL1_CLK 110 - VIDEO_PLL_CLK 111 - SYSTEM_PLL3_CLK ... ... ... but in the source code, the imx8mn_m7_sels clocks list contains vpu_pll for the source select bits 011b. So, let's rename "vpu_pll" to "m7_alt_pll" to be consistent with the RM. The IMX8MN_VPU_* constants have not been removed to ensure backward compatibility of the patch. No functional changes intended. Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Acked-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221117113637.1978703-2-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: microchip: check for null return of devm_kzalloc()Hui Tang1-0/+6
[ Upstream commit e2e6a217a84d09785848a82599729c9a41566e3a ] Because of the possible failure of devm_kzalloc(), name might be NULL and will cause null pointer dereference later. Therefore, it might be better to check it and directly return -ENOMEM. Fixes: d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support") Signed-off-by: Hui Tang <tanghui20@huawei.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> [claudiu.beznea: s/refrence/reference/, s/possilble/possible] Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20221119054858.178629-1-tanghui20@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: rockchip: Fix memory leak in rockchip_clk_register_pll()Xiu Jianfeng1-0/+1
[ Upstream commit 739a6a6bbdb793bd57938cb24aa5a6df89983546 ] If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it. Fixes: 90c590254051 ("clk: rockchip: add clock type for pll clocks and pll used on rk3066") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Link: https://lore.kernel.org/r/20221123091201.199819-1-xiujianfeng@huawei.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx: imxrt1050: fix IMXRT1050_CLK_LCDIF_APB offsetsGiulio Benetti1-1/+1
[ Upstream commit 3095c02f95e537c553e0b30948c2f6c7cbed87ee ] Fix IMXRT1050_CLK_LCDIF_APB offsets. Fixes: 7154b046d8f3 ("clk: imx: Add initial support for i.MXRT1050 clock driver") Cc: Jesse Taube <mr.bossman075@gmail.com> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221117181014.851505-1-giulio.benetti@benettiengineering.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx93: correct enet clockPeng Fan1-1/+1
[ Upstream commit 4be5d91b9433f1dc76de485e240ca6aaa2d19f65 ] Per update Reference Mannual, correct the enet clock parent to wakeup_axi_root. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Reviewed-by: Ye Li <ye.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221028095211.2598312-3-peng.fan@oss.nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx93: unmap anatop base in error handling pathPeng Fan1-6/+9
[ Upstream commit bda7b7f396f94d8df89ecacc88f2826908e8762c ] The anatop base is not unmapped during error handling path, fix it. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20221028095211.2598312-2-peng.fan@oss.nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: imx93: correct the flexspi1 clock settingHaibo Chen1-1/+1
[ Upstream commit 62dfdbcc16e767b91ed35d4fc0428c86d4688505 ] Correct IMX93_CLK_FLEXSPI1_GATE CCGR setting. Otherwise the flexspi always can't be assigned to a parent clock when dump the clock tree. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/1666589199-1199-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: renesas: r8a779f0: Fix SCIF parent clocksWolfram Sang1-4/+4
[ Upstream commit 2e0d7d3eabce3babae1fd66d7650e00c848a3b45 ] As serial communication requires a clean clock signal, the Serial Communication Interfaces with FIFO (SCIF) are clocked by a clock that is not affected by Spread Spectrum or Fractional Multiplication. Hence change the parent clocks for the SCIF modules from the S0D12_PER clock to the SASYNCPERD4 clock (which has the same clock rate), cfr. R-Car S4-8 Hardware User's Manual rev. 0.81. Fixes: 24aaff6a6ce4 ("clk: renesas: cpg-mssr: Add support for R-Car S4-8") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221103143440.46449-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: renesas: r8a779f0: Fix HSCIF parent clocksWolfram Sang1-4/+4
[ Upstream commit c258e3ab639112d8f5ae9df9a873750ae2623ce2 ] As serial communication requires a clean clock signal, the High Speed Serial Communication Interfaces with FIFO (HSCIF) are clocked by a clock that is not affected by Spread Spectrum or Fractional Multiplication. Hence change the parent clocks for the HSCIF modules from the S0D3_PER clock to the SASYNCPERD1 clock (which has the same clock rate), cfr. R-Car S4-8 Hardware User's Manual rev. 0.81. Fixes: 080bcd8d5997 ("clk: renesas: r8a779f0: Add HSCIF clocks") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221103143440.46449-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: qcom: gcc-sm8250: Use retention mode for USB GDSCsManivannan Sadhasivam1-2/+2
[ Upstream commit ac1c5a03d3772b1db25e8092f771aa33f6ae2f7e ] USB controllers on SM8250 doesn't work after coming back from suspend. This can be fixed by keeping the USB GDSCs in retention mode so that hardware can keep them ON and put into rentention mode once the parent domain goes to a low power state. Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221102091320.66007-1-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: qcom: dispcc-sm6350: Add CLK_OPS_PARENT_ENABLE to pixel&byte srcKonrad Dybcio1-2/+2
[ Upstream commit 92039e8c080c63748f8e133e7cfad33a75daefb6 ] Add the CLK_OPS_PARENT_ENABLE flag to pixel and byte clk srcs to ensure set_rate can succeed. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350") Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221010155546.73884-1-konrad.dybcio@somainline.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: qcom: gcc-ipq806x: use parent_data for the last remaining entryDmitry Baryshkov1-1/+3
[ Upstream commit 55307e522cc7a4dddc3d231ca5cb7e68e9668f66 ] Use parent_data for the last remaining entry (pll4). This clock is provided by the lcc device. Fixes: cb02866f9a74 ("clk: qcom: gcc-ipq806x: convert parent_names to parent_data") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220927113826.246241-3-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: renesas: r9a06g032: Repair grave increment errorMarek Vasut1-2/+1
[ Upstream commit 02693e11611e082e3c4d8653e8af028e43d31164 ] If condition (clkspec.np != pd->dev.of_node) is true, then the driver ends up in an endless loop, forever, locking up the machine. Fixes: aad03a66f902 ("clk: renesas: r9a06g032: Add clock domain support") Reviewed-by: Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Gareth Williams <gareth.williams.jx@renesas.com> Link: https://lore.kernel.org/r/20221028113834.7496-1-marex@denx.de Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: renesas: r8a779a0: Fix SD0H clock nameWolfram Sang1-1/+1
[ Upstream commit db7076d5a7f0ca7dcf08f5095c74f86d4d0085ff ] Correct the misspelled textual name of the SD0H clock. Fixes: 470e3f0d0b15 ("clk: renesas: rcar-gen4: Introduce R-Car Gen4 CPG driver") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221012184830.3199-1-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31clk: renesas: r8a779f0: Fix SD0H clock nameGeert Uytterhoeven1-1/+1
[ Upstream commit 99c05a2b710f16ea592ccb63ef5fe5f1f6b15db9 ] Correct the misspelled textual name of the SD0H clock. Fixes: 9b5dd1ff705c6854 ("clk: renesas: r8a779f0: Add SDH0 clock") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/1f682d338f133608f138ae87323707436ad8c748.1665558014.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-11-23clk: qcom: gcc-sc8280xp: add cxo as parent for three ufs ref clksShazad Hussain1-0/+6
The three UFS reference clocks, gcc_ufs_ref_clkref_clk for external UFS devices, gcc_ufs_card_clkref_clk and gcc_ufs_1_card_clkref_clk for two PHYs are all sourced from CXO. Added parent_data for all three reference clocks described above to reflect that all three clocks are sourced from CXO to have valid frequency for the ref clock needed by UFS controller driver. Fixes: d65d005f9a6c ("clk: qcom: add sc8280xp GCC driver") Link: https://lore.kernel.org/lkml/Y2Tber39cHuOSR%2FW@hovoldconsulting.com/ Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com> Tested-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Andrew Halaney <ahalaney@redhat.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/r/20221115152956.21677-1-quic_shazhuss@quicinc.com Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-11-23Merge tag 'clk-microchip-fixes-6.1' of ↵Stephen Boyd1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-fixes Pull Microchip clk driver fixes from Claudiu Beznea: - fix the clock ID for USB device port on AT91 RM9200 SoCs; along with it the device tree references to this clocks were fixed in this patch to ease the backporting and to avoid USB driver probe failure. * tag 'clk-microchip-fixes-6.1' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: at91: rm9200: fix usb device clock id
2022-11-23Merge tag 'samsung-clk-6.2' of ↵Stephen Boyd2-4/+6
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into clk-fixes Pull Samsung SoC clk driver fixes from Krzysztof Kozlowski: - Fix calling of_device_get_match_data() on wrong device (parent's) in Exynos clock out driver - Correct clock name in bindings of ExynosAutov9 clocks - Correct parents of div4 clock on Exynos7885 * tag 'samsung-clk-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: clk: samsung: Revert "clk: samsung: exynos-clkout: Use of_device_get_match_data()" dt-bindings: clock: exynosautov9: fix reference to CMU_FSYS1 clk: samsung: exynos7885: Correct "div4" clock parents
2022-11-17ARM: at91: rm9200: fix usb device clock idMichael Grzeschik1-1/+1
Referring to the datasheet the index 2 is the MCKUDP. When enabled, it "Enables the automatic disable of the Master Clock of the USB Device Port when a suspend condition occurs". We fix the index to the real UDP id which "Enables the 48 MHz clock of the USB Device Port". Cc: nicolas.ferre@microchip.com Cc: ludovic.desroches@microchip.com Cc: alexandre.belloni@bootlin.com Cc: mturquette@baylibre.com Cc: sboyd@kernel.org Cc: claudiu.beznea@microchip.com Cc: linux-clk@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: kernel@pengutronix.de Fixes: 02ff48e4d7f7 ("clk: at91: add at91rm9200 pmc driver") Fixes: 0e0e528d8260 ("ARM: dts: at91: rm9200: switch to new clock bindings") Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20221114185923.1023249-2-m.grzeschik@pengutronix.de
2022-11-15clk: samsung: Revert "clk: samsung: exynos-clkout: Use ↵Marek Szyprowski1-2/+4
of_device_get_match_data()" of_device_get_match_data() function should not be used on the device other than the one matched to the given driver, because it always returns the match_data of the matched driver. In case of exynos-clkout driver, the code matched the OF IDs on the PARENT device, so replacing it with of_device_get_match_data() broke the driver. This reverts commit 777aaf3d1daf793461269b49c063aca1cee06a44. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: 777aaf3d1daf ("clk: samsung: exynos-clkout: Use of_device_get_match_data()") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221108213718.32076-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-11-04clk: qcom: gdsc: Remove direct runtime PM callsStephen Boyd2-57/+6
We shouldn't be calling runtime PM APIs from within the genpd enable/disable path for a couple reasons. First, this causes an AA lockdep splat[1] because genpd can call into genpd code again while holding the genpd lock. WARNING: possible recursive locking detected 5.19.0-rc2-lockdep+ #7 Not tainted -------------------------------------------- kworker/2:1/49 is trying to acquire lock: ffffffeea0370788 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30 but task is already holding lock: ffffffeea03710a8 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&genpd->mlock); lock(&genpd->mlock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/2:1/49: #0: 74ffff80811a5748 ((wq_completion)pm){+.+.}-{0:0}, at: process_one_work+0x320/0x5fc #1: ffffffc008537cf8 ((work_completion)(&genpd->power_off_work)){+.+.}-{0:0}, at: process_one_work+0x354/0x5fc #2: ffffffeea03710a8 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x24/0x30 stack backtrace: CPU: 2 PID: 49 Comm: kworker/2:1 Not tainted 5.19.0-rc2-lockdep+ #7 Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT) Workqueue: pm genpd_power_off_work_fn Call trace: dump_backtrace+0x1a0/0x200 show_stack+0x24/0x30 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x44 __lock_acquire+0xb38/0x3634 lock_acquire+0x180/0x2d4 __mutex_lock_common+0x118/0xe30 mutex_lock_nested+0x70/0x7c genpd_lock_mtx+0x24/0x30 genpd_runtime_suspend+0x2f0/0x414 __rpm_callback+0xdc/0x1b8 rpm_callback+0x4c/0xcc rpm_suspend+0x21c/0x5f0 rpm_idle+0x17c/0x1e0 __pm_runtime_idle+0x78/0xcc gdsc_disable+0x24c/0x26c _genpd_power_off+0xd4/0x1c4 genpd_power_off+0x2d8/0x41c genpd_power_off_work_fn+0x60/0x94 process_one_work+0x398/0x5fc worker_thread+0x42c/0x6c4 kthread+0x194/0x1b4 ret_from_fork+0x10/0x20 Second, this confuses runtime PM on CoachZ for the camera devices by causing the camera clock controller's runtime PM usage_count to go negative after resuming from suspend. This is because runtime PM is being used on the clock controller while runtime PM is disabled for the device. The reason for the negative count is because a GDSC is represented as a genpd and each genpd that is attached to a device is resumed during the noirq phase of system wide suspend/resume (see the noirq suspend ops assignment in pm_genpd_init() for more details). The camera GDSCs are attached to camera devices with the 'power-domains' property in DT. Every device has runtime PM disabled in the late system suspend phase via __device_suspend_late(). Runtime PM is not usable until runtime PM is enabled in device_resume_early(). The noirq phases run after the 'late' and before the 'early' phase of suspend/resume. When the genpds are resumed in genpd_resume_noirq(), we call down into gdsc_enable() that calls pm_runtime_resume_and_get() and that returns -EACCES to indicate failure to resume because runtime PM is disabled for all devices. Upon closer inspection, calling runtime PM APIs like this in the GDSC driver doesn't make sense. It was intended to make sure the GDSC for the clock controller providing other GDSCs was enabled, specifically the MMCX GDSC for the display clk controller on SM8250 (sm8250-dispcc), so that GDSC register accesses succeeded. That will already happen because we make the 'dev->pm_domain' a parent domain of each GDSC we register in gdsc_register() via pm_genpd_add_subdomain(). When any of these GDSCs are accessed, we'll enable the parent domain (in this specific case MMCX). We also remove any getting of runtime PM during registration, because when a genpd is registered it increments the count on the parent if the genpd itself is already enabled. Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Johan Hovold <johan+linaro@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Taniya Das <quic_tdas@quicinc.com> Cc: Satya Priya <quic_c_skakit@quicinc.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Cc: Matthias Kaehlcke <mka@chromium.org> Reported-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/CAE-0n52xbZeJ66RaKwggeRB57fUAwjvxGxfFMKOKJMKVyFTe+w@mail.gmail.com [1] Fixes: 1b771839de05 ("clk: qcom: gdsc: enable optional power domain support") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20221103183030.3594899-1-swboyd@chromium.org Tested-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-28clk: qcom: Update the force mem core bit for GPU clocksTaniya Das2-0/+2
There are few GPU clocks which are powering up the memories and thus enable the FORCE_MEM_PERIPH always for these clocks to force the periph_on signal to remain active during halt state of the clock. Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280") Fixes: 3e0f01d6c7e7 ("clk: qcom: Add graphics clock controller driver for SC7280") Signed-off-by: Taniya Das <quic_tdas@quicinc.com> Signed-off-by: Satya Priya <quic_c_skakit@quicinc.com> Link: https://lore.kernel.org/r/1666159535-6447-1-git-send-email-quic_c_skakit@quicinc.com 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-27Merge tag 'renesas-clk-fixes-for-v6.1-tag1' of ↵Stephen Boyd1-4/+9
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-fixes Pull Renesas clk driver fixes from Geert Uytterhoeven: - Correct the parent clocks for the High Speed Serial Communication Interfaces with FIFO (HSCIF) modules on the R-Car V4H SoC. Note that HSCIF0 is used for the serial console on the White-Hawk development board. * tag 'renesas-clk-fixes-for-v6.1-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers: clk: renesas: r8a779g0: Fix HSCIF parent clocks clk: renesas: r8a779g0: Add SASYNCPER clocks
2022-10-26clk: renesas: r8a779g0: Fix HSCIF parent clocksGeert Uytterhoeven1-4/+4
As serial communication requires a clean clock signal, the High Speed Serial Communication Interfaces with FIFO (HSCIF) is clocked by a clock that is not affected by Spread Spectrum or Fractional Multiplication. Hence change the parent clocks for the HSCIF modules from the S0D3_PER clock to the SASYNCPERD1 clock (which has the same clock rate), cfr. R-Car V4H Hardware User's Manual rev. 0.54. Fixes: 0ab55cf1834177a2 ("clk: renesas: cpg-mssr: Add support for R-Car V4H") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/b7928abc8b9f53d5b06ec8624342f449de3d24ec.1665147497.git.geert+renesas@glider.be
2022-10-18clk: samsung: exynos7885: Correct "div4" clock parentsDavid Virag1-2/+2
"div4" DIVs which divide PLLs by 4 are actually dividing "div2" DIVs by 2 to achieve a by 4 division, thus their parents are the respective "div2" DIVs. These DIVs were mistakenly set to have the PLLs as parents. This leads to the kernel thinking "div4"s and everything under them run at 2x the clock speed. Fix this. Fixes: 45bd8166a1d8 ("clk: samsung: Add initial Exynos7885 clock driver") Signed-off-by: David Virag <virag.david003@gmail.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Link: https://lore.kernel.org/r/20221013151341.151208-1-virag.david003@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-10-18clk: renesas: r8a779g0: Add SASYNCPER clocksGeert Uytterhoeven1-0/+5
On R-Car V4H, all PLLs except PLL5 support Spread Spectrum and/or Fractional Multiplication to reduce electromagnetic interference. Add the SASYNCPER and SASYNCPERD[124] clocks, which are used as clock sources for modules that must not be affected by Spread Spectrum and/or Fractional Multiplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/d0f35c35e1f96c5a649ab477e7ba5d8025957cd0.1665147497.git.geert+renesas@glider.be
2022-10-18clk: mediatek: clk-mt8195-topckgen: Fix error return code in ↵Yang Yingliang1-1/+3
clk_mt8195_topck_probe() If devm_clk_hw_register_mux() fails in clk_mt8195_topck_probe(), it should return error code. Fixes: deeb2af77cf6 ("clk: mediatek: clk-mt8195-topckgen: Register mfg_ck_fast_ref as generic mux") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221009025056.35311-1-yangyingliang@huawei.com Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-18clk: sifive: select by default if SOC_SIFIVEConor Dooley1-1/+3
With the aim of dropping direct selects of drivers from Kconfig.socs, default the SiFive clock drivers to the value of SOC_SIFIVE. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221005171348.167476-2-conor@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-18clk: rs9: Fix I2C accessorsMarek Vasut1-3/+62
Add custom I2C accessors to this driver, since the regular I2C regmap ones do not generate the exact I2C transfers required by the chip. On I2C write, it is mandatory to send transfer length first, on read the chip returns the transfer length in first byte. Instead of always reading back 8 bytes, which is the default and also the size of the entire register file, set BCP register to 1 to read out 1 byte which is less wasteful. Fixes: 892e0ddea1aa ("clk: rs9: Add Renesas 9-series PCIe clock generator driver") Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20220929195521.284497-1-marex@denx.de Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-16Merge tag 'clk-for-linus' of ↵Linus Torvalds15-124/+1810
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 tag 'arm-fixes-6.1-1' of ↵Linus Torvalds2-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "These are three fixes for build warnings that came in during the merge window" * tag 'arm-fixes-6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: mmp: Make some symbols static ARM: spear6xx: Staticize few definitions clk: spear: Move prototype to accessible header
2022-10-14Merge branch 'clk-rate-range' into clk-nextStephen Boyd9-113/+1805
- 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-14clk: tegra: Fix Tegra PWM parent clockJon Hunter5-0/+5
Commit 8c193f4714df ("pwm: tegra: Optimize period calculation") updated the period calculation in the Tegra PWM driver and now returns an error if the period requested is less than minimum period supported. This is breaking PWM support on various Tegra platforms. For example, on the Tegra210 Jetson Nano platform this is breaking the PWM fan support and probing the PWM fan driver now fails ... pwm-fan pwm-fan: Failed to configure PWM: -22 pwm-fan: probe of pwm-fan failed with error -22 The problem is that the default parent clock for the PWM on Tegra210 is a 32kHz clock and is unable to support the requested PWM period. Fix PWM support on Tegra20, Tegra30, Tegra114, Tegra124 and Tegra210 by updating the parent clock for the PWM to be the PLL_P. Fixes: 8c193f4714df ("pwm: tegra: Optimize period calculation") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Robert Eckelmann <longnoserob@gmail.com> # TF101 T20 Tested-by: Antoni Aloy Torrens <aaloytorrens@gmail.com> # TF101 T20 Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # TF201 T30 Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # TF700T T3 Link: https://lore.kernel.org/r/20221010100046.6477-1-jonathanh@nvidia.com Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-10-14clk: qcom: gcc-msm8660: Drop hardcoded fixed board clocksLinus Walleij1-11/+0
These two clocks are now registered in the device tree as fixed clocks, causing a regression in the driver as the clock already exists with e.g. the name "pxo_board" as the MSM8660 GCC driver probes. Fix this by just not hard-coding this anymore and everything works like a charm. Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: baecbda52933 ("ARM: dts: qcom: msm8660: fix node names for fixed clocks") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20221013140745.7801-1-linus.walleij@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-14 18:19:58 +0300