Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read. Ternary
operator has three arguments and with wrapping might lead to quite
long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
file.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250114190612.846696-1-krzysztof.kozlowski@linaro.org
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Commit 99c21c7ca6 ("clk: qcom: Add X1P42100 GPUCC driver") adds the
config definition CLK_X1P42100_GPUCC. This config definition selects the
non-existing config CLK_X1E8010_GCC. Note that the config for the X1E80100
Global Clock Controller is CLK_X1E80100_GCC.
Assuming this was just a minor typo in the number, i.e., 8010 instead of
80100, change the definition to select the existing config
CLK_X1E80100_GCC, similarly to the definitions for three configs
CLK_X1E80100_{CAMCC,DISPCC,GPUCC}.
Fixes: 99c21c7ca6 ("clk: qcom: Add X1P42100 GPUCC driver")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Link: https://lore.kernel.org/r/20250107104728.23098-1-lukas.bulwahn@redhat.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Similar to the earlier fixes meant for sm8x50 and x1e platforms,
we have to stop using the shared clk ops for sdm845 QUPs as well.
As Stephen Boyd pointed out in earlier fixes, there wasn't a problem
to mark QUP clks shared until we started parking shared RCGs at clk
registration time in commit 01a0a6cc8c ("clk: qcom: Park shared RCGs
upon registration"). Parking at init is actually harmful to the UART
when earlycon is used. If the device is pumping out data while the
frequency changes and we see garbage on the serial console until the
driver can probe and actually set a proper frequency.
This patch reverts the QUP clk sharing ops part of commit 06391eddb6
("clk: qcom: Add Global Clock controller (GCC) driver for SDM845"), so
that the QUPs on sdm845 don't get parked during clk registration and
break UART operations.
Fixes: 01a0a6cc8c ("clk: qcom: Park shared RCGs upon registration")
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Link: https://lore.kernel.org/r/20241209174912.2526928-1-amit.pundir@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
SDM845 has "General Purpose" clocks that can be muxed to
SoC pins to clock various external devices.
Those clocks may be used as e.g. PWM sources for external peripherals.
GPCLK can in theory have arbitrary value depending on the use case, so
the concept of frequency tables, used in rcg2 clock driver, is not
efficient, because it allows only defined frequencies.
Introduce clk_rcg2_gp_ops, which automatically calculate clock
mnd values for arbitrary clock rate. The calculation done as follows:
- upon determine rate request, we calculate m/n/pre_div as follows:
- find parent(from our client's assigned-clock-parent) rate
- find scaled rates by dividing rates on its greatest common divisor
- assign requested scaled rate to m
- factorize scaled parent rate, put multipliers to n till max value
(determined by mnd_width)
- validate calculated values with *_width:
- if doesn't fit, delete divisor and multiplier by 2 until fit
- return determined rate
Limitations:
- The driver doesn't select a parent clock (it may be selected by client
in device tree with assigned-clocks, assigned-clock-parents properties)
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Link: https://lore.kernel.org/r/20241118-starqltechn_integration_upstream-v8-3-ac8e36a3aa65@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
__clk_rcg2_configure function does 2 things -
configures parent and mnd values. In order to
be able to add new clock options, we should split.
Move __clk_rcg2_configure logic on 2 functions:
- __clk_rcg2_configure_parent which configures clock parent
- __clk_rcg2_configure_mnd which configures mnd values
__clk_rcg2_configure delegates to mentioned functions.
Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com>
Link: https://lore.kernel.org/r/20241118-starqltechn_integration_upstream-v8-2-ac8e36a3aa65@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
On APQ8064 the DSI2_PIXEL_SRC clock can be used either to drive the
second DSI host or to drive the LCDC controller. Add LVDS PLL as
possible source to the clock and LVDS output clock. The DSI2_PIXEL_SRC
clock has separate path to be used for the LVDS clock. To represent
both DSI and LVDS clocks properly, add intermediate clock which toggles
the enable bit and make DSI2_PIXEL_CLK clock just check for the HALT
bit.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20241224-apq8064-fix-mmcc-v1-4-c95d2e2bf143@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The CMN PLL clock controller supplies clocks to the hardware
blocks that together make up the Ethernet function on Qualcomm
IPQ SoCs and to GCC. The driver is initially supported for
IPQ9574 SoC.
The CMN PLL clock controller expects a reference input clock
from the on-board Wi-Fi block acting as clock source. The input
reference clock needs to be configured to one of the supported
clock rates.
The controller supplies a number of fixed-rate output clocks.
For the IPQ9574, there is one output clock of 353 MHZ to PPE
(Packet Process Engine) hardware block, three 50 MHZ output
clocks and an additional 25 MHZ output clock supplied to the
connected Ethernet devices. The PLL also supplies a 24 MHZ
clock as XO and a 32 KHZ sleep clock to GCC, and one 31.25
MHZ clock to PCS.
Signed-off-by: Luo Jie <quic_luoj@quicinc.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250103-qcom_ipq_cmnpll-v8-2-c89fb4d4849d@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for Pongo type of PLL clocks, used in Qualcomm SM8750 SoC.
Notable difference comparing to other PLLs is the need for calibration
for internally generated clock followed by wait_for_pll(). This is done
in configure call and at this time clocks are not yet registered, thus
wait_for_pll() cannot use clk_hw_get_name. Locking during this
calibration requires much more time, thus increase the timeout in
wait_for_pll().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250106-sm8750-dispcc-v2-2-6f42beda6317@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Commit c45ae598fc ("clk: qcom: support for alpha mode configuration")
added support for configuring alpha mode, but it seems that the feature
was never working in practice.
The value of the alpha_{en,mode}_mask members of the configuration gets
added to the value parameter passed to the regmap_update_bits() function,
however the same values are not getting applied to the bitmask. As the
result, the respective bits in the USER_CTL register are never modifed
which leads to improper configuration of several PLLs.
The following table shows the PLL configurations where the 'alpha_en_mask'
member is set and which are passed as a parameter for the
clk_alpha_pll_configure() function. In the table the 'expected rate' column
shows the rate the PLL should run at with the given configuration, and
the 'real rate' column shows the rate the PLL runs at actually. The real
rates has been verified on hardwareOn IPQ* platforms, on other platforms,
those are computed values only.
file pll expected rate real rate
dispcc-qcm2290.c disp_cc_pll0 768.0 MHz 768.0 MHz
dispcc-sm6115.c disp_cc_pll0 768.0 MHz 768.0 MHz
gcc-ipq5018.c ubi32_pll 1000.0 MHz != 984.0 MHz
gcc-ipq6018.c nss_crypto_pll 1200.0 MHz 1200.0 MHz
gcc-ipq6018.c ubi32_pll 1497.6 MHz != 1488.0 MHz
gcc-ipq8074.c nss_crypto_pll 1200.0 MHz != 1190.4 MHz
gcc-qcm2290.c gpll11 532.0 MHz != 518.4 MHz
gcc-qcm2290.c gpll8 533.2 MHz != 518.4 MHz
gcc-qcs404.c gpll3 921.6 MHz 921.6 MHz
gcc-sm6115.c gpll11 600.0 MHz != 595.2 MHz
gcc-sm6115.c gpll8 800.0 MHz != 787.2 MHz
gpucc-sdm660.c gpu_cc_pll0 800.0 MHz != 787.2 MHz
gpucc-sdm660.c gpu_cc_pll1 740.0 MHz != 729.6 MHz
gpucc-sm6115.c gpu_cc_pll0 1200.0 MHz != 1190.4 MHz
gpucc-sm6115.c gpu_cc_pll1 640.0 MHz != 633.6 MHz
gpucc-sm6125.c gpu_pll0 1020.0 MHz != 1017.6 MHz
gpucc-sm6125.c gpu_pll1 930.0 MHz != 921.6 MHz
mmcc-sdm660.c mmpll8 930.0 MHz != 921.6 MHz
mmcc-sdm660.c mmpll5 825.0 MHz != 806.4 MHz
As it can be seen from the above, there are several PLLs which are
configured incorrectly.
Change the code to apply both 'alpha_en_mask' and 'alpha_mode_mask'
values to the bitmask in order to configure the alpha mode correctly.
Applying the 'alpha_en_mask' fixes the initial rate of the PLLs showed
in the table above. Since the 'alpha_mode_mask' is not used by any driver
currently, that part of the change causes no functional changes.
Cc: stable@vger.kernel.org
Fixes: c45ae598fc ("clk: qcom: support for alpha mode configuration")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20241021-fix-alpha-mode-config-v1-1-f32c254e02bc@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since both the 'alpha' and 'alpha_hi' members of the configuration is
initialized (the latter is implicitly) with zero values, the output
rate of the PLL will be the same whether alpha mode is enabled or not.
Remove the initialization of the alpha* members to make it clear that
the alpha mode is not required to get the desired output rate.
Despite that enabling alpha mode is not needed for the initial
configuration, the set_rate() op might require that it is enabled
already. In this particular case however, the clk_alpha_pll_set_rate()
function will get reset the ALPHA_EN bit when the PLL's rate changes,
so dropping 'alpha_en_mask' is safe.
No functional changes intended, compile tested only.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20241028-alpha-mode-cleanup-v2-5-9bc6d712bd76@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since both the 'alpha' and 'alpha_hi' members of the configuration is
initialized (the latter is implicitly) with zero values, the output
rate of the PLL will be the same whether alpha mode is enabled or not.
Remove the initialization of the alpha* members to make it clear that
the alpha mode is not required to get the desired output rate.
Despite that enabling alpha mode is not needed for the initial
configuration, the set_rate() op might require that it is enabled
already. In this particular case however, the clk_alpha_pll_set_rate()
function will get reset the ALPHA_EN bit when the PLL's rate changes,
so dropping 'alpha_en_mask' is safe.
No functional changes intended, compile tested only.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20241028-alpha-mode-cleanup-v2-4-9bc6d712bd76@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since both the 'alpha' and 'alpha_hi' members of the configuration is
initialized with zero values, the output rate of the PLL will be the
same whether alpha mode is enabled or not.
Remove the initialization of the alpha* members to make it clear that
alpha mode is not required to get the desired output rate.
Despite that enabling alpha mode is not needed for the initial
configuration, the set_rate() op might require that it is enabled
already. In this particular case however, the clk_alpha_pll_set_rate()
function will get reset the ALPHA_EN bit when the PLL's rate changes,
so dropping 'alpha_en_mask' is safe.
While at it, also add a comment to indicate the frequency the PLL runs
at with the current configuration.
No functional changes, the PLL runs at 1.2 GHz both before and after
the change.
Tested on Xiaomi Mi Router AX1800 (IPQ6018, out-of-tree board).
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20241028-alpha-mode-cleanup-v2-3-9bc6d712bd76@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since neither 'alpha' nor 'alpha_hi' is defined in the configuration,
those will be initialized with zero values implicitly. By using zero
alpha values, the output rate of the PLL will be the same whether
alpha mode is enabled or not.
Remove the superfluous initialization of the 'alpha_en_mask' member
to make it clear that enabling alpha mode is not required to get the
desired output rate.
Despite that enabling alpha mode is not needed for the initial
configuration, the set_rate() op might require that it is enabled
already. In this particular case however, the
clk_alpha_pll_stromer_plus_set_rate() function will get reset the
ALPHA_EN bit when the PLL's rate changes, so dropping 'alpha_en_mask'
is safe.
While at it, also add a comment to indicate the frequency the PLL
runs at with the current configuration.
No functional changes, the initial rate of the PLL is the same both
before and after the patch.
Tested on Xiaomi Router BE3600 2.5G (IPQ5312, out-of-tree board).
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20241028-alpha-mode-cleanup-v2-2-9bc6d712bd76@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since neither 'alpha' nor 'alpha_hi' is defined in the configuration,
those will be initialized with zero values implicitly. By using zero
alpha values, the output rate of the PLL will be the same whether
alpha mode is enabled or not.
Remove the superfluous initialization of the 'alpha_en_mask' member
to make it clear that enabling alpha mode is not required to get the
desired output rate.
Despite that enabling alpha mode is not needed for the initial
configuration, the set_rate() op might require that it is enabled
already. In this particular case however, the
clk_alpha_pll_stromer_set_rate() function will get reset the
ALPHA_EN bit when the PLL's rate changes, so dropping 'alpha_en_mask'
is safe.
No functional changes, the initial rate of the PLL is the same both
before and after the patch.
Tested on TP-Link Archer AX55 v1 (IPQ5018).
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20241028-alpha-mode-cleanup-v2-1-9bc6d712bd76@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
If a clk_rcg2 has a parent, it should also have parent_map defined,
otherwise we'll get a NULL pointer dereference when calling clk_set_rate
like the following:
[ 3.388105] Call trace:
[ 3.390664] qcom_find_src_index+0x3c/0x70 (P)
[ 3.395301] qcom_find_src_index+0x1c/0x70 (L)
[ 3.399934] _freq_tbl_determine_rate+0x48/0x100
[ 3.404753] clk_rcg2_determine_rate+0x1c/0x28
[ 3.409387] clk_core_determine_round_nolock+0x58/0xe4
[ 3.421414] clk_core_round_rate_nolock+0x48/0xfc
[ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc
[ 3.444483] clk_core_set_rate_nolock+0x8c/0x300
[ 3.455886] clk_set_rate+0x38/0x14c
Add the parent_map property for the clock where it's missing and also
un-inline the parent_data as well to keep the matching parent_map and
parent_data together.
Fixes: 837519775f ("clk: qcom: Add display clock controller driver for SM6350")
Cc: stable@vger.kernel.org
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20241220-sm6350-parent_map-v1-2-64f3d04cb2eb@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
If a clk_rcg2 has a parent, it should also have parent_map defined,
otherwise we'll get a NULL pointer dereference when calling clk_set_rate
like the following:
[ 3.388105] Call trace:
[ 3.390664] qcom_find_src_index+0x3c/0x70 (P)
[ 3.395301] qcom_find_src_index+0x1c/0x70 (L)
[ 3.399934] _freq_tbl_determine_rate+0x48/0x100
[ 3.404753] clk_rcg2_determine_rate+0x1c/0x28
[ 3.409387] clk_core_determine_round_nolock+0x58/0xe4
[ 3.421414] clk_core_round_rate_nolock+0x48/0xfc
[ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc
[ 3.444483] clk_core_set_rate_nolock+0x8c/0x300
[ 3.455886] clk_set_rate+0x38/0x14c
Add the parent_map property for two clocks where it's missing and also
un-inline the parent_data as well to keep the matching parent_map and
parent_data together.
Fixes: 131abae905 ("clk: qcom: Add SM6350 GCC driver")
Cc: stable@vger.kernel.org
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20241220-sm6350-parent_map-v1-1-64f3d04cb2eb@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Pull clk updates from Stephen Boyd:
"The core framework gained a clk provider helper, a clk consumer
helper, and some unit tests for the assigned clk rates feature in
DeviceTree. On the vendor driver side, we gained a whole pile of SoC
driver support detailed below. The majority in the diffstat is
Qualcomm, but there's also quite a few Samsung and Mediatek clk driver
additions in here as well. The top vendors is quite common, but the
sheer amount of new drivers is uncommon, so I'm anticipating a larger
number of fixes for clk drivers this cycle.
Core:
- devm_clk_bulk_get_all_enabled() to return number of clks acquired
- devm_clk_hw_register_gate_parent_hw() helper to modernize drivers
- KUnit tests for clk-assigned-rates{,-u64}
New Drivers:
- Marvell PXA1908 SoC clks
- Mobileye EyeQ5, EyeQ6L and EyeQ6H clk driver
- TWL6030 clk driver
- Nuvoton Arbel BMC NPCM8XX SoC clks
- MediaTek MT6735 SoC clks
- MediaTek MT7620, MT7628 and MT7688 MMC clks
- Add a driver for gated fixed rate clocks
- Global clock controllers for Qualcomm QCS8300 and IPQ5424 SoCs
- Camera, display and video clock controllers for Qualcomm SA8775P
SoCs
- Global, display, GPU, TCSR, and RPMh clock controllers for Qualcomm
SAR2130P
- Global, camera, display, GPU, and video clock controllers for
Qualcomm SM8475 SoCs
- RTC power domain and Battery Backup Function (VBATTB) clock support
for the Renesas RZ/G3S SoC
- Qualcomm IPQ9574 alpha PLLs
- Support for i.MX91 CCM in the i.MX93 driver
- Microchip LAN969X SoC clks
- Cortex-A55 core clocks and Interrupt Control Unit (ICU) clock and
reset on Renesas RZ/V2H(P)
- Samsung ExynosAutov920 clk drivers for PERIC1, MISC, HSI0 and HSI1
- Samsung Exynos8895 clk drivers for FSYS0/1, PERIC0/1, PERIS and TOP
Updates:
- Convert more clk bindings to YAML
- Various clk driver cleanups: NULL checks, add const, etc.
- Remove END/NUM #defines that count number of clks in various
binding headers
- Continue moving reset drivers to drivers/reset via auxiliary bus"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (162 commits)
clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access
clk: Fix invalid execution of clk_set_rate
clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider
clk: lan966x: make it selectable for ARCH_LAN969X
clk: eyeq: add EyeQ6H west fixed factor clocks
clk: eyeq: add EyeQ6H central fixed factor clocks
clk: eyeq: add EyeQ5 fixed factor clocks
clk: eyeq: add fixed factor clocks infrastructure
clk: eyeq: require clock index with phandle in all cases
clk: fixed-factor: add clk_hw_register_fixed_factor_index() function
dt-bindings: clock: eyeq: add more Mobileye EyeQ5/EyeQ6H clocks
dt-bindings: soc: mobileye: set `#clock-cells = <1>` for all compatibles
clk: clk-axi-clkgen: make sure to enable the AXI bus clock
dt-bindings: clock: axi-clkgen: include AXI clk
clk: mmp: Add Marvell PXA1908 MPMU driver
clk: mmp: Add Marvell PXA1908 APMU driver
clk: mmp: Add Marvell PXA1908 APBCP driver
clk: mmp: Add Marvell PXA1908 APBC driver
dt-bindings: clock: Add Marvell PXA1908 clock bindings
clk: mmp: Switch to use struct u32_fract instead of custom one
...
The newly added driver causes a warnings when enabling -Wunused-const-variables:
drivers/clk/qcom/gcc-ipq5424.c:1064:30: error: 'ftbl_gcc_q6_axi_clk_src' defined but not used [-Werror=unused-const-variable=]
1064 | static const struct freq_tbl ftbl_gcc_q6_axi_clk_src[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/qcom/gcc-ipq5424.c:957:30: error: 'ftbl_gcc_qpic_clk_src' defined but not used [-Werror=unused-const-variable=]
957 | static const struct freq_tbl ftbl_gcc_qpic_clk_src[] = {
| ^~~~~~~~~~~~~~~~~~~~~
drivers/clk/qcom/gcc-ipq5424.c:497:30: error: 'ftbl_gcc_qupv3_2x_core_clk_src' defined but not used [-Werror=unused-const-variable=]
497 | static const struct freq_tbl ftbl_gcc_qupv3_2x_core_clk_src[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to hopefully enable this warning by default in the future,
remove the data for now. If it gets used in the future, it can
trivially get added back.
Fixes: 21b5d5a4a3 ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5424 SoC")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20241111103258.3336183-1-arnd@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
