aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/clk
AgeCommit message (Collapse)Author
2019-11-24clk: samsung: Use clk_hw API for calling clk framework from clk notifiersMarek Szyprowski
[ Upstream commit 1da220e3a5d22fccda0bc8542997abc1d1741268 ] clk_notifier_register() documentation states, that the provided notifier callbacks associated with the notifier must not re-enter into the clk framework by calling any top-level clk APIs. Fix this by replacing clk_get_rate() calls with clk_hw_get_rate(), which is safe in this context. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24clk: samsung: exynos5420: Define CLK_SECKEY gate clock only or Exynos5420Joonyoung Shim
[ Upstream commit d32dd2a1a0f80edad158c9a1ba5f47650d9504a0 ] The bit of GATE_BUS_PERIS1 for CLK_SECKEY is just reserved on exynos5422/5800, not exynos5420. Define gate clk for exynos5420 to handle the bit only on exynos5420. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> [m.szyprow: rewrote commit subject] Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24clk: samsung: Use NOIRQ stage for Exynos5433 clocks suspend/resumeMarek Szyprowski
[ Upstream commit 70da9ee80228e6d98fd68e3c1db124c4461d283c ] SoC clock drivers should suspend after every other drivers in the system, which are using clocks and resume before them. The last stage for calling suspend device callbacks is NOIRQ stage and there exists driver, which use that state (dwmmc-exynos), so Exynos5433 clocks driver should also use it. During the same stage, clocks driver will be always suspended after its clients as a direct result of proper device probe order (deferred probe reorders the suspend call sequence). Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24clk: keystone: Enable TISCI clocks if K3_ARCHNishanth Menon
[ Upstream commit 2f149e6e14bcb5e581e49307b54aafcd6f74a74f ] K3_ARCH uses TISCI for clocks as well. Enable the same for the driver support. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-20clk: sunxi-ng: h6: fix PWM gate/reset offsetRongyi Chen
[ Upstream commit 58c0f79887d5e425fe6a9fd542778e50df69e9c6 ] Currently the register offset of the PWM bus gate in Allwinner H6 clock driver is wrong. Fix this issue. Fixes: 542353ea ("clk: sunxi-ng: add support for the Allwinner H6 CCU") Signed-off-by: Rongyi Chen <chenyi@tt-cool.com> [Icenowy: refactor commit message] Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-06clk: boston: unregister clks on failure in clk_boston_setup()Yi Wang
[ Upstream commit 8b627f616ed63dcaf922369fc14a5daf8ad03038 ] The registered clks should unregister when something wrong happens before going out in function clk_boston_setup(). Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sprd: add missing kfreeChunyan Zhang
[ Upstream commit 5e75ea9c67433a065b0e8595ad3c91c7c0ca0d2d ] The number of config registers for different pll clocks probably are not same, so we have to use malloc, and should free the memory before return. Fixes: 3e37b005580b ("clk: sprd: add adjustable pll support") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lkml.kernel.org/r/20190905103009.27166-1-zhang.lyra@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: at91: select parent if main oscillator or bypass is enabledEugen Hristev
[ Upstream commit 69a6bcde7fd3fe6f3268ce26f31d9d9378384c98 ] Selecting the right parent for the main clock is done using only main oscillator enabled bit. In case we have this oscillator bypassed by an external signal (no driving on the XOUT line), we still use external clock, but with BYPASS bit set. So, in this case we must select the same parent as before. Create a macro that will select the right parent considering both bits from the MOR register. Use this macro when looking for the right parent. Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Link: https://lkml.kernel.org/r/1568042692-11784-2-git-send-email-eugen.hristev@microchip.com Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: qcom: gcc-sdm845: Use floor ops for sdcc clksStephen Boyd
[ Upstream commit 5e4b7e82d497580bc430576c4c9bce157dd72512 ] Some MMC cards fail to enumerate properly when inserted into an MMC slot on sdm845 devices. This is because the clk ops for qcom clks round the frequency up to the nearest rate instead of down to the nearest rate. For example, the MMC driver requests a frequency of 52MHz from clk_set_rate() but the qcom implementation for these clks rounds 52MHz up to the next supported frequency of 100MHz. The MMC driver could be modified to request clk rate ranges but for now we can fix this in the clk driver by changing the rounding policy for this clk to be round down instead of round up. Fixes: 06391eddb60a ("clk: qcom: Add Global Clock controller (GCC) driver for SDM845") Reported-by: Douglas Anderson <dianders@chromium.org> Cc: Taniya Das <tdas@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lkml.kernel.org/r/20190830195142.103564-1-swboyd@chromium.org Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: renesas: cpg-mssr: Set GENPD_FLAG_ALWAYS_ON for clock domainGeert Uytterhoeven
[ Upstream commit f787216f33ce5b5a2567766398f44ab62157114c ] The CPG/MSSR Clock Domain driver does not implement the generic_pm_domain.power_{on,off}() callbacks, as the domain itself cannot be powered down. Hence the domain should be marked as always-on by setting the GENPD_FLAG_ALWAYS_ON flag, to prevent the core PM Domain code from considering it for power-off, and doing unnessary processing. Note that this only affects RZ/A2 SoCs. On R-Car Gen2 and Gen3 SoCs, the R-Car SYSC driver handles Clock Domain creation, and offloads only device attachment/detachment to the CPG/MSSR driver. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: renesas: mstp: Set GENPD_FLAG_ALWAYS_ON for clock domainGeert Uytterhoeven
[ Upstream commit a459a184c978ca9ad538aab93aafdde873953f30 ] The CPG/MSTP Clock Domain driver does not implement the generic_pm_domain.power_{on,off}() callbacks, as the domain itself cannot be powered down. Hence the domain should be marked as always-on by setting the GENPD_FLAG_ALWAYS_ON flag, to prevent the core PM Domain code from considering it for power-off, and doing unnessary processing. This also gets rid of a boot warning when the Clock Domain contains an IRQ-safe device, e.g. on RZ/A1: sh_mtu2 fcff0000.timer: PM domain cpg_clocks will not be powered off Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: zx296718: Don't reference clk_init_data after registrationStephen Boyd
[ Upstream commit 1a4549c150e27dbc3aea762e879a88209df6d1a5 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Jun Nie <jun.nie@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190815160020.183334-3-sboyd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sprd: Don't reference clk_init_data after registrationStephen Boyd
[ Upstream commit f6c90df8e7e33c3dc33d4d7471bc42c232b0510e ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Chunyan Zhang <zhang.chunyan@linaro.org> Cc: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-8-sboyd@kernel.org Acked-by: Baolin Wang <baolin.wang@linaro.org> Acked-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sirf: Don't reference clk_init_data after registrationStephen Boyd
[ Upstream commit af55dadfbce35b4f4c6247244ce3e44b2e242b84 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Guo Zeng <Guo.Zeng@csr.com> Cc: Barry Song <Baohua.Song@csr.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-6-sboyd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: actions: Don't reference clk_init_data after registrationStephen Boyd
[ Upstream commit cf9ec1fc6d7cceb73e7f1efd079d2eae173fdf57 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-2-sboyd@kernel.org [sboyd@kernel.org: Move name to after checking for error or NULL hw] Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sunxi-ng: v3s: add missing clock slices for MMC2 module clocksIcenowy Zheng
[ Upstream commit 720099603d1f62e37b789366d7e89824b009ca28 ] The MMC2 clock slices are currently not defined in V3s CCU driver, which makes MMC2 not working. Fix this issue. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: qoriq: Fix -Wunused-const-variableNathan Huckleberry
[ Upstream commit a95fb581b144b5e73da382eaedb2e32027610597 ] drivers/clk/clk-qoriq.c:138:38: warning: unused variable 'p5020_cmux_grp1' [-Wunused-const-variable] static const struct clockgen_muxinfo p5020_cmux_grp1 drivers/clk/clk-qoriq.c:146:38: warning: unused variable 'p5020_cmux_grp2' [-Wunused-const-variable] static const struct clockgen_muxinfo p5020_cmux_grp2 In the definition of the p5020 chip, the p2041 chip's info was used instead. The p5020 and p2041 chips have different info. This is most likely a typo. Link: https://github.com/ClangBuiltLinux/linux/issues/525 Cc: clang-built-linux@googlegroups.com Signed-off-by: Nathan Huckleberry <nhuck@google.com> Link: https://lkml.kernel.org/r/20190627220642.78575-1-nhuck@google.com Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Scott Wood <oss@buserror.net> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-19clk: rockchip: Don't yell about bad mmc phases when gettingDouglas Anderson
commit 6943b839721ad4a31ad2bacf6e71b21f2dfe3134 upstream. At boot time, my rk3288-veyron devices yell with 8 lines that look like this: [ 0.000000] rockchip_mmc_get_phase: invalid clk rate This is because the clock framework at clk_register() time tries to get the phase but we don't have a parent yet. While the errors appear to be harmless they are still ugly and, in general, we don't want yells like this in the log unless they are important. There's no real reason to be yelling here. We can still return -EINVAL to indicate that the phase makes no sense without a parent. If someone really tries to do tuning and the clock is reported as 0 then we'll see the yells in rockchip_mmc_set_phase(). Fixes: 4bf59902b500 ("clk: rockchip: Prevent calculating mmc phase if clock rate is zero") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-16clk: tegra210: Fix default rates for HDA clocksJon Hunter
[ Upstream commit 9caec6620f25b6d15646bbdb93062c872ba3b56f ] Currently the default clock rates for the HDA and HDA2CODEC_2X clocks are both 19.2MHz. However, the default rates for these clocks should actually be 51MHz and 48MHz, respectively. The current clock settings results in a distorted output during audio playback. Correct the default clock rates for these clocks by specifying them in the clock init table for Tegra210. Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-16clk: tegra: Fix maximum audio sync clock for Tegra124/210Jon Hunter
[ Upstream commit 845d782d91448e0fbca686bca2cc9f9c2a9ba3e7 ] The maximum frequency supported for I2S on Tegra124 and Tegra210 is 24.576MHz (as stated in the Tegra TK1 data sheet for Tegra124 and the Jetson TX1 module data sheet for Tegra210). However, the maximum I2S frequency is limited to 24MHz because that is the maximum frequency of the audio sync clock. Increase the maximum audio sync clock frequency to 24.576MHz for Tegra124 and Tegra210 in order to support 24.576MHz for I2S. Update the tegra_clk_register_sync_source() function so that it does not set the initial rate for the sync clocks and use the clock init tables to set the initial rate instead. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-16clk: s2mps11: Add used attribute to s2mps11_dt_matchNathan Chancellor
[ Upstream commit 9c940bbe2bb47e03ca5e937d30b6a50bf9c0e671 ] Clang warns after commit 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible"): drivers/clk/clk-s2mps11.c:242:34: warning: variable 's2mps11_dt_match' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const struct of_device_id s2mps11_dt_match[] = { ^ 1 warning generated. This warning happens when a variable is used in some construct that doesn't require a reference to that variable to be emitted in the symbol table; in this case, it's MODULE_DEVICE_TABLE, which only needs to hold the data of the variable, not the variable itself. $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_dt_match 00000078 000003d4 R __mod_of__s2mps11_dt_match_device_table Normally, with device ID table variables, it means that the variable just needs to be tied to the device declaration at the bottom of the file, like s2mps11_clk_id: $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_clk_id 00000000 00000078 R __mod_platform__s2mps11_clk_id_device_table 00000000 00000078 r s2mps11_clk_id However, because the comment above this deliberately doesn't want this variable added to .of_match_table, we need to mark s2mps11_dt_match as __used to silence this warning. This makes it clear to Clang that the variable is used for something, even if a reference to it isn't being emitted. Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Fixes: 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible") Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-29clk: socfpga: stratix10: fix rate caclulationg for cnt_clksDinh Nguyen
commit c7ec75ea4d5316518adc87224e3cff47192579e7 upstream. Checking bypass_reg is incorrect for calculating the cnt_clk rates. Instead we should be checking that there is a proper hardware register that holds the clock divider. Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Link: https://lkml.kernel.org/r/20190814153014.12962-1-dinguyen@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-25clk: renesas: cpg-mssr: Fix reset control race conditionGeert Uytterhoeven
[ Upstream commit e1f1ae8002e4b06addc52443fcd975bbf554ae92 ] The module reset code in the Renesas CPG/MSSR driver uses read-modify-write (RMW) operations to write to a Software Reset Register (SRCRn), and simple writes to write to a Software Reset Clearing Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware User's Manuals. However, this may cause a race condition when two devices are reset in parallel: if the reset for device A completes in the middle of the RMW operation for device B, device A may be reset again, causing subtle failures (e.g. i2c timeouts): thread A thread B -------- -------- val = SRCRn val |= bit A SRCRn = val delay val = SRCRn (bit A is set) SRSTCLRn = bit A (bit A in SRCRn is cleared) val |= bit B SRCRn = val (bit A and B are set) This can be reproduced on e.g. Salvator-XS using: $ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done & $ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done & i2c-rcar e6510000.i2c: error -110 : 40000002 i2c-rcar e66d8000.i2c: error -110 : 40000002 According to the R-Car Gen3 Hardware Manual Errata for Rev. 0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware User's Manual, writes to SRCRn do not require read-modify-write cycles. Note that the R-Car Gen2 Hardware User's Manual has not been updated yet, and still says a read-modify-write sequence is required. According to the hardware team, the reset hardware block is the same on both R-Car Gen2 and Gen3, though. Hence fix the issue by replacing the read-modify-write operations on SRCRn by simple writes. Reported-by: Yao Lihua <Lihua.Yao@desay-svautomotive.com> Fixes: 6197aa65c4905532 ("clk: renesas: cpg-mssr: Add support for reset control") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Linh Phung <linh.phung.jy@renesas.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-25clk: sprd: Select REGMAP_MMIO to avoid compile errorsChunyan Zhang
[ Upstream commit c9a67cbb5189e966c70451562b2ca4c3876ab546 ] Make REGMAP_MMIO selected to avoid undefined reference to regmap symbols. Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-25clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1Codrin Ciubotariu
[ Upstream commit 1573eebeaa8055777eb753f9b4d1cbe653380c38 ] In clk_generated_determine_rate(), if the divisor is greater than GENERATED_MAX_DIV + 1, then the wrong best_rate will be returned. If clk_generated_set_rate() will be called later with this wrong rate, it will return -EINVAL, so the generated clock won't change its value. Do no let the divisor be greater than GENERATED_MAX_DIV + 1. Fixes: 8c7aa6328947 ("clk: at91: clk-generated: remove useless divisor loop") Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-06clk: sprd: Add check for return value of sprd_clk_regmap_init()Chunyan Zhang
[ Upstream commit c974c48deeb969c5e4250e4f06af91edd84b1f10 ] sprd_clk_regmap_init() doesn't always return success, adding check for its return value should make the code more strong. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Reviewed-by: Baolin Wang <baolin.wang@linaro.org> [sboyd@kernel.org: Add a missing int ret] Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-06clk: tegra210: fix PLLU and PLLU_OUT1JC Kuo
[ Upstream commit 0d34dfbf3023cf119b83f6470692c0b10c832495 ] Full-speed and low-speed USB devices do not work with Tegra210 platforms because of incorrect PLLU/PLLU_OUT1 clock settings. When full-speed device is connected: [ 14.059886] usb 1-3: new full-speed USB device number 2 using tegra-xusb [ 14.196295] usb 1-3: device descriptor read/64, error -71 [ 14.436311] usb 1-3: device descriptor read/64, error -71 [ 14.675749] usb 1-3: new full-speed USB device number 3 using tegra-xusb [ 14.812335] usb 1-3: device descriptor read/64, error -71 [ 15.052316] usb 1-3: device descriptor read/64, error -71 [ 15.164799] usb usb1-port3: attempt power cycle When low-speed device is connected: [ 37.610949] usb usb1-port3: Cannot enable. Maybe the USB cable is bad? [ 38.557376] usb usb1-port3: Cannot enable. Maybe the USB cable is bad? [ 38.564977] usb usb1-port3: attempt power cycle This commit fixes the issue by: 1. initializing PLLU_OUT1 before initializing XUSB_FS_SRC clock because PLLU_OUT1 is parent of XUSB_FS_SRC. 2. changing PLLU post-divider to /2 (DIVP=1) according to Technical Reference Manual. Fixes: e745f992cf4b ("clk: tegra: Rework pll_u") Signed-off-by: JC Kuo <jckuo@nvidia.com> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-21clk: ti: clkctrl: Fix returning uninitialized dataTony Lindgren
[ Upstream commit 41b3588dba6ef4b7995735a97e47ff0aeea6c276 ] If we do a clk_get() for a clock that does not exists, we have _ti_omap4_clkctrl_xlate() return uninitialized data if no match is found. This can be seen in some cases with SLAB_DEBUG enabled: Unable to handle kernel paging request at virtual address 5a5a5a5a ... clk_hw_create_clk.part.33 sysc_notifier_call notifier_call_chain blocking_notifier_call_chain device_add Let's fix this by setting a found flag only when we find a match. Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Fixes: 88a172526c32 ("clk: ti: add support for clkctrl clocks") Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-03clk: socfpga: stratix10: fix divider entry for the emac clocksDinh Nguyen
commit 74684cce5ebd567b01e9bc0e9a1945c70a32f32f upstream. The fixed dividers for the emac clocks should be 2 not 4. Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-22clk: ti: clkctrl: Fix clkdm_clk handlingTony Lindgren
[ Upstream commit 1cc54078d104f5b4d7e9f8d55362efa5a8daffdb ] We need to always call clkdm_clk_enable() and clkdm_clk_disable() even the clkctrl clock(s) enabled for the domain do not have any gate register bits. Otherwise clockdomains may never get enabled except when devices get probed with the legacy "ti,hwmods" devicetree property. Fixes: 88a172526c32 ("clk: ti: add support for clkctrl clocks") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-15clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288Douglas Anderson
[ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ] Experimentally it can be seen that going into deep sleep (specifically setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1) appears to fail unless "aclk_dmac1" is on. The failure is that the system never signals that it made it into suspend on the GLOBAL_PWROFF pin and it just hangs. NOTE that it's confirmed that it's the actual suspend that fails, not one of the earlier calls to read/write registers. Specifically if you comment out the "PMU_GLOBAL_INT_DISABLE" setting in rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in rockchip_lpmode_enter() then you can exercise the whole suspend path without any crashing. This is currently not a problem with suspend upstream because there is no current way to exercise the deep suspend code. However, anyone trying to make it work will run into this issue. This was not a problem on shipping rk3288-based Chromebooks because those devices all ran on an old kernel based on 3.14. On that kernel "aclk_dmac1" appears to be left on all the time. There are several ways to skin this problem. A) We could add "aclk_dmac1" to the list of critical clocks and that apperas to work, but presumably that wastes power. B) We could keep a list of "struct clk" objects to enable at suspend time in clk-rk3288.c and use the standard clock APIs. C) We could make the rk3288-pmu driver keep a list of clocks to enable at suspend time. Presumably this would require a dts and bindings change. D) We could just whack the clock on in the existing syscore suspend function where we whack a bunch of other clocks. This is particularly easy because we know for sure that the clock's only parent ("aclk_cpu") is a critical clock so we don't need to do anything more than ungate it. In this case I have chosen D) because it seemed like the least work, but any of the other options would presumably also work fine. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31clk: rockchip: Make rkpwm a critical clock on rk3288Douglas Anderson
[ Upstream commit dfe7fb21cd9e730230d55a79bc72cf2ece67cdd5 ] Most rk3288-based boards are derived from the EVB and thus use a PWM regulator for the logic rail. However, most rk3288-based boards don't specify the PWM regulator in their device tree. We'll deal with that by making it critical. NOTE: it's important to make it critical and not just IGNORE_UNUSED because all PWMs in the system share the same clock. We don't want another PWM user to turn the clock on and off and kill the logic rail. This change is in preparation for actually having the PWMs in the rk3288 device tree actually point to the proper PWM clock. Up until now they've all pointed to the clock for the old IP block and they've all worked due to the fact that rkpwm was IGNORE_UNUSED and that the clock rates for both clocks were the same. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31clk: rockchip: Fix video codec clocks on rk3288Douglas Anderson
[ Upstream commit 00c0cd9e59d265b393553e9afa54fee8b10e8158 ] It appears that there is a typo in the rk3288 TRM. For GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's the other way around. How do I know? Here's my evidence: 1. Prior to commit 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec using the new muxgrf type on rk3288") we always pretended that we were using "aclk_vdpu" and the comment in the code said that this matched the default setting in the system. In fact the default setting is 0 according to the TRM and according to reading memory at bootup. In addition rk3288-based Chromebooks ran like this and the video codecs worked. 2. With the existing clock code if you boot up and try to enable the new VIDEO_ROCKCHIP_VPU as a module (and without "clk_ignore_unused" on the command line), you get errors like "failed to get ack on domain 'pd_video', val=0x80208". After flipping vepu/vdpu things init OK. 3. If I export and add both the vepu and vdpu to the list of clocks for RK3288_PD_VIDEO I can get past the power domain errors, but now I freeze when the vpu_mmu gets initted. 4. If I just mark the "vdpu" as IGNORE_UNUSED then everything boots up and probes OK showing that somehow the "vdpu" was important to keep enabled. This is because we were actually using it as a parent. 5. After this change I can hack "aclk_vcodec_pre" to parent from "aclk_vepu" using assigned-clocks and the video codec still probes OK. 6. Rockchip has said so on the mailing list [1]. ...so let's fix it. Let's also add CLK_SET_RATE_PARENT to "aclk_vcodec_pre" as suggested by Jonas Karlman. Prior to the same commit you could do clk_set_rate() on "aclk_vcodec" and it would change "aclk_vdpu". That's because "aclk_vcodec" was a simple gate clock (always gets CLK_SET_RATE_PARENT) and its direct parent was "aclk_vdpu". After that commit "aclk_vcodec_pre" gets in the way so we need to add CLK_SET_RATE_PARENT to it too. [1] https://lkml.kernel.org/r/1d17b015-9e17-34b9-baf8-c285dc1957aa@rock-chips.com Fixes: 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec using the new muxgrf type on rk3288") Suggested-by: Jonas Karlman <jonas@kwiboo.se> Suggested-by: Randy Li <ayaka@soulik.info> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31clk: rockchip: undo several noc and special clocks as critical on rk3288Douglas Anderson
[ Upstream commit f4033db5b84ebe4b32c25ba2ed65ab20b628996a ] This is mostly a revert of commit 55bb6a633c33 ("clk: rockchip: mark noc and some special clk as critical on rk3288") except that we're keeping "pmu_hclk_otg0" as critical still. NOTE: turning these clocks off doesn't seem to do a whole lot in terms of power savings (checking the power on the logic rail). It appears to save maybe 1-2mW. ...but still it seems like we should turn the clocks off if they aren't needed. About "pmu_hclk_otg0" (the one clock from the original commit we're still keeping critical) from an email thread: > pmu ahb clock > > Function: Clock to pmu module when hibernation and/or ADP is > enabled. Must be greater than or equal to 30 MHz. > > If the SOC design does not support hibernation/ADP function, only have > hclk_otg, this clk can be switched according to the usage of otg. > If the SOC design support hibernation/ADP, has two clocks, hclk_otg and > pmu_hclk_otg0. > Hclk_otg belongs to the closed part of otg logic, which can be switched > according to the use of otg. > > pmu_hclk_otg0 belongs to the always on part. > > As for whether pmu_hclk_otg0 can be turned off when otg is not in use, > we have not tested. IC suggest make pmu_hclk_otg0 always on. For the rest of the clocks: atclk: No documentation about this clock other than that it goes to the CPU. CPU functions fine without it on. Maybe needed for JTAG? jtag: Presumably this clock is only needed if you're debugging with JTAG. It doesn't seem like it makes sense to waste power for every rk3288 user. In any case to do JTAG you'd need private patches to adjust the pinctrl the mux the JTAG out anyway. pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two clocks on only during kernel panics in order to access some coresight registers. Since nothing in the upstream kernel does this we should be able to leave them off safely. Maybe also needed for JTAG? hsicphy12m_xin12m: There is no indication of why this clock would need to be turned on for boards that don't use HSIC. pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn these 4 clocks on only when doing DDR transitions and they are off otherwise. I see no reason why they'd need to be on in the upstream kernel which doesn't support DDRFreq. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-25clk: sunxi-ng: nkmp: Avoid GENMASK(-1, 0)Jernej Skrabec
[ Upstream commit 2abc330c514fe56c570bb1a6318b054b06a4f72e ] Sometimes one of the nkmp factors is unused. This means that one of the factors shift and width values are set to 0. Current nkmp clock code generates a mask for each factor with GENMASK(width + shift - 1, shift). For unused factor this translates to GENMASK(-1, 0). This code is further expanded by C preprocessor to final version: (((~0UL) - (1UL << (0)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (-1)))) or a bit simplified: (~0UL & (~0UL >> BITS_PER_LONG)) It turns out that result of the second part (~0UL >> BITS_PER_LONG) is actually undefined by C standard, which clearly specifies: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." Additionally, compiling kernel with aarch64-linux-gnu-gcc 8.3.0 gave different results whether literals or variables with same values as literals were used. GENMASK with literals -1 and 0 gives zero and with variables gives 0xFFFFFFFFFFFFFFF (~0UL). Because nkmp driver uses GENMASK with variables as parameter, expression calculates mask as ~0UL instead of 0. This has further consequences that LSB in register is always set to 1 (1 is neutral value for a factor and shift is 0). For example, H6 pll-de clock is set to 600 MHz by sun4i-drm driver, but due to this bug ends up being 300 MHz. Additionally, 300 MHz seems to be too low because following warning can be found in dmesg: [ 1.752763] WARNING: CPU: 2 PID: 41 at drivers/clk/sunxi-ng/ccu_common.c:41 ccu_helper_wait_for_lock.part.0+0x6c/0x90 [ 1.763378] Modules linked in: [ 1.766441] CPU: 2 PID: 41 Comm: kworker/2:1 Not tainted 5.1.0-rc2-next-20190401 #138 [ 1.774269] Hardware name: Pine H64 (DT) [ 1.778200] Workqueue: events deferred_probe_work_func [ 1.783341] pstate: 40000005 (nZcv daif -PAN -UAO) [ 1.788135] pc : ccu_helper_wait_for_lock.part.0+0x6c/0x90 [ 1.793623] lr : ccu_helper_wait_for_lock.part.0+0x48/0x90 [ 1.799107] sp : ffff000010f93840 [ 1.802422] x29: ffff000010f93840 x28: 0000000000000000 [ 1.807735] x27: ffff800073ce9d80 x26: ffff000010afd1b8 [ 1.813049] x25: ffffffffffffffff x24: 00000000ffffffff [ 1.818362] x23: 0000000000000001 x22: ffff000010abd5c8 [ 1.823675] x21: 0000000010000000 x20: 00000000685f367e [ 1.828987] x19: 0000000000001801 x18: 0000000000000001 [ 1.834300] x17: 0000000000000001 x16: 0000000000000000 [ 1.839613] x15: 0000000000000000 x14: ffff000010789858 [ 1.844926] x13: 0000000000000000 x12: 0000000000000001 [ 1.850239] x11: 0000000000000000 x10: 0000000000000970 [ 1.855551] x9 : ffff000010f936c0 x8 : ffff800074cec0d0 [ 1.860864] x7 : 0000800067117000 x6 : 0000000115c30b41 [ 1.866177] x5 : 00ffffffffffffff x4 : 002c959300bfe500 [ 1.871490] x3 : 0000000000000018 x2 : 0000000029aaaaab [ 1.876802] x1 : 00000000000002e6 x0 : 00000000686072bc [ 1.882114] Call trace: [ 1.884565] ccu_helper_wait_for_lock.part.0+0x6c/0x90 [ 1.889705] ccu_helper_wait_for_lock+0x10/0x20 [ 1.894236] ccu_nkmp_set_rate+0x244/0x2a8 [ 1.898334] clk_change_rate+0x144/0x290 [ 1.902258] clk_core_set_rate_nolock+0x180/0x1b8 [ 1.906963] clk_set_rate+0x34/0xa0 [ 1.910455] sun8i_mixer_bind+0x484/0x558 [ 1.914466] component_bind_all+0x10c/0x230 [ 1.918651] sun4i_drv_bind+0xc4/0x1a0 [ 1.922401] try_to_bring_up_master+0x164/0x1c0 [ 1.926932] __component_add+0xa0/0x168 [ 1.930769] component_add+0x10/0x18 [ 1.934346] sun8i_dw_hdmi_probe+0x18/0x20 [ 1.938443] platform_drv_probe+0x50/0xa0 [ 1.942455] really_probe+0xcc/0x280 [ 1.946032] driver_probe_device+0x54/0xe8 [ 1.950130] __device_attach_driver+0x80/0xb8 [ 1.954488] bus_for_each_drv+0x78/0xc8 [ 1.958326] __device_attach+0xd4/0x130 [ 1.962163] device_initial_probe+0x10/0x18 [ 1.966348] bus_probe_device+0x90/0x98 [ 1.970185] deferred_probe_work_func+0x6c/0xa0 [ 1.974720] process_one_work+0x1e0/0x320 [ 1.978732] worker_thread+0x228/0x428 [ 1.982484] kthread+0x120/0x128 [ 1.985714] ret_from_fork+0x10/0x18 [ 1.989290] ---[ end trace 9babd42e1ca4b84f ]--- This commit solves the issue by first checking value of the factor width. If it is equal to 0 (unused factor), mask is set to 0, otherwise GENMASK() macro is used as before. Fixes: d897ef56faf9 ("clk: sunxi-ng: Mask nkmp factors when setting register") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-25clk: rockchip: fix wrong clock definitions for rk3328Jonas Karlman
commit fb903392131a324a243c7731389277db1cd9f8df upstream. This patch fixes definition of several clock gate and select register that is wrong for rk3328 referring to the TRM and vendor kernel. Also use correct number of softrst registers. Fix clock definition for: - clk_crypto - aclk_h265 - pclk_h265 - aclk_h264 - hclk_h264 - aclk_axisram - aclk_gmac - aclk_usb3otg Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-25clk: mediatek: Disable tuner_en before change PLL rateOwen Chen
commit be17ca6ac76a5cfd07cc3a0397dd05d6929fcbbb upstream. PLLs with tuner_en bit, such as APLL1, need to disable tuner_en before apply new frequency settings, or the new frequency settings (pcw) will not be applied. The tuner_en bit will be disabled during changing PLL rate and be restored after new settings applied. Fixes: e2f744a82d725 (clk: mediatek: Add MT2712 clock support) Cc: <stable@vger.kernel.org> Signed-off-by: Owen Chen <owen.chen@mediatek.com> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com> Reviewed-by: James Liao <jamesjj.liao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-25clk: tegra: Fix PLLM programming on Tegra124+ when PMC overrides dividerDmitry Osipenko
commit 40db569d6769ffa3864fd1b89616b1a7323568a8 upstream. There are wrongly set parenthesis in the code that are resulting in a wrong configuration being programmed for PLLM. The original fix was made by Danny Huang in the downstream kernel. The patch was tested on Nyan Big Tegra124 chromebook, PLLM rate changing works correctly now and system doesn't lock up after changing the PLLM rate due to EMC scaling. Cc: <stable@vger.kernel.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-25clk: hi3660: Mark clk_gate_ufs_subsys as criticalLeo Yan
commit 9f77a60669d13ed4ddfa6cd7374c9d88da378ffa upstream. clk_gate_ufs_subsys is a system bus clock, turning off it will introduce lockup issue during system suspend flow. Let's mark clk_gate_ufs_subsys as critical clock, thus keeps it on during system suspend and resume. Fixes: d374e6fd5088 ("clk: hisilicon: Add clock driver for hi3660 SoC") Cc: stable@vger.kernel.org Cc: Zhong Kaihua <zhongkaihua@huawei.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Zhangfei Gao <zhangfei.gao@linaro.org> Suggested-by: Dong Zhang <zhangdong46@hisilicon.com> Signed-off-by: Leo Yan <leo.yan@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-10clk: meson-gxbb: round the vdec dividers to closestMaxime Jourdan
[ Upstream commit 9b70c697e87286ade406e6a02091757307dd4b7c ] We want the video decoder clocks to always round to closest. While the muxes are already using CLK_MUX_ROUND_CLOSEST, the corresponding CLK_DIVIDER_ROUND_CLOSEST was forgotten for the dividers. Fix this by adding the flag to the two vdec dividers. Fixes: a565242eb9fc ("clk: meson: gxbb: add the video decoder clocks") Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190319102537.2043-1-mjourdan@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-08clk: x86: Add system specific quirk to mark clocks as criticalDavid Müller
commit 7c2e07130090ae001a97a6b65597830d6815e93e upstream. Since commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are unconditionally gated off. Unfortunately this will break systems where these clocks are used for external purposes beyond the kernel's knowledge. Fix it by implementing a system specific quirk to mark the necessary pmc_plt_clks as critical. Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by: David Müller <dave.mueller@gmx.ch> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-08clk: qcom: Add missing freq for usb30_master_clk on 8998Jeffrey Hugo
commit 0c8ff62504e3a667387e87889a259632c3199a86 upstream. The usb30_master_clk supports a 60Mhz frequency, but that is missing from the table of supported frequencies. Add it. Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global Clock Control (GCC) driver) Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17Revert "clk: meson: clean-up clock registration"Neil Armstrong
This reverts commit c8e4f8406842332fb55cd792016e5dac266f6354. This patch was not initially a fix and is dependent on other changes which are not fixes eithers. With this change, multiple Amlogic based boards fails to boot, as reported by kernelci. Cc: stable@vger.kernel.org # 4.19.34 Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05clk: rockchip: fix frac settings of GPLL clock for rk3328Katsuhiro Suzuki
[ Upstream commit a0e447b0c50240a90ab84b7126b3c06b0bab4adc ] This patch fixes settings of GPLL frequency in fractional mode for rk3328. In this mode, FOUTVCO is calcurated by following formula: FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24) The problem is in FREF * FRAC >> 24 term. This result always lacks one from target value is specified by rate member. For example first itme of rk3328_pll_frac_rate originally has - rate : 1016064000 - refdiv: 3 - fbdiv : 127 - frac : 134217 - FREF * FBDIV / REFDIV = 1016000000 - (FREF * FRAC / REFDIV) >> 24 = 63999 Thus calculated rate is 1016063999. It seems wrong. If frac has 134218 (it is increased 1 from original value), second term is 64000. All other items have same situation. So this patch adds 1 to frac member in all items of rk3328_pll_frac_rate. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05clk: meson: clean-up clock registrationJerome Brunet
[ Upstream commit 8d9981efbcab066d17af4d3c85c169200f6f78df ] Order, ids and size between the table of regmap clocks and the onecell data table could be different. Set regmap pointer in all the regmap clocks before starting the registration using the onecell data, to make sure we don't get into an incoherent situation. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20181221160239.26265-3-jbrunet@baylibre.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05clk: fractional-divider: check parent rate only if flag is setKatsuhiro Suzuki
[ Upstream commit d13501a2bedfbea0983cc868d3f1dc692627f60d ] Custom approximation of fractional-divider may not need parent clock rate checking. For example Rockchip SoCs work fine using grand parent clock rate even if target rate is greater than parent. This patch checks parent clock rate only if CLK_SET_RATE_PARENT flag is set. For detailed example, clock tree of Rockchip I2S audio hardware. - Clock rate of CPLL is 1.2GHz, GPLL is 491.52MHz. - i2s1_div is integer divider can divide N (N is 1~128). Input clock is CPLL or GPLL. Initial divider value is N = 1. Ex) PLL = CPLL, N = 10, i2s1_div output rate is CPLL / 10 = 1.2GHz / 10 = 120MHz - i2s1_frac is fractional divider can divide input to x/y, x and y are 16bit integer. CPLL --> | selector | ---> i2s1_div -+--> | selector | --> I2S1 MCLK GPLL --> | | ,--------------' | | `--> i2s1_frac ---> | | Clock mux system try to choose suitable one from i2s1_div and i2s1_frac for master clock (MCLK) of I2S1. Bad scenario as follows: - Try to set MCLK to 8.192MHz (32kHz audio replay) Candidate setting is - i2s1_div: GPLL / 60 = 8.192MHz i2s1_div candidate is exactly same as target clock rate, so mux choose this clock source. i2s1_div output rate is changed 491.52MHz -> 8.192MHz - After that try to set to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div = 8.192MHz This is because clk_fd_round_rate() thinks target rate (11.2896MHz) is higher than parent rate (i2s1_div = 8.192MHz) and returns parent clock rate. Above is current upstreamed behavior. Clock mux system choose i2s1_div, but this clock rate is not acceptable for I2S driver, so users cannot replay audio. Expected behavior is: - Try to set master clock to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div * 147/6400 = 11.2896MHz Change i2s1_div to GPLL / 1 = 491.52MHz at same time. If apply this commit, clk_fd_round_rate() calls custom approximate function of Rockchip even if target rate is higher than parent. Custom function changes both grand parent (i2s1_div) and parent (i2s_frac) settings at same time. Clock mux system can choose i2s1_frac and audio works fine. Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Reviewed-by: Heiko Stuebner <heiko@sntech.de> [sboyd@kernel.org: Make function into a macro instead] Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23clk: ingenic: Fix doc of ingenic_cgu_div_infoPaul Cercueil
commit 7ca4c922aad2e3c46767a12f80d01c6b25337b59 upstream. The 'div' field does not represent a number of bits used to divide (understand: right-shift) the divider, but a number itself used to divide the divider. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Maarten ter Huurne <maarten@treewalker.org> Cc: <stable@vger.kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-23clk: ingenic: Fix round_rate misbehaving with non-integer dividersPaul Cercueil
commit bc5d922c93491878c44c9216e9d227c7eeb81d7f upstream. Take a parent rate of 180 MHz, and a requested rate of 4.285715 MHz. This results in a theorical divider of 41.999993 which is then rounded up to 42. The .round_rate function would then return (180 MHz / 42) as the clock, rounded down, so 4.285714 MHz. Calling clk_set_rate on 4.285714 MHz would round the rate again, and give a theorical divider of 42,0000028, now rounded up to 43, and the rate returned would be (180 MHz / 43) which is 4.186046 MHz, aka. not what we requested. Fix this by rounding up the divisions. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Tested-by: Maarten ter Huurne <maarten@treewalker.org> Cc: <stable@vger.kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-23clk: samsung: exynos5: Fix kfree() of const memory on setting driver_overrideKrzysztof Kozlowski
commit 785c9f411eb2d9a6076d3511c631587d5e676bf3 upstream. Platform driver driver_override field should not be initialized from const memory because the core later kfree() it. If driver_override is manually set later through sysfs, kfree() of old value leads to: $ echo "new_value" > /sys/bus/platform/drivers/.../driver_override kernel BUG at ../mm/slub.c:3960! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM ... (kfree) from [<c058e8c0>] (platform_set_driver_override+0x84/0xac) (platform_set_driver_override) from [<c058e908>] (driver_override_store+0x20/0x34) (driver_override_store) from [<c031f778>] (kernfs_fop_write+0x100/0x1dc) (kernfs_fop_write) from [<c0296de8>] (__vfs_write+0x2c/0x17c) (__vfs_write) from [<c02970c4>] (vfs_write+0xa4/0x188) (vfs_write) from [<c02972e8>] (ksys_write+0x4c/0xac) (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) The clk-exynos5-subcmu driver uses override only for the purpose of creating meaningful names for children devices (matching names of power domains, e.g. DISP, MFC). The driver_override was not developed for this purpose so just switch to default names of devices to fix the issue. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-23clk: samsung: exynos5: Fix possible NULL pointer exception on ↵Krzysztof Kozlowski
platform_device_alloc() failure commit 5f0b6216ea381b43c0dff88702d6cc5673d63922 upstream. During initialization of subdevices if platform_device_alloc() failed, returned NULL pointer will be later dereferenced. Add proper error paths to exynos5_clk_register_subcmu(). The return value of this function is still ignored because at this stage of init there is nothing we can do. Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>