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>
The CMN PLL controller provides clocks to networking hardware blocks
and to GCC on Qualcomm IPQ9574 SoC. It receives input clock from the
on-chip Wi-Fi, and produces output clocks at fixed rates. These output
rates are predetermined, and are unrelated to the input clock rate.
The primary purpose of CMN PLL is to supply clocks to the networking
hardware such as PPE (packet process engine), PCS and the externally
connected switch or PHY device. The CMN PLL block also outputs fixed
rate clocks to GCC, such as 24 MHZ as XO clock and 32 KHZ as sleep
clock supplied to GCC.
Signed-off-by: Luo Jie <quic_luoj@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250103-qcom_ipq_cmnpll-v8-1-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>
