summaryrefslogtreecommitdiff
path: root/drivers/clk
AgeCommit message (Collapse)Author
2022-09-30clk: baikal-t1: Move reset-controls code into a dedicated moduleSerge Semin
Before adding the directly controlled resets support it's reasonable to move the existing resets control functionality into a dedicated object for the sake of the CCU dividers clock driver simplification. After the new functionality was added clk-ccu-div.c would have got to a mixture of the weakly dependent clocks and resets methods. Splitting the methods up into the two objects will make the code easier to read and maintain. It shall also improve the code scalability (though hopefully we won't need this part that much in the future). The reset control functionality is now implemented in the framework of a single unit since splitting it up doesn't make much sense due to relatively simple reset operations. The ccu-rst.c has been designed to be looking like ccu-div.c or ccu-pll.c with two globally available methods for the sake of the code unification and better code readability. This commit doesn't provide any change in the CCU reset implementation semantics. As before the driver will support the trigger-like CCU resets only, which are responsible for the AXI-bus, APB-bus and SATA-ref blocks reset. The assert/de-assert-capable reset controls support will be added in the next commit. Note the CCU Clock dividers and resets functionality split up was possible due to not having any side-effects (at least we didn't found ones) of the regmap-based concurrent access of the common CCU dividers/reset CSRs. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20220929225402.9696-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: baikal-t1: Add SATA internal ref clock bufferSerge Semin
It turns out the internal SATA reference clock signal will stay unavailable for the SATA interface consumer until the buffer on it's way is ungated. So aside with having the actual clock divider enabled we need to ungate a buffer placed on the signal way to the SATA controller (most likely some rudiment from the initial SoC release). Seeing the switch flag is placed in the same register as the SATA-ref clock divider at a non-standard ffset, let's implement it as a separate clock controller with the set-rate propagation to the parental clock divider wrapper. As such we'll be able to disable/enable and still change the original clock source rate. Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20220929225402.9696-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: baikal-t1: Add shared xGMAC ref/ptp clocks internal parentSerge Semin
Baikal-T1 CCU reference manual says that both xGMAC reference and xGMAC PTP clocks are generated by two different wrappers with the same constant divider thus each producing a 156.25 MHz signal. But for some reason both of these clock sources are gated by a single switch-flag in the CCU registers space - CCU_SYS_XGMAC_BASE.BIT(0). In order to make the clocks handled independently we need to define a shared parental gate so the base clock signal would be switched off only if both of the child-clocks are disabled. Note the ID is intentionally set to -2 since we are going to add a one more internal clock identifier in the next commit. Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20220929225402.9696-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: baikal-t1: Fix invalid xGMAC PTP clock dividerSerge Semin
Most likely due to copy-paste mistake the divider has been set to 10 while according to the SoC reference manual it's supposed to be 8 thus having PTP clock frequency of 156.25 MHz. Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20220929225402.9696-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: vc5: Fix 5P49V6901 outputs disabling when enabling FODSerge Semin
We have discovered random glitches during the system boot up procedure. The problem investigation led us to the weird outcomes: when none of the Renesas 5P49V6901 ports are explicitly enabled by the kernel driver, the glitches disappeared. It was a mystery since the SoC external clock domains were fed with different 5P49V6901 outputs. The driver code didn't seem like bogus either. We almost despaired to find out a root cause when the solution has been found for a more modern revision of the chip. It turned out the 5P49V6901 clock generator stopped its output for a short period of time during the VC5_OUT_DIV_CONTROL register writing. The same problem was found for the 5P49V6965 revision of the chip and was successfully fixed in commit fc336ae622df ("clk: vc5: fix output disabling when enabling a FOD") by enabling the "bypass_sync" flag hidden inside "Unused Factory Reserved Register". Even though the 5P49V6901 registers description and programming guide doesn't provide any intel regarding that flag, setting it up anyway in the officially unused register completely eliminated the denoted glitches. Thus let's activate the functionality submitted in commit fc336ae622df ("clk: vc5: fix output disabling when enabling a FOD") for the Renesas 5P49V6901 chip too in order to remove the ports implicit inter-dependency. Fixes: dbf6b16f5683 ("clk: vc5: Add support for IDT VersaClock 5P49V6901") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Link: https://lore.kernel.org/r/20220929225402.9696-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: davinci: cfgchip: Use dev_err_probe() helperYang Yingliang
dev_err() can be replace with dev_err_probe() which will check if error code is -EPROBE_DEFER. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220913032228.985852-1-yangyingliang@huawei.com Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: davinci: pll: fix spelling typo in commentJiangshan Yi
Fix spelling typo in comment. Reported-by: k2ci <kernel-bot@kylinos.cn> Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Link: https://lore.kernel.org/r/20220905065833.1831473-1-13667453960@163.com Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: control shared SDH bits with separate clockDoug Brown
The PXA168 has a peculiar setup with the AXI clock enable control for the SDHC controllers. The bits in the SDH0 register control the AXI clock enable for both SDH0 and SDH1. Likewise, the bits in the SDH2 register control both SDH2 and SDH3. This is modeled with two new parentless clocks that control the shared bits. Previously, SDH0 had to be enabled in order for SDH1 to be used, and when SDH1 was enabled, unused bits in the SDH1 register were being controlled. This fixes those issues. A future commit will add support for these new shared clocks to be enabled by the PXA168 SDHC driver. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-13-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: add clocks for SDH2 and SDH3Doug Brown
The PXA168 has four SDHC peripherals. This commit adds the last two. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-11-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: fix GPIO clock enable bitsDoug Brown
According to the datasheet, only bit 0 of APBC_GPIO should be controlled for the clock enable. Bit 1 is marked as reserved (always write 0). Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-9-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: add muxes for more peripheralsDoug Brown
The TWSI, KPC, PWM, and DFC peripherals didn't have their muxes modeled in the code, but the PXA168 datasheet shows that they are indeed muxed: - TWSI can be 31.2 MHz or 62.4 MHz - KPC can be 32 kHz, 16 kHz, or 26 MHz - PWM can be 13 MHz or 32 kHz - DFC can be 156 MHz or 78 MHz Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-8-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: fix incorrect parent clocksDoug Brown
The UART, SDHC, LCD, and CCIC peripherals' muxed parent clocks didn't match the information provided by the PXA168 datasheet: - The UART clocks can be 58.5 MHz or the UART PLL. Previously, the first mux option was being calculated as 117 MHz, confirmed on hardware to be incorrect. - The SDHC clocks can be 48 MHz, 52 MHz, or 78 MHz. Previously, 48 MHz and 52 MHz were swapped. 78 MHz wasn't listed as an option. - The LCD clock can be 624 MHz or 312 Mhz. Previously, it was being calculated as 312 MHz or 52 MHz. - The CCIC clock can be 156 MHz or 78 MHz. Previously, it was being calculated as 312 MHz or 52 MHz. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-7-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: fix const-correctnessDoug Brown
While working on this series of patches, checkpatch recommended that an extra const should be added to the mux parent arrays. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-6-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: add new clocks for peripheralsDoug Brown
This commit adds three new clocks that previously didn't exist, but are needed in order to match the clock parenting as described in the PXA168 datasheet. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-5-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: fix incorrect dividersDoug Brown
These two clocks had multipliers and dividers that didn't match their names. A subsequent commit goes through all of the existing peripherals and ensure the correct clocks are being used everywhere. Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-3-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: mmp: pxa168: add additional register definesDoug Brown
In preparation for adding additional peripherals over time, this commit adds a bunch of extra APBC_* defines based on information from the datasheet. It also reorganizes the list of defines to be ordered sequentially by address (grouped by type). Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20220612192937.162952-2-doug@schmorgal.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30clk: sprd: Add clocks support for UMS512Cixi Geng
Add the list of clocks for the Unisoc UMS512, along with clock initialization. Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com> Link: https://lore.kernel.org/r/20220909152421.278662-3-gengcixi@gmail.com Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-30Merge branch 'acpi-dev'Rafael J. Wysocki
Merge changes regarding the management of ACPI device objects for 6.1-rc1: - Rename ACPI device object reference counting functions (Rafael Wysocki). - Rearrange ACPI device object initialization code (Rafael Wysocki). - Drop parent field from struct acpi_device (Rafael Wysocki). - Extend the the int3472-tps68470 driver to support multiple consumers of a single TPS68470 along with the requisite framework-level support (Daniel Scally). * acpi-dev: platform/x86: int3472: Add board data for Surface Go2 IR camera platform/x86: int3472: Support multiple gpio lookups in board data platform/x86: int3472: Support multiple clock consumers ACPI: bus: Add iterator for dependent devices ACPI: scan: Add acpi_dev_get_next_consumer_dev() ACPI: property: Use acpi_dev_parent() ACPI: Drop redundant acpi_dev_parent() header ACPI: PM: Fix NULL argument handling in acpi_device_get/set_power() ACPI: Drop parent field from struct acpi_device ACPI: scan: Eliminate __acpi_device_add() ACPI: scan: Rearrange initialization of ACPI device objects ACPI: scan: Rename acpi_bus_get_parent() and rearrange it ACPI: Rename acpi_bus_get/put_acpi_device()
2022-09-29clk: fixed-rate: add devm_clk_hw_register_fixed_rateDmitry Baryshkov
Add devm_clk_hw_register_fixed_rate(), devres-managed helper to register fixed-rate clock. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220916061740.87167-3-dmitry.baryshkov@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-29clk: asm9260: use parent index to link the reference clockDmitry Baryshkov
Rewrite clk-asm9260 to use parent index to use the reference clock. During this rework two helpers are added: - clk_hw_register_mux_table_parent_data() to supplement clk_hw_register_mux_table() but using parent_data instead of parent_names - clk_hw_register_fixed_rate_parent_accuracy() to be used instead of directly calling __clk_hw_register_fixed_rate(). The later function is an internal API, which is better not to be called directly. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220916061740.87167-2-dmitry.baryshkov@linaro.org Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-29clk: qcom: gcc-msm8939: use ARRAY_SIZE instead of specifying num_parentsDmitry Baryshkov
Use ARRAY_SIZE() instead of manually specifying num_parents. This makes adding/removing entries to/from parent_data easy and errorproof. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220928145609.375860-4-dmitry.baryshkov@linaro.org
2022-09-29clk: qcom: gcc-msm8939: use parent_hws where possibleDmitry Baryshkov
Use parent_hws instead of hanving parent_data with just a single .hw entry to speed up and simplify parent lookups. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220928145609.375860-3-dmitry.baryshkov@linaro.org
2022-09-29clk: qcom: gcc-sm6350: Update the .pwrsts for usb gdscsLuca Weiss
The USB controllers on sm6350 do not retain the state when the system goes into low power state and the GDSCs are turned off. This can be observed by the USB connection not coming back alive after putting the device into suspend, essentially breaking USB. Fix this by updating the .pwrsts for the USB GDSCs so they only transition to retention state in low power. Cc: Rajendra Nayak <quic_rjendra@quicinc.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220928132853.179425-1-luca.weiss@fairphone.com
2022-09-29clk: qcom: gcc-sc8280xp: use retention for USB power domainsJohan Hovold
Since commit d399723950c4 ("clk: qcom: gdsc: Fix the handling of PWRSTS_RET support) retention mode can be used on sc8280xp to maintain state during suspend instead of leaving the domain always on. This is needed to eventually allow the parent CX domain to be powered down during suspend. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220929161124.18138-1-johan+linaro@kernel.org
2022-09-29clk: qcom: gdsc: add missing error handlingJohan Hovold
Since commit 7eb231c337e0 ("PM / Domains: Convert pm_genpd_init() to return an error code") pm_genpd_init() can return an error which the caller must handle. The current error handling was also incomplete as the runtime PM and regulator use counts were not balanced in all error paths. Add the missing error handling to the GDSC initialisation to avoid continuing as if nothing happened on errors. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220929155816.17425-1-johan+linaro@kernel.org
2022-09-29clk: mediatek: mt8192: deduplicate parent clock listsChen-Yu Tsai
Some groups of clocks of the same type share the same list of parents. These lists were declared separately for each clock in older drivers, bloating the code. Merge some obvious duplicate parent clock lists in the MT8192 clock driver together to reduce the code size. These include: - apll_i2s*_m_parents into one as apll_i2s_m_parents - img1_parents & img2_parents into one as img_parents - msdc30_*_parents into one as msdc30_parents - camtg*_parents into cam_tg_parents - seninf*_parents into seninf_parents Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220926102523.2367530-6-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: Migrate remaining clk_unregister_*() to clk_hw_unregister_*()Chen-Yu Tsai
During the previous |struct clk| to |struct clk_hw| clk provider API migration in commit 6f691a586296 ("clk: mediatek: Switch to clk_hw provider APIs"), a few clk_unregister_*() calls were missed. Migrate the remaining ones to the |struct clk_hw| provider API, i.e. change clk_unregister_*() to clk_hw_unregister_*(). Fixes: 6f691a586296 ("clk: mediatek: Switch to clk_hw provider APIs") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220926102523.2367530-3-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: fix unregister function in mtk_clk_register_dividers cleanupChen-Yu Tsai
When the cleanup paths for the various clk register APIs in the MediaTek clk library were added, the one in the dividers type used the wrong type of unregister function. This would result in incorrect dereferencing of the clk pointer and freeing of invalid pointers. Fix this by switching to the correct type of clk unregistration call. Fixes: 3c3ba2ab0226 ("clk: mediatek: mtk: Implement error handling in register APIs") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220926102523.2367530-2-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: clk-mt8192: Add clock mux notifier for mfg_pll_selAngeloGioacchino Del Regno
Following the changes that were done for mt8183, add a clock notifier for the GPU PLL selector mux: this allows safe clock rate changes by temporarily reparenting the GPU to a safe clock (clk26m) while the MFGPLL is reprogrammed and stabilizes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20220927101128.44758-11-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: clk-mt8192-mfg: Propagate rate changes to parentAngeloGioacchino Del Regno
Following what was done on MT8183 and MT8195, also propagate the rate changes to MFG_BG3D's parent on MT8192 to allow for proper GPU DVFS. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20220927101128.44758-10-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: clk-mt8195-topckgen: Drop univplls from mfg mux parentsAngeloGioacchino Del Regno
These PLLs are conflicting with GPU rates that can be generated by the GPU-dedicated MFGPLL and would require a special clock handler to be used, for very little and ignorable power consumption benefits. Also, we're in any case unable to set the rate of these PLLs to something else that is sensible for this task, so simply drop them: this will make the GPU to be clocked exclusively from MFGPLL for "fast" rates, while still achieving the right "safe" rate during PLL frequency locking. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20220927101128.44758-9-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: clk-mt8195-topckgen: Add GPU clock mux notifierAngeloGioacchino Del Regno
Following the changes done to MT8183, register a similar notifier for MT8195 as well, allowing safe clockrate updates for the MFGPLL. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Miles Chen <miles.chen@mediatek.com> Link: https://lore.kernel.org/r/20220927101128.44758-8-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: clk-mt8195-topckgen: Register mfg_ck_fast_ref as generic muxAngeloGioacchino Del Regno
This clock was being registered as clk-composite through the helpers for the same in the MediaTek clock APIs but, in reality, this isn't a composite clock. Appropriately register this clock with devm_clk_hw_register_mux(). No functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20220927101128.44758-7-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: clk-mt8195-mfg: Reparent mfg_bg3d and propagate rate changesAngeloGioacchino Del Regno
The MFG_BG3D is a gate to enable/disable clock output to the GPU, but the actual output is decided by multiple muxes; in particular: mfg_ck_fast_ref muxes between "slow" (top_mfg_core_tmp) and "fast" (MFGPLL) clock, while top_mfg_core_tmp muxes between the 26MHz clock and various system PLLs. The clock gate comes after all the muxes, so its parent is mfg_ck_fast_reg, not top_mfg_core_tmp. Reparent MFG_BG3D to the latter to match the hardware and add the CLK_SET_RATE_PARENT flag to it: this way we ensure propagating rate changes that are requested on MFG_BG3D along its entire clock tree. Fixes: 35016f10c0e5 ("clk: mediatek: Add MT8195 mfgcfg clock support") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20220927101128.44758-6-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: mt8183: Add clk mux notifier for MFG muxChen-Yu Tsai
When the MFG PLL clock, which is upstream of the MFG clock, is changed, the downstream clock and consumers need to be switched away from the PLL over to a stable clock to avoid glitches. This is done through the use of the newly added clk mux notifier. The notifier is set on the mux itself instead of the upstream PLL, but in practice this works, as the rate change notifitcations are propogated throughout the sub-tree hanging off the PLL. Just before rate changes, the MFG mux is temporarily and transparently switched to the 26 MHz main crystal. After the rate change, the mux is switched back. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [Angelo: Rebased to assign clk_ops in mtk_mux_nb] Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Miles Chen <miles.chen@mediatek.com> Link: https://lore.kernel.org/r/20220927101128.44758-5-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: mux: add clk notifier functionsChen-Yu Tsai
With device frequency scaling, the mux clock that (indirectly) feeds the device selects between a dedicated PLL, and some other stable clocks. When a clk rate change is requested, the (normally) upstream PLL is reconfigured. It's possible for the clock output of the PLL to become unstable during this process. To avoid causing the device to glitch, the mux should temporarily be switched over to another "stable" clock during the PLL rate change. This is done with clk notifiers. This patch adds common functions for notifiers to temporarily and transparently reparent mux clocks. This was loosely based on commit 8adfb08605a9 ("clk: sunxi-ng: mux: Add clk notifier functions"). Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [Angelo: Changed mtk_mux_nb to hold a pointer to clk_ops instead of mtk_mux] Co-developed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Miles Chen <miles.chen@mediatek.com> Link: https://lore.kernel.org/r/20220927101128.44758-4-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-29clk: mediatek: mt8183: mfgcfg: Propagate rate changes to parentChen-Yu Tsai
The only clock in the MT8183 MFGCFG block feeds the GPU. Propagate its rate change requests to its parent, so that DVFS for the GPU can work properly. Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220927101128.44758-3-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2022-09-28clk: imx93: drop of_match_ptrPeng Fan
There is build warning when CONFIG_OF is not selected. >> drivers/clk/imx/clk-imx93.c:324:34: warning: 'imx93_clk_of_match' >> defined but not used [-Wunused-const-variable=] 324 | static const struct of_device_id imx93_clk_of_match[] = { | ^~~~~~~~~~~~~~~~~~ The driver only support DT table, no sense to use of_match_ptr. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220830033137.4149542-3-peng.fan@oss.nxp.com Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-28clk: pistachio: Fix initconst confusionAndi Kleen
A variable pointing to const isn't const itself. It has to contain "const" keyword after "*" too. So to keep it in __initconst (and not mark properly as __initdata), add the "const" keyword exactly there. Note we need to update struct pistachio_mux too. On the other hand, the clk core already counts with "const char *const" already. [js] more explanatory commit message. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Cc: Martin Liska <mliska@suse.cz> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220920055838.22637-1-jslaby@suse.cz Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-28clk: iproc: Do not rely on node name for correct PLL setupFlorian Fainelli
After commit 31fd9b79dc58 ("ARM: dts: BCM5301X: update CRU block description") a warning from clk-iproc-pll.c was generated due to a duplicate PLL name as well as the console stopped working. Upon closer inspection it became clear that iproc_pll_clk_setup() used the Device Tree node unit name as an unique identifier as well as a parent name to parent all clocks under the PLL. BCM5301X was the first platform on which that got noticed because of the DT node unit name renaming but the same assumptions hold true for any user of the iproc_pll_clk_setup() function. The first 'clock-output-names' property is always guaranteed to be unique as well as providing the actual desired PLL clock name, so we utilize that to register the PLL and as a parent name of all children clock. Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-28clk: clk-npcm7xx: Remove unused struct npcm7xx_clk_gate_data and ↵Yuan Can
npcm7xx_clk_div_fixed_data After commit 6a5898411159("clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates' and 'npcm7xx_divs_fx'"), no one use struct npcm7xx_clk_gate_data and struct npcm7xx_clk_div_fixed_data, so remove them. Signed-off-by: Yuan Can <yuancan@huawei.com> Link: https://lore.kernel.org/r/20220927133931.104060-1-yuancan@huawei.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-28clk: sunxi-ng: h6: Fix default PLL GPU rateJernej Skrabec
In commit 4167ac8a657e ("clk: sunxi-ng: sun50i: h6: Modify GPU clock configuration to support DFS") divider M0 was forced to be 1 in order to support DFS. However, that left N as it is, at high value of 36. On boards without devfreq enabled (all of them in kernel 6.0), this effectively sets GPU frequency to 864 MHz. This is about 100 MHz above maximum supported frequency. In order to fix this, let's set N to 18 (register value 17). That way default frequency of 432 MHz is preserved. Fixes: 4167ac8a657e ("clk: sunxi-ng: sun50i: h6: Modify GPU clock configuration to support DFS") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220928200122.3963509-1-jernej.skrabec@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-28clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocksHan Xu
There is no dedicate parent clock for QSPI so SET_RATE_PARENT flag should not be used. For instance, the default parent clock for QSPI is pll2_bus, which is also the parent clock for quite a few modules, such as MMDC, once GPMI NAND set clock rate for EDO5 mode can cause system hang due to pll2_bus rate changed. Fixes: f1541e15e38e ("clk: imx6sx: Switch to clk_hw based API") Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20220915150959.3646702-1-han.xu@nxp.com Tested-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-09-28Merge tag 'clk-microchip-fixes-6.0' of ↵Stephen Boyd
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-fixes Pull Microchip clock fixes for Polarfire SoCs: - fix panic at boot in clock initialization when building with clang-15 - make RTC's AHB clock critical as rtc will stop if the AHB interface clock is disabled * tag 'clk-microchip-fixes-6.0' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: clk: microchip: mpfs: make the rtc's ahb clock critical clk: microchip: mpfs: fix clk_cfg array bounds violation
2022-09-27clk: qcom: Add global clock controller driver for SM6375Konrad Dybcio
Add support for the global clock controller found on SM6375. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220921001303.56151-3-konrad.dybcio@somainline.org
2022-09-27clk: qcom: alpha: Add support for programming the PLL_FSM_LEGACY_MODE bitKonrad Dybcio
This is used on at least SM6375 and its variations. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220921001303.56151-1-konrad.dybcio@somainline.org
2022-09-27clk: qcom: gcc-sc7280: Update the .pwrsts for usb gdscsRajendra Nayak
The USB controllers on sc7280 do not retain the state when the system goes into low power state and the GDSCs are turned off. This results in the controllers reinitializing and re-enumerating all the connected devices (resulting in additional delay while coming out of suspend) Fix this by updating the .pwrsts for the USB GDSCs so they only transition to retention state in low power. Since sc7280 only supports cx (parent of usb gdscs) Retention, there are no cxcs offsets mentioned in order to support the Retention state. Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220920111517.10407-3-quic_rjendra@quicinc.com
2022-09-27clk: qcom: gcc-sc7180: Update the .pwrsts for usb gdscRajendra Nayak
The USB controller on sc7180 does not retain the state when the system goes into low power state and the GDSC is turned off. This results in the controller reinitializing and re-enumerating all the connected devices (resulting in additional delay while coming out of suspend) Fix this by updating the .pwrsts for the USB GDSC so it only transitions to retention state in low power. Since sc7180 only supports cx (parent of usb gdsc) Retention, there are no cxcs offsets mentioned in order to support the Retention state. Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220920111517.10407-2-quic_rjendra@quicinc.com
2022-09-27clk: qcom: gdsc: Fix the handling of PWRSTS_RET supportRajendra Nayak
GDSCs cannot be transitioned into a Retention state in SW. When either the RETAIN_MEM bit, or both the RETAIN_MEM and RETAIN_PERIPH bits are set, and the GDSC is left ON, the HW takes care of retaining the memory/logic for the domain when the parent domain transitions to power collapse/power off state. On some platforms where the parent domains lowest power state itself is Retention, just leaving the GDSC in ON (without any RETAIN_MEM/RETAIN_PERIPH bits being set) will also transition it to Retention. The existing logic handling the PWRSTS_RET seems to set the RETAIN_MEM/RETAIN_PERIPH bits if the cxcs offsets are specified but then explicitly turns the GDSC OFF as part of _gdsc_disable(). Fix that by leaving the GDSC in ON state. Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220920111517.10407-1-quic_rjendra@quicinc.com
2022-09-27clk: qcom: Add SC8280XP GPU clock controllerBjorn Andersson
Add driver for the GPU clock controller in the Qualcomm SC8280XP platform. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> [bjorn: Included kernel.h and lower-cased hex numbers] Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220926173025.4747-3-quic_bjorande@quicinc.com
generated by cgit (git 2.34.1) at 2025-09-11 08:50:38 +0000