IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-8-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-6-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Number of clocks supported by Linux drivers might vary - sometimes we
add new clocks, not exposed previously. Therefore these numbers of
clocks should not be in the bindings, as that prevents changing them.
Define number of clocks per each clock controller inside the driver
directly.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20230808082738.122804-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates"),
the driver has the ability to dynamically compute PLL parameters to
approximate the requested rates. This is not always used, because the
logic is as follows:
- Check if the target rate is hardcoded in the frequency table
- Check if varying only kdiv is possible, so switch over is glitch free
- Compute rate dynamically by iterating over pdiv range
If we skip the frequency table for the 1443x PLL, we find that the
computed values differ to the hardcoded ones. This can be valid if the
hardcoded values guarantee for example an earlier lock-in or if the
divisors are chosen, so that other important rates are more likely to
be reached glitch-free.
For rates (393216000 and 361267200, this doesn't seem to be the case:
They are only approximated by existing parameters (393215995 and
361267196 Hz, respectively) and they aren't reachable glitch-free from
other hardcoded frequencies. Dropping them from the table allows us
to lock-in to these frequencies exactly.
This is immediately noticeable because they are the assigned-clock-rates
for IMX8MN_AUDIO_PLL1 and IMX8MN_AUDIO_PLL2, respectively and a look
into clk_summary so far showed that they were a few Hz short of the target:
imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary
audio_pll2_out 0 0 0 361267196 0 0 50000 N
audio_pll1_out 1 1 0 393215995 0 0 50000 Y
and afterwards:
imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary
audio_pll2_out 0 0 0 361267200 0 0 50000 N
audio_pll1_out 1 1 0 393216000 0 0 50000 Y
This change is equivalent to adding following hardcoded values:
/* rate mdiv pdiv sdiv kdiv */
PLL_1443X_RATE(393216000, 655, 5, 3, 23593),
PLL_1443X_RATE(361267200, 497, 33, 0, -16882),
Fixes: 053a4ffe2988 ("clk: imx: imx8mm: fix audio pll setting")
Cc: stable@vger.kernel.org # v5.18+
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20230807084744.1184791-2-m.felsch@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
The PLL14xx hardware can be found on i.MX8M{M,N,P} SoCs and always come
with a 6-bit pre-divider. Neither the reference manuals nor the
datasheets of these SoCs do mention any restrictions. Furthermore the
current code doesn't respect the restrictions from the comment too.
Therefore drop the restriction and align the max pre-divider (pdiv)
value to 63 to get more accurate frequencies.
Fixes: b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates")
Cc: stable@vger.kernel.org
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.kernel.org/r/20230807084744.1184791-1-m.felsch@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reconfiguring the clock divider to the exact same value is observed
on an i.MX8MN to often cause a longer than usual clock pause, probably
because the divider restarts counting whenever the register is rewritten.
This issue doesn't show up normally, because the clock framework will
take care to not call set_rate when the clock rate is the same.
However, when we reconfigure an upstream clock, the common code will
call set_rate with the newly calculated rate on all children, e.g.:
- sai5 is running normally and divides Audio PLL out by 16.
- Audio PLL rate is increased by 32Hz (glitch-free kdiv change)
- rates for children are recalculated and rates are set recursively
- imx8m_clk_composite_divider_set_rate(sai5) is called with
32/16 = 2Hz more
- imx8m_clk_composite_divider_set_rate computes same divider as before
- divider register is written, so it restarts counting from zero and
MCLK is briefly paused, so instead of e.g. 40ns, MCLK is low for 120ns.
Some external clock consumers can be upset by such unexpected clock pauses,
so let's make sure we only rewrite the divider value when the value to be
written is actually different.
Fixes: d3ff9728134e ("clk: imx: Add imx composite clock")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230807082201.2332746-1-a.fatoum@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
The __mx25_clocks_init function always returns 0 and its only
caller does not check the return value. Let's remove it.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20230802184046.153394-3-martin@kaiser.cx
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Print the imx25 silicon revision when the clocks are initialised.
Use the same mechanism as for imx27, i.e. call mx25_revision.
This function is unused at the moment.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20230802184046.153394-2-martin@kaiser.cx
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
The reference manual don't mention a SAI4 hardware block. This would be
clock slice 78 which is skipped (TRM, page 237). Remove any reference to
this clock to align the driver with the reality.
Fixes: 9c140d992676 ("clk: imx: Add support for i.MX8MP clock driver")
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Link: https://lore.kernel.org/r/20230731142150.3186650-1-m.felsch@pengutronix.de
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
The SPLL2 on iMX8ULP is different with other frac PLLs, it can
support VCO from 650Mhz to 1Ghz. Following the changes to pllv4,
use the new type IMX_PLLV4_IMX8ULP_1GHZ.
Fixes: c43a801a5789 ("clk: imx: Add clock driver for imx8ulp")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20230625123340.4067536-2-peng.fan@oss.nxp.com
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
The SPLL2 on iMX8ULP is different with other frac PLLs, it can
support VCO from 650Mhz to 1Ghz. According to RM, the MULT is
using a range from 27 to 54, not some fixed values. If using
current PLL implementation, some clock rate can't be supported.
Fix the issue by adding new type for the SPLL2 and use MULT range
to replace MULT table
Fixes: 5f0601c47c33 ("clk: imx: Update the pllv4 to support imx8ulp")
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20230625123340.4067536-1-peng.fan@oss.nxp.com
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
The Audio Clock Mux (ACM) is a collection of control registers
and multiplexers that are used to route the audio source clocks
to the audio peripherals.
Each audio peripheral has its dedicated audio clock mux
(which differ based on usage) and control register.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/1690260984-25744-3-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20230705065313.67043-8-frank.li@vivo.com
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
This is the parent clock of gpll0_early, so it needs to be enabled
for gpll0_early to return the correct rate. Enable GPLL0_SLEEP_CLK_SRC
by adding its existing definition to the clock list.
This clock also doesn't work with clk_alpha_pll_ops, use
clk_branch_simple_ops instead to make it enable and disable correctly.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Link: https://lore.kernel.org/r/20230802170317.205112-3-otto.pflueger@abscue.de
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The clock RCGs are required to be parked at safe clock source(XO)
during disable as per the hardware expectation and clk_rcg2_shared_ops
are the closest implementation for the same. Hence update the clock
RCG ops to clk_rcg2_shared_ops.
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-9-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Update the GCC SDCC clock RCG ops to clk_rcg2_floor_ops to avoid
the overclocking issues on QDU1000 and QRU1000 SoCs.
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-8-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the GDSCs support for QDU1000 and QRU1000 SoCs.
Co-developed-by: Taniya Das <quic_tdas@quicinc.com>
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-7-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the gcc_ddrss_ecpri_gsi_clk support as per the latest hardware
version of QDU1000 and QRU100 SoCs.
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-6-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
gcc_gpll1_out_even clock is referenced as a parent, but not registered
with the clock framework. Hence add support to register the same.
Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support")
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-5-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Update the GCC clkref clock's halt_check to BRANCH_HALT, as it's
status bit is not inverted in the latest hardware version of QDU1000
and QRU1000 SoCs. While at it, fix the gcc clkref clock ops as well.
Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support")
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-4-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Fix the gcc pcie pipe clock handling as per the clk_regmap_phy_mux_ops
implementation to let the clock framework automatically park the clock
at XO when the clock is switched off and restore the parent when the
clock is switched on.
Fixes: 1c9efb0bc040 ("clk: qcom: Add QDU1000 and QRU1000 GCC support")
Co-developed-by: Taniya Das <quic_tdas@quicinc.com>
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230803105741.2292309-3-quic_imrashai@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Use the floor ops to prevent warnings like this at suspend exit and boot:
mmc0: Card appears overclocked; req 800000 Hz, actual 25000000 Hz
Fixes: db0c944ee92b ("clk: qcom: Add clock driver for SM8450")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20230811-topic-8450_clk-v1-1-88031478d548@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
With the removal of the mem noc clocks in the commit e224dc703521 ("clk:
qcom: gcc-ipq5332: drop the mem noc clocks"), we can drop the
gcc_apss_axi_clk_src clock as well, since there are no clocks uses this
clock as a parent.
Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
Link: https://lore.kernel.org/r/20230710102807.1189942-3-quic_kathirav@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Due to the recent design changes, all the mem noc clocks will be
configured by the bootloaders and it will be access protected by the TZ
firmware. So drop these clocks from the GCC driver.
Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
Link: https://lore.kernel.org/r/20230710102807.1189942-2-quic_kathirav@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Some branch clocks are governed externally and we're only supposed to
send a request concerning their shutdown, not actually ensure it happens.
Use the BRANCH_HALT_SKIP define to skip checking the halt bit.
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230622-topic-8998clk-v2-6-6222fbc2916b@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
GPUCC has its own GPLL0 legs - one for 1-1 and one for div-2 output.
Add .name lookup to make sure older DTs consume the correct clock.
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230622-topic-8998clk-v2-5-6222fbc2916b@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Up until now, the GPLL0_DIV MMSS input has been modeled as a fixed
child of MMSS_GPLL0_DIV that's always-on. Properly representing the
former in the GCC driver makes us unable to keep doing so.
Consume MSS_GPLL0_DIV through fw_name ("gpll0_div") as well as add a
fixed .name link to keep backwards compatibility.
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230622-topic-8998clk-v2-4-6222fbc2916b@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Up until now, we've been relying on some non-descript hardware magic
to pinkypromise turn the clocks on for us. While new SoCs shine with
that feature, MSM8998 can not always be fully trusted.
Register the MMSS and GPUSS GPLL0 legs with the CCF to allow for manual
enable voting.
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230622-topic-8998clk-v2-3-6222fbc2916b@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Similar to ccu_mp, if the current parent rate allows getting the ideal
rate, prefer to not change the parent clock's rate.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-11-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Selecting the closest rate for pll-video0 instead of the closest rate
that is less than the requested rate has no downside for this clock,
while allowing for selecting a more suitable rate, e.g. for the
connected panels.
Furthermore, the algorithm that sets an NKM clock's parent benefits from
the closest rate. Without it, the NKM clock's rate might drift away from
the requested rate in the multiple successive calls to
ccu_nkm_determine_rate that the clk framework performs when setting a
clock rate.
Therefore, configure pll-video0 and, in consequence, all of its
descendents to select the closest rate.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-10-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Add initalization macros for divisor clocks with mux
(SUNXI_CCU_M_WITH_MUX) to support finding the closest rate. This clock
type requires the appropriate flags to be set in the .common structure
(for the mux part of the clock) and the .div part.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-9-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
When finding the best rate for a mux clock, consider rates that are
higher than the requested rate when CCU_FEATURE_ROUND_CLOSEST is used.
Furthermore, introduce an initialization macro that sets this flag.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-8-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
When finding the best rate for a NKM clock, consider rates that are
higher than the requested rate, if the CCU_FEATURE_CLOSEST_RATE flag is
set by using the helper function ccu_is_better_rate().
Accommodate ccu_mux_helper_determine_rate to this change.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-7-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Use the helper function ccu_is_better_rate() to determine the rate that
is closest to the requested rate, thereby supporting rates that are
higher than the requested rate if the clock uses the
CCU_FEATURE_CLOSEST_RATE.
Add the macro SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST which
sets CCU_FEATURE_CLOSEST_RATE.
To avoid code duplication, add the macros
SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT that allows selecting
arbitrary features and use it in the original
SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX as well as the newly introduced
SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST macros.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-6-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The default behaviour of clocks in the sunxi-ng driver is to select a
clock rate that is closest to but less than the requested rate.
Add the ccu_is_better_rate() helper function that - depending on the
fact if thc CCU_FEATURE_CLOSEST_RATE flag is set - decides if a rate is
closer than another rate.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-5-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The default behaviour of clocks in the sunxi-ng driver is to select a
clock rate that is closest to but less than the requested rate.
Add the CCU_FEATURE_CLOSEST_RATE flag, which can be used to allow clocks
to find the closest rate instead.
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-4-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The nkm clock now supports setting the parent's rate. Utilize this
option to find the optimal rate for pll-mipi.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-3-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
In case the CLK_SET_RATE_PARENT flag is set, consider using a different
parent rate when determining a new rate.
To find the best match for the requested rate, perform the following
steps for each NKM combination:
- calculate the optimal parent rate,
- find the best parent rate that the parent clock actually supports
- use that parent rate to calculate the effective rate.
In case the clk does not support setting the parent rate, use the same
algorithm as before.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-2-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
ccu_nkm_round_rate() takes a clk_hw as parameter "hw". Since "hw" is the
nkm clock's parent clk_hw, not the clk_hw of the nkm clock itself,
change the parameter name to "parent_hw" to make it more clear what
we're dealing with.
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
Link: https://lore.kernel.org/r/20230807-pll-mipi_set_rate_parent-v6-1-f173239a4b59@oltmanns.dev
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
