[PATCH v2 00/65] clk: Make determine_rate mandatory for muxes
Hi,
This is a follow-up to a previous series that was printing a warning when a mux has a set_parent implementation but is missing determine_rate().
The rationale is that set_parent() is very likely to be useful when changing the rate, but it's determine_rate() that takes the parenting decision. If we're missing it, then the current parent is always going to be used, and thus set_parent() will not be used. The only exception being a direct call to clk_set_parent(), but those are fairly rare compared to clk_set_rate().
Stephen then asked to promote the warning to an error, and to fix up all the muxes that are in that situation first. So here it is :)
Let me know what you think, Maxime
To: Michael Turquette mturquette@baylibre.com To: Stephen Boyd sboyd@kernel.org To: Andreas Färber afaerber@suse.de To: Manivannan Sadhasivam mani@kernel.org To: Nicolas Ferre nicolas.ferre@microchip.com To: Alexandre Belloni alexandre.belloni@bootlin.com To: Claudiu Beznea claudiu.beznea@microchip.com To: Max Filippov jcmvbkbc@gmail.com To: Charles Keepax ckeepax@opensource.cirrus.com To: Richard Fitzgerald rf@opensource.cirrus.com To: Maxime Coquelin mcoquelin.stm32@gmail.com To: Alexandre Torgue alexandre.torgue@foss.st.com To: Luca Ceresoli luca.ceresoli@bootlin.com To: David Lechner david@lechnology.com To: Sekhar Nori nsekhar@ti.com To: Abel Vesa abelvesa@kernel.org To: Shawn Guo shawnguo@kernel.org To: Sascha Hauer s.hauer@pengutronix.de To: Pengutronix Kernel Team kernel@pengutronix.de To: Fabio Estevam festevam@gmail.com To: NXP Linux Team linux-imx@nxp.com To: Matthias Brugger matthias.bgg@gmail.com To: Geert Uytterhoeven geert+renesas@glider.be To: Dinh Nguyen dinguyen@kernel.org To: Peter De Schrijver pdeschrijver@nvidia.com To: Prashant Gaikwad pgaikwad@nvidia.com To: Thierry Reding thierry.reding@gmail.com To: Jonathan Hunter jonathanh@nvidia.com To: Ulf Hansson ulf.hansson@linaro.org To: Linus Walleij linus.walleij@linaro.org To: David Airlie airlied@gmail.com To: Daniel Vetter daniel@ffwll.ch To: Vinod Koul vkoul@kernel.org To: Kishon Vijay Abraham I kishon@kernel.org To: Alessandro Zummo a.zummo@towertech.it To: Chen-Yu Tsai wens@csie.org To: Jernej Skrabec jernej.skrabec@gmail.com To: Samuel Holland samuel@sholland.org To: Liam Girdwood lgirdwood@gmail.com To: Mark Brown broonie@kernel.org To: Jaroslav Kysela perex@perex.cz To: Takashi Iwai tiwai@suse.com To: Paul Cercueil paul@crapouillou.net To: Orson Zhai orsonzhai@gmail.com To: Baolin Wang baolin.wang@linux.alibaba.com To: Chunyan Zhang zhang.lyra@gmail.com Cc: linux-clk@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-actions@lists.infradead.org Cc: patches@opensource.cirrus.com Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-mediatek@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-phy@lists.infradead.org Cc: linux-rtc@vger.kernel.org Cc: linux-sunxi@lists.linux.dev Cc: alsa-devel@alsa-project.org Cc: linux-mips@vger.kernel.org Signed-off-by: Maxime Ripard maxime@cerno.tech --- Changes in v2: - Drop all the patches already applied - Promote the clk registration warning to an error - Make all muxes use determine_rate - Link to v1: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v1-0-f3ef80518140@...
--- Maxime Ripard (65): clk: Export clk_hw_forward_rate_request() clk: lan966x: Remove unused round_rate hook clk: nodrv: Add a determine_rate hook clk: test: Add a determine_rate hook clk: actions: composite: Add a determine_rate hook for pass clk clk: at91: main: Add a determine_rate hook clk: at91: sckc: Add a determine_rate hook clk: berlin: div: Add a determine_rate hook clk: cdce706: Add a determine_rate hook clk: k210: pll: Add a determine_rate hook clk: k210: aclk: Add a determine_rate hook clk: k210: mux: Add a determine_rate hook clk: lmk04832: clkout: Add a determine_rate hook clk: lochnagar: Add a determine_rate hook clk: qoriq: Add a determine_rate hook clk: si5341: Add a determine_rate hook clk: stm32f4: mux: Add a determine_rate hook clk: vc5: mux: Add a determine_rate hook clk: vc5: clkout: Add a determine_rate hook clk: wm831x: clkout: Add a determine_rate hook clk: davinci: da8xx-cfgchip: Add a determine_rate hook clk: davinci: da8xx-cfgchip: Add a determine_rate hook clk: imx: busy: Add a determine_rate hook clk: imx: fixup-mux: Add a determine_rate hook clk: imx: scu: Add a determine_rate hook clk: mediatek: cpumux: Add a determine_rate hook clk: pxa: Add a determine_rate hook clk: renesas: r9a06g032: Add a determine_rate hook clk: socfpga: gate: Add a determine_rate hook clk: stm32: core: Add a determine_rate hook clk: tegra: bpmp: Add a determine_rate hook clk: tegra: super: Add a determine_rate hook clk: tegra: periph: Add a determine_rate hook clk: ux500: prcmu: Add a determine_rate hook clk: ux500: sysctrl: Add a determine_rate hook clk: versatile: sp810: Add a determine_rate hook drm/tegra: sor: Add a determine_rate hook phy: cadence: sierra: Add a determine_rate hook phy: cadence: torrent: Add a determine_rate hook phy: ti: am654-serdes: Add a determine_rate hook phy: ti: j721e-wiz: Add a determine_rate hook rtc: sun6i: Add a determine_rate hook ASoC: tlv320aic32x4: Add a determine_rate hook clk: actions: composite: div: Switch to determine_rate clk: actions: composite: fact: Switch to determine_rate clk: at91: smd: Switch to determine_rate clk: axi-clkgen: Switch to determine_rate clk: cdce706: divider: Switch to determine_rate clk: cdce706: clkout: Switch to determine_rate clk: si5341: Switch to determine_rate clk: si5351: pll: Switch to determine_rate clk: si5351: msynth: Switch to determine_rate clk: si5351: clkout: Switch to determine_rate clk: da8xx: clk48: Switch to determine_rate clk: imx: scu: Switch to determine_rate clk: ingenic: cgu: Switch to determine_rate clk: ingenic: tcu: Switch to determine_rate clk: sprd: composite: Switch to determine_rate clk: st: flexgen: Switch to determine_rate clk: stm32: composite: Switch to determine_rate clk: tegra: periph: Switch to determine_rate clk: tegra: super: Switch to determine_rate ASoC: tlv320aic32x4: pll: Switch to determine_rate ASoC: tlv320aic32x4: div: Switch to determine_rate clk: Warn if we register a mux without determine_rate
drivers/clk/actions/owl-composite.c | 35 +++++++++++----- drivers/clk/actions/owl-composite.h | 2 +- drivers/clk/at91/clk-main.c | 3 +- drivers/clk/at91/clk-smd.c | 29 +++++++------ drivers/clk/at91/sckc.c | 3 +- drivers/clk/berlin/berlin2-div.c | 3 +- drivers/clk/clk-axi-clkgen.c | 14 ++++--- drivers/clk/clk-cdce706.c | 31 ++++++++------ drivers/clk/clk-k210.c | 17 +++++--- drivers/clk/clk-lan966x.c | 17 -------- drivers/clk/clk-lmk04832.c | 1 + drivers/clk/clk-lochnagar.c | 2 + drivers/clk/clk-qoriq.c | 10 +++-- drivers/clk/clk-si5341.c | 21 +++++----- drivers/clk/clk-si5351.c | 67 +++++++++++++++++-------------- drivers/clk/clk-stm32f4.c | 3 +- drivers/clk/clk-versaclock5.c | 8 ++-- drivers/clk/clk-wm831x.c | 3 +- drivers/clk/clk.c | 15 +++++++ drivers/clk/clk_test.c | 1 + drivers/clk/davinci/da8xx-cfgchip.c | 15 ++++--- drivers/clk/imx/clk-busy.c | 3 +- drivers/clk/imx/clk-fixup-mux.c | 3 +- drivers/clk/imx/clk-scu.c | 27 +++++++++++-- drivers/clk/ingenic/cgu.c | 15 +++---- drivers/clk/ingenic/tcu.c | 19 +++++---- drivers/clk/mediatek/clk-cpumux.c | 3 +- drivers/clk/pxa/clk-pxa.c | 3 +- drivers/clk/renesas/r9a06g032-clocks.c | 3 +- drivers/clk/socfpga/clk-gate.c | 3 +- drivers/clk/sprd/composite.c | 16 +++++--- drivers/clk/st/clk-flexgen.c | 15 +++---- drivers/clk/stm32/clk-stm32-core.c | 32 ++++++++++----- drivers/clk/tegra/clk-bpmp.c | 7 +++- drivers/clk/tegra/clk-periph.c | 19 ++++++--- drivers/clk/tegra/clk-super.c | 18 ++++++--- drivers/clk/ux500/clk-prcmu.c | 3 +- drivers/clk/ux500/clk-sysctrl.c | 4 +- drivers/clk/versatile/clk-sp810.c | 3 +- drivers/gpu/drm/tegra/sor.c | 3 +- drivers/phy/cadence/phy-cadence-sierra.c | 1 + drivers/phy/cadence/phy-cadence-torrent.c | 1 + drivers/phy/ti/phy-am654-serdes.c | 1 + drivers/phy/ti/phy-j721e-wiz.c | 1 + drivers/rtc/rtc-sun6i.c | 2 + sound/soc/codecs/tlv320aic32x4-clk.c | 37 ++++++++++------- 46 files changed, 343 insertions(+), 199 deletions(-) --- base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd change-id: 20221018-clk-range-checks-fixes-2039f3523240
Best regards,
Commit 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent") introduced the public clk_hw_forward_rate_request() function, but didn't export the symbol. Make sure it's the case.
Fixes: 262ca38f4b6e ("clk: Stop forwarding clk_rate_requests to the parent") Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 57b83665e5c3..d4a74759fe29 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1525,6 +1525,7 @@ void clk_hw_forward_rate_request(const struct clk_hw *hw, parent->core, req, parent_rate); } +EXPORT_SYMBOL_GPL(clk_hw_forward_rate_request);
static bool clk_core_can_round(struct clk_core * const core) {
The lan966x driver registers a gck clock with both a determine_rate and a round_rate implementation. Both are equivalent, and are only called by clk_core_determine_round_nolock() which favors determine_rate.
Thus, lan966x_gck_round_rate() is never called, so we can just remove it.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-lan966x.c | 17 ----------------- 1 file changed, 17 deletions(-)
diff --git a/drivers/clk/clk-lan966x.c b/drivers/clk/clk-lan966x.c index 460e7216bfa1..870fd7df50c1 100644 --- a/drivers/clk/clk-lan966x.c +++ b/drivers/clk/clk-lan966x.c @@ -103,22 +103,6 @@ static int lan966x_gck_set_rate(struct clk_hw *hw, return 0; }
-static long lan966x_gck_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) -{ - unsigned int div; - - if (rate == 0 || *parent_rate == 0) - return -EINVAL; - - if (rate >= *parent_rate) - return *parent_rate; - - div = DIV_ROUND_CLOSEST(*parent_rate, rate); - - return *parent_rate / div; -} - static unsigned long lan966x_gck_recalc_rate(struct clk_hw *hw, unsigned long parent_rate) { @@ -177,7 +161,6 @@ static const struct clk_ops lan966x_gck_ops = { .enable = lan966x_gck_enable, .disable = lan966x_gck_disable, .set_rate = lan966x_gck_set_rate, - .round_rate = lan966x_gck_round_rate, .recalc_rate = lan966x_gck_recalc_rate, .determine_rate = lan966x_gck_determine_rate, .set_parent = lan966x_gck_set_parent,
The nodrv clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
Even though it's a mock clock and the missing function is harmless, we'll start to require a determine_rate implementation when set_parent is set, so let's fill it.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index d4a74759fe29..495d7497cc43 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -4257,11 +4257,18 @@ static int clk_nodrv_set_parent(struct clk_hw *hw, u8 index) return -ENXIO; }
+static int clk_nodrv_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) +{ + return -ENXIO; +} + static const struct clk_ops clk_nodrv_ops = { .enable = clk_nodrv_prepare_enable, .disable = clk_nodrv_disable_unprepare, .prepare = clk_nodrv_prepare_enable, .unprepare = clk_nodrv_disable_unprepare, + .determine_rate = clk_nodrv_determine_rate, .set_rate = clk_nodrv_set_rate, .set_parent = clk_nodrv_set_parent, };
The single parent clock in our kunit tests implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is not entirely unexpected, since its whole purpose it to have a single parent. When determine_rate is missing, and since CLK_SET_RATE_PARENT is set for all its instances, the default behaviour of the framework will be to forward it to the current parent.
This is totally fine as far as the tests are concerned, but we'll start to mandate a determine_rate implementation when set_parent is set, so let's fill it with __clk_mux_determine_rate() which will have the same behavior.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk_test.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c index f9a5c2964c65..b4f37fbd180b 100644 --- a/drivers/clk/clk_test.c +++ b/drivers/clk/clk_test.c @@ -104,6 +104,7 @@ static const struct clk_ops clk_dummy_minimize_rate_ops = { };
static const struct clk_ops clk_dummy_single_parent_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = clk_dummy_single_set_parent, .get_parent = clk_dummy_single_get_parent, };
The Actions "Pass" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/actions/owl-composite.c | 1 + drivers/clk/actions/owl-composite.h | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/actions/owl-composite.c b/drivers/clk/actions/owl-composite.c index 101706e0c66f..4c844a5613e4 100644 --- a/drivers/clk/actions/owl-composite.c +++ b/drivers/clk/actions/owl-composite.c @@ -189,6 +189,7 @@ const struct clk_ops owl_comp_fix_fact_ops = {
const struct clk_ops owl_comp_pass_ops = { /* mux_ops */ + .determine_rate = __clk_mux_determine_rate, .get_parent = owl_comp_get_parent, .set_parent = owl_comp_set_parent,
diff --git a/drivers/clk/actions/owl-composite.h b/drivers/clk/actions/owl-composite.h index bca38bf8f218..0a0eecc78344 100644 --- a/drivers/clk/actions/owl-composite.h +++ b/drivers/clk/actions/owl-composite.h @@ -104,7 +104,7 @@ struct owl_composite { .hw.init = CLK_HW_INIT_PARENTS(_name, \ _parent, \ &owl_comp_pass_ops,\ - _flags), \ + _flags | CLK_SET_RATE_NO_REPARENT), \ }, \ }
The SAM9x5 main clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/at91/clk-main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c index 8601b27c1ae0..e04e72394632 100644 --- a/drivers/clk/at91/clk-main.c +++ b/drivers/clk/at91/clk-main.c @@ -533,6 +533,7 @@ static const struct clk_ops sam9x5_main_ops = { .prepare = clk_sam9x5_main_prepare, .is_prepared = clk_sam9x5_main_is_prepared, .recalc_rate = clk_sam9x5_main_recalc_rate, + .determine_rate = __clk_mux_determine_rate, .set_parent = clk_sam9x5_main_set_parent, .get_parent = clk_sam9x5_main_get_parent, .save_context = clk_sam9x5_main_save_context, @@ -565,7 +566,7 @@ at91_clk_register_sam9x5_main(struct regmap *regmap, init.ops = &sam9x5_main_ops; init.parent_names = parent_names; init.num_parents = num_parents; - init.flags = CLK_SET_PARENT_GATE; + init.flags = CLK_SET_PARENT_GATE | CLK_SET_RATE_NO_REPARENT;
clkmain->hw.init = &init; clkmain->regmap = regmap;
The SAM9x5 slow clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/at91/sckc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/at91/sckc.c b/drivers/clk/at91/sckc.c index fdc9b669f8a7..9c42961a8a2f 100644 --- a/drivers/clk/at91/sckc.c +++ b/drivers/clk/at91/sckc.c @@ -310,6 +310,7 @@ static u8 clk_sam9x5_slow_get_parent(struct clk_hw *hw) }
static const struct clk_ops sam9x5_slow_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = clk_sam9x5_slow_set_parent, .get_parent = clk_sam9x5_slow_get_parent, }; @@ -337,7 +338,7 @@ at91_clk_register_sam9x5_slow(void __iomem *sckcr, init.ops = &sam9x5_slow_ops; init.parent_names = parent_names; init.num_parents = num_parents; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT;
slowck->hw.init = &init; slowck->sckcr = sckcr;
The Berlin2 divider clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/berlin/berlin2-div.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/berlin/berlin2-div.c b/drivers/clk/berlin/berlin2-div.c index eb14a5bc0507..d3856ec93c12 100644 --- a/drivers/clk/berlin/berlin2-div.c +++ b/drivers/clk/berlin/berlin2-div.c @@ -210,6 +210,7 @@ static unsigned long berlin2_div_recalc_rate(struct clk_hw *hw, }
static const struct clk_ops berlin2_div_rate_ops = { + .determine_rate = __clk_mux_determine_rate, .recalc_rate = berlin2_div_recalc_rate, };
@@ -251,5 +252,5 @@ berlin2_div_register(const struct berlin2_div_map *map,
return clk_hw_register_composite(NULL, name, parent_names, num_parents, &div->hw, mux_ops, &div->hw, rate_ops, - &div->hw, gate_ops, flags); + &div->hw, gate_ops, flags | CLK_SET_RATE_NO_REPARENT); }
The cdce706 "clkin" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-cdce706.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/clk/clk-cdce706.c b/drivers/clk/clk-cdce706.c index 1449d0537674..dc046bbf83a1 100644 --- a/drivers/clk/clk-cdce706.c +++ b/drivers/clk/clk-cdce706.c @@ -155,6 +155,7 @@ static u8 cdce706_clkin_get_parent(struct clk_hw *hw) }
static const struct clk_ops cdce706_clkin_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = cdce706_clkin_set_parent, .get_parent = cdce706_clkin_get_parent, }; @@ -471,6 +472,7 @@ static int cdce706_register_clkin(struct cdce706_dev_data *cdce) { struct clk_init_data init = { .ops = &cdce706_clkin_ops, + .flags = CLK_SET_RATE_NO_REPARENT, .parent_names = cdce->clkin_name, .num_parents = ARRAY_SIZE(cdce->clkin_name), };
The K210 PLL clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-k210.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-k210.c b/drivers/clk/clk-k210.c index 67a7cb3503c3..279931a38127 100644 --- a/drivers/clk/clk-k210.c +++ b/drivers/clk/clk-k210.c @@ -537,6 +537,7 @@ static const struct clk_ops k210_pll2_ops = { .disable = k210_pll_disable, .is_enabled = k210_pll_is_enabled, .recalc_rate = k210_pll_get_rate, + .determine_rate = __clk_mux_determine_rate, .set_parent = k210_pll2_set_parent, .get_parent = k210_pll2_get_parent, }; @@ -544,7 +545,8 @@ static const struct clk_ops k210_pll2_ops = { static int __init k210_register_pll(struct device_node *np, struct k210_sysclk *ksc, enum k210_pll_id pllid, const char *name, - int num_parents, const struct clk_ops *ops) + int num_parents, const struct clk_ops *ops, + unsigned long flags) { struct k210_pll *pll = &ksc->plls[pllid]; struct clk_init_data init = {}; @@ -558,6 +560,7 @@ static int __init k210_register_pll(struct device_node *np, init.parent_data = parent_data; init.num_parents = num_parents; init.ops = ops; + init.flags = flags;
pll->hw.init = &init; pll->ksc = ksc; @@ -574,19 +577,20 @@ static int __init k210_register_plls(struct device_node *np, k210_init_pll(ksc->regs, i, &ksc->plls[i]);
/* PLL0 and PLL1 only have IN0 as parent */ - ret = k210_register_pll(np, ksc, K210_PLL0, "pll0", 1, &k210_pll_ops); + ret = k210_register_pll(np, ksc, K210_PLL0, "pll0", 1, &k210_pll_ops, 0); if (ret) { pr_err("%pOFP: register PLL0 failed\n", np); return ret; } - ret = k210_register_pll(np, ksc, K210_PLL1, "pll1", 1, &k210_pll_ops); + ret = k210_register_pll(np, ksc, K210_PLL1, "pll1", 1, &k210_pll_ops, 0); if (ret) { pr_err("%pOFP: register PLL1 failed\n", np); return ret; }
/* PLL2 has IN0, PLL0 and PLL1 as parents */ - ret = k210_register_pll(np, ksc, K210_PLL2, "pll2", 3, &k210_pll2_ops); + ret = k210_register_pll(np, ksc, K210_PLL2, "pll2", 3, &k210_pll2_ops, + CLK_SET_RATE_NO_REPARENT); if (ret) { pr_err("%pOFP: register PLL2 failed\n", np); return ret;
The K210 ACLK clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-k210.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/clk/clk-k210.c b/drivers/clk/clk-k210.c index 279931a38127..5b9fd00d14e1 100644 --- a/drivers/clk/clk-k210.c +++ b/drivers/clk/clk-k210.c @@ -639,6 +639,7 @@ static unsigned long k210_aclk_get_rate(struct clk_hw *hw, }
static const struct clk_ops k210_aclk_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = k210_aclk_set_parent, .get_parent = k210_aclk_get_parent, .recalc_rate = k210_aclk_get_rate, @@ -661,6 +662,7 @@ static int __init k210_register_aclk(struct device_node *np, init.parent_data = parent_data; init.num_parents = 2; init.ops = &k210_aclk_ops; + init.flags = CLK_SET_RATE_NO_REPARENT; ksc->aclk.init = &init;
ret = of_clk_hw_register(np, &ksc->aclk);
The K210 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-k210.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-k210.c b/drivers/clk/clk-k210.c index 5b9fd00d14e1..cdd7230f8f66 100644 --- a/drivers/clk/clk-k210.c +++ b/drivers/clk/clk-k210.c @@ -780,6 +780,7 @@ static unsigned long k210_clk_get_rate(struct clk_hw *hw, static const struct clk_ops k210_clk_mux_ops = { .enable = k210_clk_enable, .disable = k210_clk_disable, + .determine_rate = __clk_mux_determine_rate, .set_parent = k210_clk_set_parent, .get_parent = k210_clk_get_parent, .recalc_rate = k210_clk_get_rate, @@ -832,7 +833,7 @@ static inline void __init k210_register_mux_clk(struct device_node *np, { .hw = &ksc->plls[K210_PLL0].hw } };
- k210_register_clk(np, ksc, id, parent_data, 2, 0); + k210_register_clk(np, ksc, id, parent_data, 2, CLK_SET_RATE_NO_REPARENT); }
static inline void __init k210_register_in0_child(struct device_node *np,
The LKM04832 "CLKOUT" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-lmk04832.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-lmk04832.c b/drivers/clk/clk-lmk04832.c index f416f8bc2898..f68bb0affdad 100644 --- a/drivers/clk/clk-lmk04832.c +++ b/drivers/clk/clk-lmk04832.c @@ -1281,6 +1281,7 @@ static const struct clk_ops lmk04832_clkout_ops = { .is_enabled = lmk04832_clkout_is_enabled, .prepare = lmk04832_clkout_prepare, .unprepare = lmk04832_clkout_unprepare, + .determine_rate = __clk_mux_determine_rate, .set_parent = lmk04832_clkout_set_parent, .get_parent = lmk04832_clkout_get_parent, };
Hi Maxime,
On Fri, Nov 04, 2022 at 02:17:30PM +0100, Maxime Ripard wrote:
The LKM04832 "CLKOUT" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
This is correct, the set_parent hook is effectively unused at the moment. It was implemented as a way for consumers to select the parent themselves.
The LMK04832 is used in JESD204 applications where devices need a device clock as well as a sysref clock. Since this is determined by the hardware layout, a devicetree option is used to select the inital state of the clkout mux. This is set at the end of lmk04832_register_clkout().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech
Reviewed-by: Liam Beguin liambeguin@gmail.com
Cheers, Liam
drivers/clk/clk-lmk04832.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-lmk04832.c b/drivers/clk/clk-lmk04832.c index f416f8bc2898..f68bb0affdad 100644 --- a/drivers/clk/clk-lmk04832.c +++ b/drivers/clk/clk-lmk04832.c @@ -1281,6 +1281,7 @@ static const struct clk_ops lmk04832_clkout_ops = { .is_enabled = lmk04832_clkout_is_enabled, .prepare = lmk04832_clkout_prepare, .unprepare = lmk04832_clkout_unprepare,
- .determine_rate = __clk_mux_determine_rate, .set_parent = lmk04832_clkout_set_parent, .get_parent = lmk04832_clkout_get_parent,
};
-- b4 0.11.0-dev-99e3a
The lochnagar clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-lochnagar.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/clk/clk-lochnagar.c b/drivers/clk/clk-lochnagar.c index 80944bf482e9..820c05732ac7 100644 --- a/drivers/clk/clk-lochnagar.c +++ b/drivers/clk/clk-lochnagar.c @@ -209,6 +209,7 @@ static u8 lochnagar_clk_get_parent(struct clk_hw *hw) static const struct clk_ops lochnagar_clk_ops = { .prepare = lochnagar_clk_prepare, .unprepare = lochnagar_clk_unprepare, + .determine_rate = __clk_mux_determine_rate, .set_parent = lochnagar_clk_set_parent, .get_parent = lochnagar_clk_get_parent, }; @@ -238,6 +239,7 @@ static int lochnagar_clk_probe(struct platform_device *pdev) { struct clk_init_data clk_init = { .ops = &lochnagar_clk_ops, + .flags = CLK_SET_RATE_NO_REPARENT, }; struct device *dev = &pdev->dev; struct lochnagar_clk_priv *priv;
The Qoriq mux clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-qoriq.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index 5eddb9f0d6bd..6f51a2cfaace 100644 --- a/drivers/clk/clk-qoriq.c +++ b/drivers/clk/clk-qoriq.c @@ -878,6 +878,7 @@ static u8 mux_get_parent(struct clk_hw *hw) }
static const struct clk_ops cmux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = mux_get_parent, .set_parent = mux_set_parent, }; @@ -908,6 +909,7 @@ static const struct clockgen_pll_div *get_pll_div(struct clockgen *cg, static struct clk * __init create_mux_common(struct clockgen *cg, struct mux_hwclock *hwc, const struct clk_ops *ops, + unsigned long flags, unsigned long min_rate, unsigned long max_rate, unsigned long pct80_rate, @@ -951,7 +953,7 @@ static struct clk * __init create_mux_common(struct clockgen *cg, init.ops = ops; init.parent_names = parent_names; init.num_parents = hwc->num_parents = j; - init.flags = 0; + init.flags = flags; hwc->hw.init = &init; hwc->cg = cg;
@@ -1010,8 +1012,8 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx) else min_rate = plat_rate / 2;
- return create_mux_common(cg, hwc, &cmux_ops, min_rate, max_rate, - pct80_rate, "cg-cmux%d", idx); + return create_mux_common(cg, hwc, &cmux_ops, CLK_SET_RATE_NO_REPARENT, + min_rate, max_rate, pct80_rate, "cg-cmux%d", idx); }
static struct clk * __init create_one_hwaccel(struct clockgen *cg, int idx) @@ -1025,7 +1027,7 @@ static struct clk * __init create_one_hwaccel(struct clockgen *cg, int idx) hwc->reg = cg->regs + 0x20 * idx + 0x10; hwc->info = cg->info.hwaccel[idx];
- return create_mux_common(cg, hwc, &hwaccel_ops, 0, ULONG_MAX, 0, + return create_mux_common(cg, hwc, &hwaccel_ops, 0, 0, ULONG_MAX, 0, "cg-hwaccel%d", idx); }
The SI5341 clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-si5341.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-si5341.c b/drivers/clk/clk-si5341.c index 0e528d7ba656..259861aa2e2f 100644 --- a/drivers/clk/clk-si5341.c +++ b/drivers/clk/clk-si5341.c @@ -551,6 +551,7 @@ static int si5341_clk_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops si5341_clk_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = si5341_clk_set_parent, .get_parent = si5341_clk_get_parent, .recalc_rate = si5341_clk_recalc_rate, @@ -1682,7 +1683,7 @@ static int si5341_probe(struct i2c_client *client) init.parent_names = data->input_clk_name; init.num_parents = SI5341_NUM_INPUTS; init.ops = &si5341_clk_ops; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT; data->hw.init = &init;
err = devm_clk_hw_register(&client->dev, &data->hw);
The STM32F4 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-stm32f4.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c index 473dfe632cc5..01046437a48c 100644 --- a/drivers/clk/clk-stm32f4.c +++ b/drivers/clk/clk-stm32f4.c @@ -1045,6 +1045,7 @@ static int cclk_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops cclk_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = cclk_mux_get_parent, .set_parent = cclk_mux_set_parent, }; @@ -1085,7 +1086,7 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name, &mux->hw, &cclk_mux_ops, NULL, NULL, &gate->hw, &cclk_gate_ops, - flags); + flags | CLK_SET_RATE_NO_REPARENT);
if (IS_ERR(hw)) { kfree(gate);
The Versaclock5 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-versaclock5.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c index 88689415aff9..e858066c2c3f 100644 --- a/drivers/clk/clk-versaclock5.c +++ b/drivers/clk/clk-versaclock5.c @@ -281,6 +281,7 @@ static int vc5_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops vc5_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = vc5_mux_set_parent, .get_parent = vc5_mux_get_parent, }; @@ -1031,7 +1032,7 @@ static int vc5_probe(struct i2c_client *client)
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node); init.ops = &vc5_mux_ops; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; vc5->clk_mux.init = &init; ret = devm_clk_hw_register(&client->dev, &vc5->clk_mux);
The Versaclock5 "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-versaclock5.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c index e858066c2c3f..661ab1ca3d83 100644 --- a/drivers/clk/clk-versaclock5.c +++ b/drivers/clk/clk-versaclock5.c @@ -728,6 +728,7 @@ static int vc5_clk_out_set_parent(struct clk_hw *hw, u8 index) static const struct clk_ops vc5_clk_out_ops = { .prepare = vc5_clk_out_prepare, .unprepare = vc5_clk_out_unprepare, + .determine_rate = __clk_mux_determine_rate, .set_parent = vc5_clk_out_set_parent, .get_parent = vc5_clk_out_get_parent, }; @@ -1115,7 +1116,7 @@ static int vc5_probe(struct i2c_client *client) init.name = kasprintf(GFP_KERNEL, "%pOFn.out0_sel_i2cb", client->dev.of_node); init.ops = &vc5_clk_out_ops; - init.flags = CLK_SET_RATE_PARENT; + init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; parent_names[0] = clk_hw_get_name(&vc5->clk_mux); init.num_parents = 1; @@ -1141,7 +1142,7 @@ static int vc5_probe(struct i2c_client *client) init.name = kasprintf(GFP_KERNEL, "%pOFn.out%d", client->dev.of_node, idx + 1); init.ops = &vc5_clk_out_ops; - init.flags = CLK_SET_RATE_PARENT; + init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; init.num_parents = 2; vc5->clk_out[n].num = idx;
The WM381x "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-wm831x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c index ae6dd38ec053..be3a9c1f3610 100644 --- a/drivers/clk/clk-wm831x.c +++ b/drivers/clk/clk-wm831x.c @@ -329,6 +329,7 @@ static const struct clk_ops wm831x_clkout_ops = { .is_prepared = wm831x_clkout_is_prepared, .prepare = wm831x_clkout_prepare, .unprepare = wm831x_clkout_unprepare, + .determine_rate = __clk_mux_determine_rate, .get_parent = wm831x_clkout_get_parent, .set_parent = wm831x_clkout_set_parent, }; @@ -338,7 +339,7 @@ static const struct clk_init_data wm831x_clkout_init = { .ops = &wm831x_clkout_ops, .parent_names = wm831x_clkout_parents, .num_parents = ARRAY_SIZE(wm831x_clkout_parents), - .flags = CLK_SET_RATE_PARENT, + .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, };
static int wm831x_clk_probe(struct platform_device *pdev)
On Fri, Nov 04, 2022 at 02:17:37PM +0100, Maxime Ripard wrote:
The WM381x "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Yeah I don't think there would be anything wrong with this clock changing parents on a rate change, but as you say this can be refined down the line if someone needs the behaviour. It's an older part so probably better to stick roughly to the current behaviour for now.
Acked-by: Charles Keepax ckeepax@opensource.cirrus.com
Thanks, Charles
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/davinci/da8xx-cfgchip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c b/drivers/clk/davinci/da8xx-cfgchip.c index 4103d605e804..c04276bc4051 100644 --- a/drivers/clk/davinci/da8xx-cfgchip.c +++ b/drivers/clk/davinci/da8xx-cfgchip.c @@ -229,6 +229,7 @@ static u8 da8xx_cfgchip_mux_clk_get_parent(struct clk_hw *hw) }
static const struct clk_ops da8xx_cfgchip_mux_clk_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = da8xx_cfgchip_mux_clk_set_parent, .get_parent = da8xx_cfgchip_mux_clk_get_parent, }; @@ -251,7 +252,7 @@ da8xx_cfgchip_mux_clk_register(struct device *dev, init.ops = &da8xx_cfgchip_mux_clk_ops; init.parent_names = parent_names; init.num_parents = 2; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT;
mux->hw.init = &init; mux->regmap = regmap;
On 11/4/22 8:17 AM, Maxime Ripard wrote:
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The parent is defined in the device tree and is not expected to change at runtime, so if I am understanding the patch correctly, setting the CLK_SET_RATE_NO_REPARENT flag seems correct.
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/davinci/da8xx-cfgchip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c b/drivers/clk/davinci/da8xx-cfgchip.c index 4103d605e804..c04276bc4051 100644 --- a/drivers/clk/davinci/da8xx-cfgchip.c +++ b/drivers/clk/davinci/da8xx-cfgchip.c @@ -229,6 +229,7 @@ static u8 da8xx_cfgchip_mux_clk_get_parent(struct clk_hw *hw) }
static const struct clk_ops da8xx_cfgchip_mux_clk_ops = {
- .determine_rate = __clk_mux_determine_rate, .set_parent = da8xx_cfgchip_mux_clk_set_parent, .get_parent = da8xx_cfgchip_mux_clk_get_parent, };
@@ -251,7 +252,7 @@ da8xx_cfgchip_mux_clk_register(struct device *dev, init.ops = &da8xx_cfgchip_mux_clk_ops; init.parent_names = parent_names; init.num_parents = 2;
- init.flags = 0;
init.flags = CLK_SET_RATE_NO_REPARENT;
mux->hw.init = &init; mux->regmap = regmap;
Hi David,
On Fri, Nov 04, 2022 at 11:45:17AM -0500, David Lechner wrote:
On 11/4/22 8:17 AM, Maxime Ripard wrote:
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The parent is defined in the device tree and is not expected to change at runtime, so if I am understanding the patch correctly, setting the CLK_SET_RATE_NO_REPARENT flag seems correct.
Is that an acked-by/reviewed-by?
Thanks! Maxime
On 11/7/22 6:06 AM, Maxime Ripard wrote:
Hi David,
On Fri, Nov 04, 2022 at 11:45:17AM -0500, David Lechner wrote:
On 11/4/22 8:17 AM, Maxime Ripard wrote:
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The parent is defined in the device tree and is not expected to change at runtime, so if I am understanding the patch correctly, setting the CLK_SET_RATE_NO_REPARENT flag seems correct.
Is that an acked-by/reviewed-by?
Thanks! Maxime
The commit message could be updated to be more certain now, but sure...
Acked-by: David Lechner david@lechnology.com
The Davinci DA8xxx cfgchip "clk48" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/davinci/da8xx-cfgchip.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c b/drivers/clk/davinci/da8xx-cfgchip.c index c04276bc4051..4c1cc59bba53 100644 --- a/drivers/clk/davinci/da8xx-cfgchip.c +++ b/drivers/clk/davinci/da8xx-cfgchip.c @@ -565,6 +565,7 @@ static u8 da8xx_usb1_clk48_get_parent(struct clk_hw *hw) }
static const struct clk_ops da8xx_usb1_clk48_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = da8xx_usb1_clk48_set_parent, .get_parent = da8xx_usb1_clk48_get_parent, }; @@ -589,6 +590,7 @@ da8xx_cfgchip_register_usb1_clk48(struct device *dev,
init.name = "usb1_clk48"; init.ops = &da8xx_usb1_clk48_ops; + init.flags = CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; init.num_parents = 2;
On 11/4/22 8:17 AM, Maxime Ripard wrote:
The Davinci DA8xxx cfgchip "clk48" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
The parent is defined in the device tree and is not expected to change at runtime, so if I am understanding the patch correctly, setting the CLK_SET_RATE_NO_REPARENT flag seems correct.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/davinci/da8xx-cfgchip.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c b/drivers/clk/davinci/da8xx-cfgchip.c index c04276bc4051..4c1cc59bba53 100644 --- a/drivers/clk/davinci/da8xx-cfgchip.c +++ b/drivers/clk/davinci/da8xx-cfgchip.c @@ -565,6 +565,7 @@ static u8 da8xx_usb1_clk48_get_parent(struct clk_hw *hw) }
static const struct clk_ops da8xx_usb1_clk48_ops = {
- .determine_rate = __clk_mux_determine_rate, .set_parent = da8xx_usb1_clk48_set_parent, .get_parent = da8xx_usb1_clk48_get_parent, };
@@ -589,6 +590,7 @@ da8xx_cfgchip_register_usb1_clk48(struct device *dev,
init.name = "usb1_clk48"; init.ops = &da8xx_usb1_clk48_ops;
- init.flags = CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; init.num_parents = 2;
The iMX busy clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/imx/clk-busy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-busy.c b/drivers/clk/imx/clk-busy.c index 6f17311647f3..2df81862782a 100644 --- a/drivers/clk/imx/clk-busy.c +++ b/drivers/clk/imx/clk-busy.c @@ -148,6 +148,7 @@ static int clk_busy_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_busy_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_busy_mux_get_parent, .set_parent = clk_busy_mux_set_parent, }; @@ -176,7 +177,7 @@ struct clk_hw *imx_clk_hw_busy_mux(const char *name, void __iomem *reg, u8 shift
init.name = name; init.ops = &clk_busy_mux_ops; - init.flags = CLK_IS_CRITICAL; + init.flags = CLK_IS_CRITICAL | CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; init.num_parents = num_parents;
The iMX fixup mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/imx/clk-fixup-mux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-fixup-mux.c b/drivers/clk/imx/clk-fixup-mux.c index c82401570c84..e32c3b22ff05 100644 --- a/drivers/clk/imx/clk-fixup-mux.c +++ b/drivers/clk/imx/clk-fixup-mux.c @@ -60,6 +60,7 @@ static int clk_fixup_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_fixup_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_fixup_mux_get_parent, .set_parent = clk_fixup_mux_set_parent, }; @@ -84,7 +85,7 @@ struct clk_hw *imx_clk_hw_fixup_mux(const char *name, void __iomem *reg, init.ops = &clk_fixup_mux_ops; init.parent_names = parents; init.num_parents = num_parents; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT;
fixup_mux->mux.reg = reg; fixup_mux->mux.shift = shift;
The iMX SCU mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/imx/clk-scu.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c index 1e6870f3671f..66e49fea5f8a 100644 --- a/drivers/clk/imx/clk-scu.c +++ b/drivers/clk/imx/clk-scu.c @@ -785,6 +785,7 @@ static int clk_gpr_mux_scu_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_gpr_mux_scu_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_gpr_mux_scu_get_parent, .set_parent = clk_gpr_mux_scu_set_parent, }; @@ -836,7 +837,7 @@ struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_na struct imx_scu_clk_node *clk_node; struct clk_gpr_scu *clk; struct clk_hw *hw; - struct clk_init_data init; + struct clk_init_data init = {}; int ret;
if (rsrc_id >= IMX_SC_R_LAST || gpr_id >= IMX_SC_C_LAST) @@ -868,10 +869,11 @@ struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_na if (flags & IMX_SCU_GPR_CLK_DIV) init.ops = &clk_gpr_div_scu_ops;
- if (flags & IMX_SCU_GPR_CLK_MUX) + if (flags & IMX_SCU_GPR_CLK_MUX) { init.ops = &clk_gpr_mux_scu_ops; + init.flags |= CLK_SET_RATE_NO_REPARENT; + }
- init.flags = 0; init.name = name; init.parent_names = parent_name; init.num_parents = num_parents;
The Mediatek cpumux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/mediatek/clk-cpumux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-cpumux.c b/drivers/clk/mediatek/clk-cpumux.c index 25618eff6f2a..514807ae4903 100644 --- a/drivers/clk/mediatek/clk-cpumux.c +++ b/drivers/clk/mediatek/clk-cpumux.c @@ -53,6 +53,7 @@ static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_cpumux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_cpumux_get_parent, .set_parent = clk_cpumux_set_parent, }; @@ -73,7 +74,7 @@ mtk_clk_register_cpumux(const struct mtk_composite *mux, init.ops = &clk_cpumux_ops; init.parent_names = mux->parent_names; init.num_parents = mux->num_parents; - init.flags = mux->flags; + init.flags = mux->flags | CLK_SET_RATE_NO_REPARENT;
cpumux->reg = mux->mux_reg; cpumux->shift = mux->mux_shift;
The PXA "CKEN" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the set_parent implementation is a nop though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/pxa/clk-pxa.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/pxa/clk-pxa.c b/drivers/clk/pxa/clk-pxa.c index 374098ebbf2b..47bc60c2854c 100644 --- a/drivers/clk/pxa/clk-pxa.c +++ b/drivers/clk/pxa/clk-pxa.c @@ -82,6 +82,7 @@ static u8 cken_get_parent(struct clk_hw *hw) }
static const struct clk_ops cken_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = cken_get_parent, .set_parent = dummy_clk_set_parent, }; @@ -117,7 +118,7 @@ int __init clk_pxa_cken_init(const struct desc_clk_cken *clks, &pxa_clk->hw, &cken_mux_ops, &pxa_clk->hw, &cken_rate_ops, &pxa_clk->gate.hw, &clk_gate_ops, - clks[i].flags); + clks[i].flags | CLK_SET_RATE_NO_REPARENT); clkdev_pxa_register(clks[i].ckid, clks[i].con_id, clks[i].dev_id, clk); }
The Renesas r9a06g032 bitselect clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/renesas/r9a06g032-clocks.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c index 983faa5707b9..70c37097ca6e 100644 --- a/drivers/clk/renesas/r9a06g032-clocks.c +++ b/drivers/clk/renesas/r9a06g032-clocks.c @@ -773,6 +773,7 @@ static int r9a06g032_clk_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_bitselect_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = r9a06g032_clk_mux_get_parent, .set_parent = r9a06g032_clk_mux_set_parent, }; @@ -797,7 +798,7 @@ r9a06g032_register_bitsel(struct r9a06g032_priv *clocks,
init.name = desc->name; init.ops = &clk_bitselect_ops; - init.flags = CLK_SET_RATE_PARENT; + init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT; init.parent_names = names; init.num_parents = 2;
CC Gareth
On Fri, Nov 4, 2022 at 2:18 PM Maxime Ripard maxime@cerno.tech wrote:
The Renesas r9a06g032 bitselect clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/renesas/r9a06g032-clocks.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c index 983faa5707b9..70c37097ca6e 100644 --- a/drivers/clk/renesas/r9a06g032-clocks.c +++ b/drivers/clk/renesas/r9a06g032-clocks.c @@ -773,6 +773,7 @@ static int r9a06g032_clk_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_bitselect_ops = {
.determine_rate = __clk_mux_determine_rate, .get_parent = r9a06g032_clk_mux_get_parent, .set_parent = r9a06g032_clk_mux_set_parent,}; @@ -797,7 +798,7 @@ r9a06g032_register_bitsel(struct r9a06g032_priv *clocks,
init.name = desc->name; init.ops = &clk_bitselect_ops;
init.flags = CLK_SET_RATE_PARENT;
init.flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT; init.parent_names = names; init.num_parents = 2;-- b4 0.11.0-dev-99e3a
The SoCFGPA gate clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/socfpga/clk-gate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c index 53d6e3ec4309..261fe2fac982 100644 --- a/drivers/clk/socfpga/clk-gate.c +++ b/drivers/clk/socfpga/clk-gate.c @@ -164,6 +164,7 @@ static int socfpga_clk_prepare(struct clk_hw *hwclk) static struct clk_ops gateclk_ops = { .prepare = socfpga_clk_prepare, .recalc_rate = socfpga_clk_recalc_rate, + .determine_rate = __clk_mux_determine_rate, .get_parent = socfpga_clk_get_parent, .set_parent = socfpga_clk_set_parent, }; @@ -228,7 +229,7 @@ void __init socfpga_gate_init(struct device_node *node)
init.name = clk_name; init.ops = ops; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT;
init.num_parents = of_clk_parent_fill(node, parent_name, SOCFPGA_MAX_PARENTS); if (init.num_parents < 2) {
The STM32 mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/stm32/clk-stm32-core.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/clk/stm32/clk-stm32-core.c b/drivers/clk/stm32/clk-stm32-core.c index 45a279e73779..3247539683c9 100644 --- a/drivers/clk/stm32/clk-stm32-core.c +++ b/drivers/clk/stm32/clk-stm32-core.c @@ -275,6 +275,7 @@ static int clk_stm32_mux_set_parent(struct clk_hw *hw, u8 index) }
const struct clk_ops clk_stm32_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_stm32_mux_get_parent, .set_parent = clk_stm32_mux_set_parent, };
The Tegra BPMP mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/tegra/clk-bpmp.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c index d82a71f10c2c..6aea1cefbb80 100644 --- a/drivers/clk/tegra/clk-bpmp.c +++ b/drivers/clk/tegra/clk-bpmp.c @@ -286,6 +286,7 @@ static const struct clk_ops tegra_bpmp_clk_mux_ops = { .unprepare = tegra_bpmp_clk_unprepare, .is_prepared = tegra_bpmp_clk_is_prepared, .recalc_rate = tegra_bpmp_clk_recalc_rate, + .determine_rate = __clk_mux_determine_rate, .set_parent = tegra_bpmp_clk_set_parent, .get_parent = tegra_bpmp_clk_get_parent, }; @@ -512,10 +513,12 @@ tegra_bpmp_clk_register(struct tegra_bpmp *bpmp, clk->hw.init = &init;
if (info->flags & TEGRA_BPMP_CLK_HAS_MUX) { - if (info->flags & TEGRA_BPMP_CLK_HAS_SET_RATE) + if (info->flags & TEGRA_BPMP_CLK_HAS_SET_RATE) { init.ops = &tegra_bpmp_clk_mux_rate_ops; - else + } else { init.ops = &tegra_bpmp_clk_mux_ops; + init.flags |= CLK_SET_RATE_NO_REPARENT; + } } else { if (info->flags & TEGRA_BPMP_CLK_HAS_SET_RATE) init.ops = &tegra_bpmp_clk_rate_ops;
The Tegra super mux clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/tegra/clk-super.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/tegra/clk-super.c b/drivers/clk/tegra/clk-super.c index a98a420398fa..8ad62e04fd8b 100644 --- a/drivers/clk/tegra/clk-super.c +++ b/drivers/clk/tegra/clk-super.c @@ -136,6 +136,7 @@ static void clk_super_mux_restore_context(struct clk_hw *hw) }
static const struct clk_ops tegra_clk_super_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_super_get_parent, .set_parent = clk_super_set_parent, .restore_context = clk_super_mux_restore_context, @@ -212,7 +213,7 @@ struct clk *tegra_clk_register_super_mux(const char *name,
init.name = name; init.ops = &tegra_clk_super_mux_ops; - init.flags = flags; + init.flags = flags | CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; init.num_parents = num_parents;
The Tegra periph nodiv clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/tegra/clk-periph.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c index 79ca3aa072b7..367396c62259 100644 --- a/drivers/clk/tegra/clk-periph.c +++ b/drivers/clk/tegra/clk-periph.c @@ -140,6 +140,7 @@ const struct clk_ops tegra_clk_periph_ops = { };
static const struct clk_ops tegra_clk_periph_nodiv_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_periph_get_parent, .set_parent = clk_periph_set_parent, .is_enabled = clk_periph_is_enabled, @@ -170,7 +171,7 @@ static struct clk *_tegra_clk_register_periph(const char *name, bool div = !(periph->gate.flags & TEGRA_PERIPH_NO_DIV);
if (periph->gate.flags & TEGRA_PERIPH_NO_DIV) { - flags |= CLK_SET_RATE_PARENT; + flags |= CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT; init.ops = &tegra_clk_periph_nodiv_ops; } else if (periph->gate.flags & TEGRA_PERIPH_NO_GATE) init.ops = &tegra_clk_periph_no_gate_ops;
The UX500 PRCMU "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/ux500/clk-prcmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ux500/clk-prcmu.c b/drivers/clk/ux500/clk-prcmu.c index 4deb37f19a7c..7118991f3731 100644 --- a/drivers/clk/ux500/clk-prcmu.c +++ b/drivers/clk/ux500/clk-prcmu.c @@ -344,6 +344,7 @@ static const struct clk_ops clk_prcmu_clkout_ops = { .prepare = clk_prcmu_clkout_prepare, .unprepare = clk_prcmu_clkout_unprepare, .recalc_rate = clk_prcmu_clkout_recalc_rate, + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_prcmu_clkout_get_parent, .set_parent = clk_prcmu_clkout_set_parent, }; @@ -383,7 +384,7 @@ struct clk_hw *clk_reg_prcmu_clkout(const char *name,
clk_prcmu_clkout_init.name = name; clk_prcmu_clkout_init.ops = &clk_prcmu_clkout_ops; - clk_prcmu_clkout_init.flags = CLK_GET_RATE_NOCACHE; + clk_prcmu_clkout_init.flags = CLK_GET_RATE_NOCACHE | CLK_SET_RATE_NO_REPARENT; clk_prcmu_clkout_init.parent_names = parent_names; clk_prcmu_clkout_init.num_parents = num_parents; clk->hw.init = &clk_prcmu_clkout_init;
On Fri, Nov 4, 2022 at 2:32 PM Maxime Ripard maxime@cerno.tech wrote:
The UX500 PRCMU "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
It is actually set up from the device tree, typically like this:
/* clkout1 from ACLK divided by 8 */ clocks = <&clkout_clk DB8500_CLKOUT_1 DB8500_CLKOUT_SRC_ACLK 8>;
So the parent (source) and divisor comes in there.
clk->source and clk->divider is already set up when clk_hw_register() is called.
So set/get_parent() is never used on clkout.
I think I just added the callbacks for completeness, should we delete them altogether? The patch is probably fine as-is as well so Acked-by: Linus Walleij linus.walleij@linaro.org
Yours, Linus Walleij
Hi Linus,
On Tue, Nov 08, 2022 at 02:25:04PM +0100, Linus Walleij wrote:
On Fri, Nov 4, 2022 at 2:32 PM Maxime Ripard maxime@cerno.tech wrote:
The UX500 PRCMU "clkout" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
It is actually set up from the device tree, typically like this:
/* clkout1 from ACLK divided by 8 */ clocks = <&clkout_clk DB8500_CLKOUT_1 DB8500_CLKOUT_SRC_ACLK 8>;
So the parent (source) and divisor comes in there.
clk->source and clk->divider is already set up when clk_hw_register() is called.
I wasn't aware that we had such bindings. AFAIUI, it looks redundant with assigned-clock-rates and assigned-clock-parents, could we deprecate it?
So set/get_parent() is never used on clkout.
I think I just added the callbacks for completeness, should we delete them altogether?
I can't really test any of these platforms, so I'm a bit wary of making such changes myself. Feel free to send a follow-up if you think it's needed :)
The patch is probably fine as-is as well so Acked-by: Linus Walleij linus.walleij@linaro.org
Thanks! Maxime
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/ux500/clk-sysctrl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c index 702f2f8b43fa..d36336665b6d 100644 --- a/drivers/clk/ux500/clk-sysctrl.c +++ b/drivers/clk/ux500/clk-sysctrl.c @@ -110,6 +110,7 @@ static const struct clk_ops clk_sysctrl_gate_fixed_rate_ops = { };
static const struct clk_ops clk_sysctrl_set_parent_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = clk_sysctrl_set_parent, .get_parent = clk_sysctrl_get_parent, }; @@ -220,6 +221,7 @@ struct clk *clk_reg_sysctrl_set_parent(struct device *dev, unsigned long flags) { return clk_reg_sysctrl(dev, name, parent_names, num_parents, - reg_sel, reg_mask, reg_bits, 0, 0, flags, + reg_sel, reg_mask, reg_bits, 0, 0, + flags | CLK_SET_RATE_NO_REPARENT, &clk_sysctrl_set_parent_ops); }
On Fri, Nov 4, 2022 at 2:32 PM Maxime Ripard maxime@cerno.tech wrote:
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech
Acked-by: Linus Walleij linus.walleij@linaro.org
Yours, Linus Walleij
On Fri, 4 Nov 2022 at 14:32, Maxime Ripard maxime@cerno.tech wrote:
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
If I recall correctly, that is the use case we did target for these types of clocks. See sound/soc/ux500/ux500_ab85xx.c, for example.
Maybe there are some additional pieces missing from the old down stream kernel, I don't have full picture, sorry.
Anyway, if I am not wrong, this was about supporting a low-power audio use case, which requires us to switch the parent clock (to avoid wasting energy).
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
Yes, this was the reason.
As a matter of fact, I don't even recall that re-parenting was possible through clk_set_rate() when this clock driver was introduced. But, I might be wrong, it's quite a while ago.
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech
Seems reasonable to me!
Reviewed-by: Ulf Hansson ulf.hansson@linaro.org
Kind regards Uffe
drivers/clk/ux500/clk-sysctrl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c index 702f2f8b43fa..d36336665b6d 100644 --- a/drivers/clk/ux500/clk-sysctrl.c +++ b/drivers/clk/ux500/clk-sysctrl.c @@ -110,6 +110,7 @@ static const struct clk_ops clk_sysctrl_gate_fixed_rate_ops = { };
static const struct clk_ops clk_sysctrl_set_parent_ops = {
.determine_rate = __clk_mux_determine_rate, .set_parent = clk_sysctrl_set_parent, .get_parent = clk_sysctrl_get_parent,}; @@ -220,6 +221,7 @@ struct clk *clk_reg_sysctrl_set_parent(struct device *dev, unsigned long flags) { return clk_reg_sysctrl(dev, name, parent_names, num_parents,
reg_sel, reg_mask, reg_bits, 0, 0, flags,
reg_sel, reg_mask, reg_bits, 0, 0,flags | CLK_SET_RATE_NO_REPARENT, &clk_sysctrl_set_parent_ops);}
-- b4 0.11.0-dev-99e3a
On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson ulf.hansson@linaro.org wrote:
On Fri, 4 Nov 2022 at 14:32, Maxime Ripard maxime@cerno.tech wrote:
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
If I recall correctly, that is the use case we did target for these types of clocks. See sound/soc/ux500/ux500_ab85xx.c, for example.
Hm I am trying to get that driver to work ... from time to time. It's just that ALSA SoC DT has changed to much that it turns out into a complete rewrite :/
So in sound/soc/ux500/mop500_ab8500.c I see this:
status = clk_set_parent(drvdata->clk_ptr_intclk, clk_ptr); if (status) (...)
and there is elaborate code to switch between "SYSCLK" and "ULPCLK" (ulta-low power clock). Just like you say... however a clock named SYSCLK or ULPCLK does not appear in the code in drivers/clk/ux500 or any DT bindings so... it seems to be non-working for the time being.
Yours, Linus Walleij
On Thu, 10 Nov 2022 at 12:39, Linus Walleij linus.walleij@linaro.org wrote:
On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson ulf.hansson@linaro.org wrote:
On Fri, 4 Nov 2022 at 14:32, Maxime Ripard maxime@cerno.tech wrote:
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
If I recall correctly, that is the use case we did target for these types of clocks. See sound/soc/ux500/ux500_ab85xx.c, for example.
Hm I am trying to get that driver to work ... from time to time. It's just that ALSA SoC DT has changed to much that it turns out into a complete rewrite :/
So in sound/soc/ux500/mop500_ab8500.c I see this:
status = clk_set_parent(drvdata->clk_ptr_intclk, clk_ptr); if (status)(...)
and there is elaborate code to switch between "SYSCLK" and "ULPCLK" (ulta-low power clock). Just like you say... however a clock named SYSCLK or ULPCLK does not appear in the code in drivers/clk/ux500 or any DT bindings so... it seems to be non-working for the time being.
It's definitely not working, but the corresponding clocks ("ulpclk", "intclk", "audioclk", etc) are being registered in ab8500_reg_clks().
What seems to be missing is a DT conversion for these clocks, so they can be consumed properly. Right?
Kind regards Uffe
On Thu, Nov 10, 2022 at 2:05 PM Ulf Hansson ulf.hansson@linaro.org wrote:
On Thu, 10 Nov 2022 at 12:39, Linus Walleij linus.walleij@linaro.org wrote:
On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson ulf.hansson@linaro.org wrote:
On Fri, 4 Nov 2022 at 14:32, Maxime Ripard maxime@cerno.tech wrote:
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
If I recall correctly, that is the use case we did target for these types of clocks. See sound/soc/ux500/ux500_ab85xx.c, for example.
Hm I am trying to get that driver to work ... from time to time. It's just that ALSA SoC DT has changed to much that it turns out into a complete rewrite :/
So in sound/soc/ux500/mop500_ab8500.c I see this:
status = clk_set_parent(drvdata->clk_ptr_intclk, clk_ptr); if (status)(...)
and there is elaborate code to switch between "SYSCLK" and "ULPCLK" (ulta-low power clock). Just like you say... however a clock named SYSCLK or ULPCLK does not appear in the code in drivers/clk/ux500 or any DT bindings so... it seems to be non-working for the time being.
It's definitely not working, but the corresponding clocks ("ulpclk", "intclk", "audioclk", etc) are being registered in ab8500_reg_clks().
What seems to be missing is a DT conversion for these clocks, so they can be consumed properly. Right?
Yeps that and a few more things, I have a scratch rewrite here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/...
I remember Lee said he had audio working with the mainline kernel on Snowball at one point, unfortunately I think that was before we started with the DT conversions and then we probably broke it.
Yours, Linus Walleij
On Fri, 11 Nov 2022, Linus Walleij wrote:
On Thu, Nov 10, 2022 at 2:05 PM Ulf Hansson ulf.hansson@linaro.org wrote:
On Thu, 10 Nov 2022 at 12:39, Linus Walleij linus.walleij@linaro.org wrote:
On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson ulf.hansson@linaro.org wrote:
On Fri, 4 Nov 2022 at 14:32, Maxime Ripard maxime@cerno.tech wrote:
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
If I recall correctly, that is the use case we did target for these types of clocks. See sound/soc/ux500/ux500_ab85xx.c, for example.
Hm I am trying to get that driver to work ... from time to time. It's just that ALSA SoC DT has changed to much that it turns out into a complete rewrite :/
So in sound/soc/ux500/mop500_ab8500.c I see this:
status = clk_set_parent(drvdata->clk_ptr_intclk, clk_ptr); if (status)(...)
and there is elaborate code to switch between "SYSCLK" and "ULPCLK" (ulta-low power clock). Just like you say... however a clock named SYSCLK or ULPCLK does not appear in the code in drivers/clk/ux500 or any DT bindings so... it seems to be non-working for the time being.
It's definitely not working, but the corresponding clocks ("ulpclk", "intclk", "audioclk", etc) are being registered in ab8500_reg_clks().
What seems to be missing is a DT conversion for these clocks, so they can be consumed properly. Right?
Yeps that and a few more things, I have a scratch rewrite here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/...
I remember Lee said he had audio working with the mainline kernel on Snowball at one point, unfortunately I think that was before we started with the DT conversions and then we probably broke it.
That was also 100 years ago. :)
But yes, it used to work at one point.
The Versatile sp810 "timerclken" clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/versatile/clk-sp810.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/versatile/clk-sp810.c b/drivers/clk/versatile/clk-sp810.c index caf0cd2fb5b6..a45b1b7b7d49 100644 --- a/drivers/clk/versatile/clk-sp810.c +++ b/drivers/clk/versatile/clk-sp810.c @@ -63,6 +63,7 @@ static int clk_sp810_timerclken_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops clk_sp810_timerclken_ops = { + .determine_rate = __clk_mux_determine_rate, .get_parent = clk_sp810_timerclken_get_parent, .set_parent = clk_sp810_timerclken_set_parent, }; @@ -105,7 +106,7 @@ static void __init clk_sp810_of_setup(struct device_node *node)
init.name = name; init.ops = &clk_sp810_timerclken_ops; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT; init.parent_names = parent_names; init.num_parents = num;
The Tegra sor pad clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/gpu/drm/tegra/sor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index 8af632740673..92084a9a67c5 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -586,6 +586,7 @@ static u8 tegra_clk_sor_pad_get_parent(struct clk_hw *hw) }
static const struct clk_ops tegra_clk_sor_pad_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = tegra_clk_sor_pad_set_parent, .get_parent = tegra_clk_sor_pad_get_parent, }; @@ -604,7 +605,7 @@ static struct clk *tegra_clk_sor_pad_register(struct tegra_sor *sor, pad->sor = sor;
init.name = name; - init.flags = 0; + init.flags = CLK_SET_RATE_NO_REPARENT; init.parent_names = tegra_clk_sor_pad_parents[sor->index]; init.num_parents = ARRAY_SIZE(tegra_clk_sor_pad_parents[sor->index]); init.ops = &tegra_clk_sor_pad_ops;
The Cadence Sierra PLL clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/phy/cadence/phy-cadence-sierra.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c index 6e86a6517f37..403f8eba9fe5 100644 --- a/drivers/phy/cadence/phy-cadence-sierra.c +++ b/drivers/phy/cadence/phy-cadence-sierra.c @@ -709,6 +709,7 @@ static int cdns_sierra_pll_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops cdns_sierra_pll_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = cdns_sierra_pll_mux_set_parent, .get_parent = cdns_sierra_pll_mux_get_parent, };
The Cadence Torrent refclk clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/phy/cadence/phy-cadence-torrent.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/phy/cadence/phy-cadence-torrent.c b/drivers/phy/cadence/phy-cadence-torrent.c index f099053c583c..be65b05ec41d 100644 --- a/drivers/phy/cadence/phy-cadence-torrent.c +++ b/drivers/phy/cadence/phy-cadence-torrent.c @@ -1861,6 +1861,7 @@ static const struct clk_ops cdns_torrent_refclk_driver_ops = { .enable = cdns_torrent_refclk_driver_enable, .disable = cdns_torrent_refclk_driver_disable, .is_enabled = cdns_torrent_refclk_driver_is_enabled, + .determine_rate = __clk_mux_determine_rate, .set_parent = cdns_torrent_refclk_driver_set_parent, .get_parent = cdns_torrent_refclk_driver_get_parent, };
The TI AM654 SerDes clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/phy/ti/phy-am654-serdes.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/phy/ti/phy-am654-serdes.c b/drivers/phy/ti/phy-am654-serdes.c index 0be727bb9f79..f2061ce4e62d 100644 --- a/drivers/phy/ti/phy-am654-serdes.c +++ b/drivers/phy/ti/phy-am654-serdes.c @@ -634,6 +634,7 @@ static int serdes_am654_clk_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops serdes_am654_clk_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = serdes_am654_clk_mux_set_parent, .get_parent = serdes_am654_clk_mux_get_parent, };
The TI J721e Wiz clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Since the CLK_SET_RATE_NO_REPARENT flag was already set though, it seems unlikely.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/phy/ti/phy-j721e-wiz.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c index 141b51af4427..bd0691e5de47 100644 --- a/drivers/phy/ti/phy-j721e-wiz.c +++ b/drivers/phy/ti/phy-j721e-wiz.c @@ -781,6 +781,7 @@ static int wiz_clk_mux_set_parent(struct clk_hw *hw, u8 index) }
static const struct clk_ops wiz_clk_mux_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = wiz_clk_mux_set_parent, .get_parent = wiz_clk_mux_get_parent, };
The Allwinner sun6i RTC clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/rtc/rtc-sun6i.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c index ed5516089e9a..a2781502c244 100644 --- a/drivers/rtc/rtc-sun6i.c +++ b/drivers/rtc/rtc-sun6i.c @@ -215,6 +215,7 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw, u8 index)
static const struct clk_ops sun6i_rtc_osc_ops = { .recalc_rate = sun6i_rtc_osc_recalc_rate, + .determine_rate = __clk_mux_determine_rate,
.get_parent = sun6i_rtc_osc_get_parent, .set_parent = sun6i_rtc_osc_set_parent, @@ -228,6 +229,7 @@ static void __init sun6i_rtc_clk_init(struct device_node *node, struct clk_init_data init = { .ops = &sun6i_rtc_osc_ops, .name = "losc", + .flags = CLK_SET_RATE_NO_REPARENT, }; const char *iosc_name = "rtc-int-osc"; const char *clkout_name = "osc32k-out";
The tlv320aic32x4 clkin clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- sound/soc/codecs/tlv320aic32x4-clk.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c index 2f78e6820c75..65b72373cb95 100644 --- a/sound/soc/codecs/tlv320aic32x4-clk.c +++ b/sound/soc/codecs/tlv320aic32x4-clk.c @@ -41,6 +41,7 @@ struct aic32x4_clkdesc { const char * const *parent_names; unsigned int num_parents; const struct clk_ops *ops; + unsigned long flags; unsigned int reg; };
@@ -292,6 +293,7 @@ static u8 clk_aic32x4_codec_clkin_get_parent(struct clk_hw *hw) }
static const struct clk_ops aic32x4_codec_clkin_ops = { + .determine_rate = __clk_mux_determine_rate, .set_parent = clk_aic32x4_codec_clkin_set_parent, .get_parent = clk_aic32x4_codec_clkin_get_parent, }; @@ -401,6 +403,7 @@ static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = { (const char *[]) { "mclk", "bclk", "gpio", "pll" }, .num_parents = 4, .ops = &aic32x4_codec_clkin_ops, + .flags = CLK_SET_RATE_NO_REPARENT, .reg = 0, }, { @@ -452,7 +455,7 @@ static struct clk *aic32x4_register_clk(struct device *dev, init.name = desc->name; init.parent_names = desc->parent_names; init.num_parents = desc->num_parents; - init.flags = 0; + init.flags = desc->flags;
priv = devm_kzalloc(dev, sizeof(struct clk_aic32x4), GFP_KERNEL); if (priv == NULL)
On Fri, Nov 04, 2022 at 02:18:00PM +0100, Maxime Ripard wrote:
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Given that the current approach involves patching every single user to set a default implementation it feels like it might be more straightforward to just have the clock API use that implementation if none is defined - as you say there's already a flag to indicate the unusual case where there's a solid reason to prevent reparenting. It feels like the resulting API is more straightforward.
Hi Mark,
On Fri, Nov 04, 2022 at 03:44:53PM +0000, Mark Brown wrote:
On Fri, Nov 04, 2022 at 02:18:00PM +0100, Maxime Ripard wrote:
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the flag CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook to __clk_mux_determine_rate(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. __clk_mux_determine_rate() has the exact same behavior when CLK_SET_RATE_NO_REPARENT is set.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Given that the current approach involves patching every single user to set a default implementation it feels like it might be more straightforward to just have the clock API use that implementation if none is defined - as you say there's already a flag to indicate the unusual case where there's a solid reason to prevent reparenting. It feels like the resulting API is more straightforward.
That would be another solution indeed. The thing is, most places where determine_rate is missing seems to be oversight, and the flag is missing as well.
Just filling determine_rate if it's missing with __clk_mux_determine_rate will possibly pick different parents, and I'm fairly certain that this have never been tested on most platforms, and will be completely broken. And I don't really want to play a game of whack-a-mole adding that flag everywhere it turns out it's broken.
Maxime
On Fri, Nov 04, 2022 at 04:51:23PM +0100, Maxime Ripard wrote:
Just filling determine_rate if it's missing with __clk_mux_determine_rate will possibly pick different parents, and I'm fairly certain that this have never been tested on most platforms, and will be completely broken. And I don't really want to play a game of whack-a-mole adding that flag everywhere it turns out it's broken.
Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged?
Hi Mark,
On Fri, Nov 04, 2022 at 03:59:53PM +0000, Mark Brown wrote:
On Fri, Nov 04, 2022 at 04:51:23PM +0100, Maxime Ripard wrote:
Just filling determine_rate if it's missing with __clk_mux_determine_rate will possibly pick different parents, and I'm fairly certain that this have never been tested on most platforms, and will be completely broken. And I don't really want to play a game of whack-a-mole adding that flag everywhere it turns out it's broken.
Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged?
I'm sorry, I'm not sure what you mean here. The only issue to fix at the moment is that determine_rate and set_parent aren't coupled, and it led to issues due to oversight.
I initially added a warning but Stephen wanted to fix all users in that case and make that an error instead.
If I filled __clk_mux_determine_rate into clocks that weren't using it before, I would change their behavior. With that flag set, on all users I add __clk_mux_determine_rate to, the behavior is the same than what we previously had, so the risk of regressions is minimal, and everything should keep going like it was?
Maxime
On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote:
On Fri, Nov 04, 2022 at 03:59:53PM +0000, Mark Brown wrote:
Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged?
I'm sorry, I'm not sure what you mean here. The only issue to fix at the moment is that determine_rate and set_parent aren't coupled, and it led to issues due to oversight.
I initially added a warning but Stephen wanted to fix all users in that case and make that an error instead.
My suggestion is that instead of doing either of these things it'd be quicker and less error prone to just fix the core to provide the default implementation if nothing more specific is provided. Any issues that causes would already be present with your current series.
If I filled __clk_mux_determine_rate into clocks that weren't using it before, I would change their behavior. With that flag set, on all users I add __clk_mux_determine_rate to, the behavior is the same than what we previously had, so the risk of regressions is minimal, and everything should keep going like it was?
The series does fill in __clk_mux_determine_rate for everything though - if it was just assumed by default the only thing that'd be needed would be adding the flag.
On Mon, Nov 07, 2022 at 12:06:07PM +0000, Mark Brown wrote:
On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote:
On Fri, Nov 04, 2022 at 03:59:53PM +0000, Mark Brown wrote:
Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged?
I'm sorry, I'm not sure what you mean here. The only issue to fix at the moment is that determine_rate and set_parent aren't coupled, and it led to issues due to oversight.
I initially added a warning but Stephen wanted to fix all users in that case and make that an error instead.
My suggestion is that instead of doing either of these things it'd be quicker and less error prone to just fix the core to provide the default implementation if nothing more specific is provided. Any issues that causes would already be present with your current series.
If I filled __clk_mux_determine_rate into clocks that weren't using it before, I would change their behavior. With that flag set, on all users I add __clk_mux_determine_rate to, the behavior is the same than what we previously had, so the risk of regressions is minimal, and everything should keep going like it was?
The series does fill in __clk_mux_determine_rate for everything though - if it was just assumed by default the only thing that'd be needed would be adding the flag.
The behavior assumed by default was equivalent to __clk_mux_determine_rate + CLK_SET_RATE_NO_REPARENT. We could indeed set both if determine_rate is missing in the core, but that's unprecedented in the clock framework so I think we'll want Stephen to comment here :)
It's also replacing one implicit behavior by another. The point of this series was to raise awareness on that particular point, so I'm not sure it actually fixes things. We'll see what Stephen thinks about it.
Maxime
On Mon, Nov 07, 2022 at 04:26:03PM +0100, Maxime Ripard wrote:
On Mon, Nov 07, 2022 at 12:06:07PM +0000, Mark Brown wrote:
On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote:
The series does fill in __clk_mux_determine_rate for everything though - if it was just assumed by default the only thing that'd be needed would be adding the flag.
The behavior assumed by default was equivalent to __clk_mux_determine_rate + CLK_SET_RATE_NO_REPARENT. We could indeed set both if determine_rate is missing in the core, but that's unprecedented in the clock framework so I think we'll want Stephen to comment here :)
It's also replacing one implicit behavior by another. The point of this series was to raise awareness on that particular point, so I'm not sure it actually fixes things. We'll see what Stephen thinks about it.
We could also just set the operation and still require the flag to be specified. I'm a little surprised to learn that it's something you might want to override, never mind that the API didn't have a default - it feels like a bit of a landmine that this is the case and is probably why there's so many cases to fix up.
Quoting Maxime Ripard (2022-11-07 07:26:03)
On Mon, Nov 07, 2022 at 12:06:07PM +0000, Mark Brown wrote:
On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote:
On Fri, Nov 04, 2022 at 03:59:53PM +0000, Mark Brown wrote:
Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged?
I'm sorry, I'm not sure what you mean here. The only issue to fix at the moment is that determine_rate and set_parent aren't coupled, and it led to issues due to oversight.
I initially added a warning but Stephen wanted to fix all users in that case and make that an error instead.
My suggestion is that instead of doing either of these things it'd be quicker and less error prone to just fix the core to provide the default implementation if nothing more specific is provided. Any issues that causes would already be present with your current series.
If I filled __clk_mux_determine_rate into clocks that weren't using it before, I would change their behavior. With that flag set, on all users I add __clk_mux_determine_rate to, the behavior is the same than what we previously had, so the risk of regressions is minimal, and everything should keep going like it was?
The series does fill in __clk_mux_determine_rate for everything though - if it was just assumed by default the only thing that'd be needed would be adding the flag.
The behavior assumed by default was equivalent to __clk_mux_determine_rate + CLK_SET_RATE_NO_REPARENT. We could indeed set both if determine_rate is missing in the core, but that's unprecedented in the clock framework so I think we'll want Stephen to comment here :)
The clk_ops pointer is const (no writeable jump tables) so we'd have to copy the clk_ops struct on registration to set the __clk_mux_determine_rate() op. We could set the flag though and then check for the absence of a determine_rate op. Things like clk_core_can_round() would need to check for the flag. I'd actually forgotten about this flag. In hindsight I think we should delete it. I'd expect it to be used when walking the clk tree during rate rounding, but it's only used in the determine rate clk op.
It's also replacing one implicit behavior by another. The point of this series was to raise awareness on that particular point, so I'm not sure it actually fixes things. We'll see what Stephen thinks about it.
Right. A decade ago (!) when determine_rate() was introduced we introduced CLK_SET_RATE_NO_REPARENT and set it on each mux user (see commit 819c1de344c5 ("clk: add CLK_SET_RATE_NO_REPARENT flag")). This way driver behavior wouldn't change and the status quo would be maintained, i.e. that clk_set_rate() on a mux wouldn't change parents. We didn't enforce that determine_rate exists if the set_parent() op existed at the same time though. Probably an oversight.
Most of the replies to this series have been "DT is setting the parent", which makes me believe that there are 'assigned-clock-parents' being used. The clk_set_parent() path is valid for those cases. Probably nobody cares about determine_rate because they don't set rates on these clks. Some drivers even explicitly left out determine_rate()/round_rate() because they didn't want to have some other clk round up to the mux and change the parent.
Eventually we want drivers to migrate to determine_rate op so we can get rid of the round_rate op and save a pointer (we're so greedy). It's been 10 years though, and that hasn't been done. Sigh! I can see value in this series from the angle of migrating, but adding a determine_rate op when there isn't a round_rate op makes it hard to reason about. What if something copies the clk_ops or sets a different flag? Now we've just added parent changing support to clk_set_rate(). What if the clk has CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to change rate. Fun bugs.
TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't then the clk is a mux that doesn't want to support clk_set_rate(). Make a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT branch in clk_mux_determine_rate_flags() and call that directly from the clk_ops so it is clear what's happening, clk_hw_mux_same_parent_determine_rate() or something with a better name. Otherwise migrate the explicit determine_rate op to this new function and don't set the flag.
It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag with this design, if the determine_rate clk_op can call the inner wrapper function instead of __clk_mux_determine_rate*() (those underscores are awful, we should just prefix them with clk_hw_mux_*() and live happier). That should be another patch series.
Hi Stephen,
On Wed, Mar 22, 2023 at 04:31:04PM -0700, Stephen Boyd wrote:
It's also replacing one implicit behavior by another. The point of this series was to raise awareness on that particular point, so I'm not sure it actually fixes things. We'll see what Stephen thinks about it.
Right. A decade ago (!) when determine_rate() was introduced we introduced CLK_SET_RATE_NO_REPARENT and set it on each mux user (see commit 819c1de344c5 ("clk: add CLK_SET_RATE_NO_REPARENT flag")). This way driver behavior wouldn't change and the status quo would be maintained, i.e. that clk_set_rate() on a mux wouldn't change parents. We didn't enforce that determine_rate exists if the set_parent() op existed at the same time though. Probably an oversight.
Most of the replies to this series have been "DT is setting the parent", which makes me believe that there are 'assigned-clock-parents' being used.
Yes, that's my understanding as well.
The clk_set_parent() path is valid for those cases. Probably nobody cares about determine_rate because they don't set rates on these clks. Some drivers even explicitly left out determine_rate()/round_rate() because they didn't want to have some other clk round up to the mux and change the parent.
Eventually we want drivers to migrate to determine_rate op so we can get rid of the round_rate op and save a pointer (we're so greedy). It's been 10 years though, and that hasn't been done. Sigh! I can see value in this series from the angle of migrating, but adding a determine_rate op when there isn't a round_rate op makes it hard to reason about. What if something copies the clk_ops or sets a different flag? Now we've just added parent changing support to clk_set_rate(). What if the clk has CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to change rate. Fun bugs.
TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't then the clk is a mux that doesn't want to support clk_set_rate(). Make a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT branch in clk_mux_determine_rate_flags() and call that directly from the clk_ops so it is clear what's happening, clk_hw_mux_same_parent_determine_rate() or something with a better name. Otherwise migrate the explicit determine_rate op to this new function and don't set the flag.
It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag with this design, if the determine_rate clk_op can call the inner wrapper function instead of __clk_mux_determine_rate*() (those underscores are awful, we should just prefix them with clk_hw_mux_*() and live happier). That should be another patch series.
Sorry but it's not really clear to me what you expect in the v2 of this series (if you even expect one). It looks that you don't like the assignment-if-missing idea Mark suggested, but should I just rebase/resend or did you expect something else?
Maxime
Quoting Maxime Ripard (2023-03-29 12:50:49)
On Wed, Mar 22, 2023 at 04:31:04PM -0700, Stephen Boyd wrote:
The clk_set_parent() path is valid for those cases. Probably nobody cares about determine_rate because they don't set rates on these clks. Some drivers even explicitly left out determine_rate()/round_rate() because they didn't want to have some other clk round up to the mux and change the parent.
Eventually we want drivers to migrate to determine_rate op so we can get rid of the round_rate op and save a pointer (we're so greedy). It's been 10 years though, and that hasn't been done. Sigh! I can see value in this series from the angle of migrating, but adding a determine_rate op when there isn't a round_rate op makes it hard to reason about. What if something copies the clk_ops or sets a different flag? Now we've just added parent changing support to clk_set_rate(). What if the clk has CLK_SET_RATE_PARENT flag set? Now we're going to ask the parent clk to change rate. Fun bugs.
TL;DR: If the set_parent op exists but determine_rate/round_rate doesn't then the clk is a mux that doesn't want to support clk_set_rate(). Make a new mux function that's the contents of the CLK_SET_RATE_NO_REPARENT branch in clk_mux_determine_rate_flags() and call that directly from the clk_ops so it is clear what's happening, clk_hw_mux_same_parent_determine_rate() or something with a better name. Otherwise migrate the explicit determine_rate op to this new function and don't set the flag.
It may be possible to entirely remove the CLK_SET_RATE_NO_REPARENT flag with this design, if the determine_rate clk_op can call the inner wrapper function instead of __clk_mux_determine_rate*() (those underscores are awful, we should just prefix them with clk_hw_mux_*() and live happier). That should be another patch series.
Sorry but it's not really clear to me what you expect in the v2 of this series (if you even expect one). It looks that you don't like the assignment-if-missing idea Mark suggested, but should I just rebase/resend or did you expect something else?
Yes, we want explicit code. Just rebase & resend. Don't add a determine_rate if there isn't a round_rate. Don't add more users of CLK_SET_RATE_NO_REPARENT. Instead, make an explicit determine_rate function for that. If you want to work on the removal of CLK_SET_RATE_NO_REPARENT go for it. Otherwise I'll take care of it after this series.
The Actions composite divider clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/actions/owl-composite.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/actions/owl-composite.c b/drivers/clk/actions/owl-composite.c index 4c844a5613e4..d66b268563d0 100644 --- a/drivers/clk/actions/owl-composite.c +++ b/drivers/clk/actions/owl-composite.c @@ -53,13 +53,19 @@ static int owl_comp_is_enabled(struct clk_hw *hw) return owl_gate_clk_is_enabled(common, &comp->gate_hw); }
-static long owl_comp_div_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int owl_comp_div_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct owl_composite *comp = hw_to_owl_comp(hw); + long rate;
- return owl_divider_helper_round_rate(&comp->common, &comp->rate.div_hw, - rate, parent_rate); + rate = owl_divider_helper_round_rate(&comp->common, &comp->rate.div_hw, + req->rate, &req->best_parent_rate); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static unsigned long owl_comp_div_recalc_rate(struct clk_hw *hw, @@ -152,7 +158,7 @@ const struct clk_ops owl_comp_div_ops = { .is_enabled = owl_comp_is_enabled,
/* div_ops */ - .round_rate = owl_comp_div_round_rate, + .determine_rate = owl_comp_div_determine_rate, .recalc_rate = owl_comp_div_recalc_rate, .set_rate = owl_comp_div_set_rate, };
The Actions composite factor clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/actions/owl-composite.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/actions/owl-composite.c b/drivers/clk/actions/owl-composite.c index d66b268563d0..3cac8f0a80dc 100644 --- a/drivers/clk/actions/owl-composite.c +++ b/drivers/clk/actions/owl-composite.c @@ -86,14 +86,20 @@ static int owl_comp_div_set_rate(struct clk_hw *hw, unsigned long rate, rate, parent_rate); }
-static long owl_comp_fact_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int owl_comp_fact_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct owl_composite *comp = hw_to_owl_comp(hw); + long rate;
- return owl_factor_helper_round_rate(&comp->common, - &comp->rate.factor_hw, - rate, parent_rate); + rate = owl_factor_helper_round_rate(&comp->common, + &comp->rate.factor_hw, + req->rate, &req->best_parent_rate); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static unsigned long owl_comp_fact_recalc_rate(struct clk_hw *hw, @@ -175,7 +181,7 @@ const struct clk_ops owl_comp_fact_ops = { .is_enabled = owl_comp_is_enabled,
/* fact_ops */ - .round_rate = owl_comp_fact_round_rate, + .determine_rate = owl_comp_fact_determine_rate, .recalc_rate = owl_comp_fact_recalc_rate, .set_rate = owl_comp_fact_set_rate, };
The Atmel SAM9x5 SMD clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/at91/clk-smd.c | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c index 160378438f1b..09c649c8598e 100644 --- a/drivers/clk/at91/clk-smd.c +++ b/drivers/clk/at91/clk-smd.c @@ -36,26 +36,31 @@ static unsigned long at91sam9x5_clk_smd_recalc_rate(struct clk_hw *hw, return parent_rate / (smddiv + 1); }
-static long at91sam9x5_clk_smd_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int at91sam9x5_clk_smd_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { unsigned long div; unsigned long bestrate; unsigned long tmp;
- if (rate >= *parent_rate) - return *parent_rate; + if (req->rate >= req->best_parent_rate) { + req->rate = req->best_parent_rate; + return 0; + }
- div = *parent_rate / rate; - if (div > SMD_MAX_DIV) - return *parent_rate / (SMD_MAX_DIV + 1); + div = req->best_parent_rate / req->rate; + if (div > SMD_MAX_DIV) { + req->rate = req->best_parent_rate / (SMD_MAX_DIV + 1); + return 0; + }
- bestrate = *parent_rate / div; - tmp = *parent_rate / (div + 1); - if (bestrate - rate > rate - tmp) + bestrate = req->best_parent_rate / div; + tmp = req->best_parent_rate / (div + 1); + if (bestrate - req->rate > req->rate - tmp) bestrate = tmp;
- return bestrate; + req->rate = bestrate; + return 0; }
static int at91sam9x5_clk_smd_set_parent(struct clk_hw *hw, u8 index) @@ -98,7 +103,7 @@ static int at91sam9x5_clk_smd_set_rate(struct clk_hw *hw, unsigned long rate,
static const struct clk_ops at91sam9x5_smd_ops = { .recalc_rate = at91sam9x5_clk_smd_recalc_rate, - .round_rate = at91sam9x5_clk_smd_round_rate, + .determine_rate = at91sam9x5_clk_smd_determine_rate, .get_parent = at91sam9x5_clk_smd_get_parent, .set_parent = at91sam9x5_clk_smd_set_parent, .set_rate = at91sam9x5_clk_smd_set_rate,
The AXI clkgen clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-axi-clkgen.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c index ac6ff736ac8f..6b2a44ef4d73 100644 --- a/drivers/clk/clk-axi-clkgen.c +++ b/drivers/clk/clk-axi-clkgen.c @@ -384,23 +384,25 @@ static int axi_clkgen_set_rate(struct clk_hw *clk_hw, return 0; }
-static long axi_clkgen_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int axi_clkgen_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct axi_clkgen *axi_clkgen = clk_hw_to_axi_clkgen(hw); const struct axi_clkgen_limits *limits = &axi_clkgen->limits; unsigned int d, m, dout; unsigned long long tmp;
- axi_clkgen_calc_params(limits, *parent_rate, rate, &d, &m, &dout); + axi_clkgen_calc_params(limits, req->best_parent_rate, req->rate, + &d, &m, &dout);
if (d == 0 || dout == 0 || m == 0) return -EINVAL;
- tmp = (unsigned long long)*parent_rate * m; + tmp = (unsigned long long)req->best_parent_rate * m; tmp = DIV_ROUND_CLOSEST_ULL(tmp, dout * d);
- return min_t(unsigned long long, tmp, LONG_MAX); + req->rate = min_t(unsigned long long, tmp, LONG_MAX); + return 0; }
static unsigned int axi_clkgen_get_div(struct axi_clkgen *axi_clkgen, @@ -495,7 +497,7 @@ static u8 axi_clkgen_get_parent(struct clk_hw *clk_hw)
static const struct clk_ops axi_clkgen_ops = { .recalc_rate = axi_clkgen_recalc_rate, - .round_rate = axi_clkgen_round_rate, + .determine_rate = axi_clkgen_determine_rate, .set_rate = axi_clkgen_set_rate, .enable = axi_clkgen_enable, .disable = axi_clkgen_disable,
The cdce706 divider clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-cdce706.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-cdce706.c b/drivers/clk/clk-cdce706.c index dc046bbf83a1..a53769d239a9 100644 --- a/drivers/clk/clk-cdce706.c +++ b/drivers/clk/clk-cdce706.c @@ -288,18 +288,19 @@ static unsigned long cdce706_divider_recalc_rate(struct clk_hw *hw, return 0; }
-static long cdce706_divider_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int cdce706_divider_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct cdce706_hw_data *hwd = to_hw_data(hw); struct cdce706_dev_data *cdce = hwd->dev_data; + unsigned long rate = req->rate; unsigned long mul, div;
dev_dbg(&hwd->dev_data->client->dev, "%s, rate: %lu, parent_rate: %lu\n", - __func__, rate, *parent_rate); + __func__, rate, req->best_parent_rate);
- rational_best_approximation(rate, *parent_rate, + rational_best_approximation(rate, req->best_parent_rate, 1, CDCE706_DIVIDER_DIVIDER_MAX, &mul, &div); if (!mul) @@ -344,8 +345,8 @@ static long cdce706_divider_round_rate(struct clk_hw *hw, unsigned long rate,
dev_dbg(&hwd->dev_data->client->dev, "%s, altering parent rate: %lu -> %lu\n", - __func__, *parent_rate, rate * div); - *parent_rate = rate * div; + __func__, req->best_parent_rate, rate * div); + req->best_parent_rate = rate * div; } hwd->div = div;
@@ -353,7 +354,8 @@ static long cdce706_divider_round_rate(struct clk_hw *hw, unsigned long rate, "%s, divider: %d, div: %lu\n", __func__, hwd->idx, div);
- return *parent_rate / div; + req->rate = req->best_parent_rate / div; + return 0; }
static int cdce706_divider_set_rate(struct clk_hw *hw, unsigned long rate, @@ -375,7 +377,7 @@ static const struct clk_ops cdce706_divider_ops = { .set_parent = cdce706_divider_set_parent, .get_parent = cdce706_divider_get_parent, .recalc_rate = cdce706_divider_recalc_rate, - .round_rate = cdce706_divider_round_rate, + .determine_rate = cdce706_divider_determine_rate, .set_rate = cdce706_divider_set_rate, };
The cdce706 clkout clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-cdce706.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-cdce706.c b/drivers/clk/clk-cdce706.c index a53769d239a9..0a560b4d295e 100644 --- a/drivers/clk/clk-cdce706.c +++ b/drivers/clk/clk-cdce706.c @@ -423,11 +423,12 @@ static unsigned long cdce706_clkout_recalc_rate(struct clk_hw *hw, return parent_rate; }
-static long cdce706_clkout_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int cdce706_clkout_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { - *parent_rate = rate; - return rate; + req->best_parent_rate = req->rate; + + return 0; }
static int cdce706_clkout_set_rate(struct clk_hw *hw, unsigned long rate, @@ -442,7 +443,7 @@ static const struct clk_ops cdce706_clkout_ops = { .set_parent = cdce706_clkout_set_parent, .get_parent = cdce706_clkout_get_parent, .recalc_rate = cdce706_clkout_recalc_rate, - .round_rate = cdce706_clkout_round_rate, + .determine_rate = cdce706_clkout_determine_rate, .set_rate = cdce706_clkout_set_rate, };
The SI5341 output clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-si5341.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-si5341.c b/drivers/clk/clk-si5341.c index 259861aa2e2f..14792d5ffb4f 100644 --- a/drivers/clk/clk-si5341.c +++ b/drivers/clk/clk-si5341.c @@ -828,19 +828,20 @@ static unsigned long si5341_output_clk_recalc_rate(struct clk_hw *hw, return parent_rate / r_divider; }
-static long si5341_output_clk_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int si5341_output_clk_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { + unsigned long rate = req->rate; unsigned long r;
if (!rate) return 0;
- r = *parent_rate >> 1; + r = req->best_parent_rate >> 1;
/* If rate is an even divisor, no changes to parent required */ if (r && !(r % rate)) - return (long)rate; + return 0;
if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) { if (rate > 200000000) { @@ -850,14 +851,15 @@ static long si5341_output_clk_round_rate(struct clk_hw *hw, unsigned long rate, /* Take a parent frequency near 400 MHz */ r = (400000000u / rate) & ~1; } - *parent_rate = r * rate; + req->best_parent_rate = r * rate; } else { /* We cannot change our parent's rate, report what we can do */ r /= rate; - rate = *parent_rate / (r << 1); + rate = req->best_parent_rate / (r << 1); }
- return rate; + req->rate = rate; + return 0; }
static int si5341_output_clk_set_rate(struct clk_hw *hw, unsigned long rate, @@ -930,7 +932,7 @@ static const struct clk_ops si5341_output_clk_ops = { .prepare = si5341_output_clk_prepare, .unprepare = si5341_output_clk_unprepare, .recalc_rate = si5341_output_clk_recalc_rate, - .round_rate = si5341_output_clk_round_rate, + .determine_rate = si5341_output_clk_determine_rate, .set_rate = si5341_output_clk_set_rate, .set_parent = si5341_output_set_parent, .get_parent = si5341_output_get_parent,
The SI5351 PLL clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-si5351.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c index 9e939c98a455..fcf5785ba4ce 100644 --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -442,11 +442,12 @@ static unsigned long si5351_pll_recalc_rate(struct clk_hw *hw, return (unsigned long)rate; }
-static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int si5351_pll_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct si5351_hw_data *hwdata = container_of(hw, struct si5351_hw_data, hw); + unsigned long rate = req->rate; unsigned long rfrac, denom, a, b, c; unsigned long long lltmp;
@@ -456,18 +457,18 @@ static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate, rate = SI5351_PLL_VCO_MAX;
/* determine integer part of feedback equation */ - a = rate / *parent_rate; + a = rate / req->best_parent_rate;
if (a < SI5351_PLL_A_MIN) - rate = *parent_rate * SI5351_PLL_A_MIN; + rate = req->best_parent_rate * SI5351_PLL_A_MIN; if (a > SI5351_PLL_A_MAX) - rate = *parent_rate * SI5351_PLL_A_MAX; + rate = req->best_parent_rate * SI5351_PLL_A_MAX;
/* find best approximation for b/c = fVCO mod fIN */ denom = 1000 * 1000; - lltmp = rate % (*parent_rate); + lltmp = rate % (req->best_parent_rate); lltmp *= denom; - do_div(lltmp, *parent_rate); + do_div(lltmp, req->best_parent_rate); rfrac = (unsigned long)lltmp;
b = 0; @@ -484,19 +485,20 @@ static long si5351_pll_round_rate(struct clk_hw *hw, unsigned long rate, hwdata->params.p1 -= 512;
/* recalculate rate by fIN * (a + b/c) */ - lltmp = *parent_rate; + lltmp = req->best_parent_rate; lltmp *= b; do_div(lltmp, c);
rate = (unsigned long)lltmp; - rate += *parent_rate * a; + rate += req->best_parent_rate * a;
dev_dbg(&hwdata->drvdata->client->dev, "%s - %s: a = %lu, b = %lu, c = %lu, parent_rate = %lu, rate = %lu\n", __func__, clk_hw_get_name(hw), a, b, c, - *parent_rate, rate); + req->best_parent_rate, rate);
- return rate; + req->rate = rate; + return 0; }
static int si5351_pll_set_rate(struct clk_hw *hw, unsigned long rate, @@ -533,7 +535,7 @@ static const struct clk_ops si5351_pll_ops = { .set_parent = si5351_pll_set_parent, .get_parent = si5351_pll_get_parent, .recalc_rate = si5351_pll_recalc_rate, - .round_rate = si5351_pll_round_rate, + .determine_rate = si5351_pll_determine_rate, .set_rate = si5351_pll_set_rate, };
The SI5351 msynth clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-si5351.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c index fcf5785ba4ce..bfab05f4fe28 100644 --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -642,11 +642,12 @@ static unsigned long si5351_msynth_recalc_rate(struct clk_hw *hw, return (unsigned long)rate; }
-static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int si5351_msynth_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct si5351_hw_data *hwdata = container_of(hw, struct si5351_hw_data, hw); + unsigned long rate = req->rate; unsigned long long lltmp; unsigned long a, b, c; int divby4; @@ -681,10 +682,10 @@ static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate, b = 0; c = 1;
- *parent_rate = a * rate; + req->best_parent_rate = a * rate; } else if (hwdata->num >= 6) { /* determine the closest integer divider */ - a = DIV_ROUND_CLOSEST(*parent_rate, rate); + a = DIV_ROUND_CLOSEST(req->best_parent_rate, rate); if (a < SI5351_MULTISYNTH_A_MIN) a = SI5351_MULTISYNTH_A_MIN; if (a > SI5351_MULTISYNTH67_A_MAX) @@ -702,7 +703,7 @@ static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate, }
/* determine integer part of divider equation */ - a = *parent_rate / rate; + a = req->best_parent_rate / rate; if (a < SI5351_MULTISYNTH_A_MIN) a = SI5351_MULTISYNTH_A_MIN; if (a > SI5351_MULTISYNTH_A_MAX) @@ -710,7 +711,7 @@ static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate,
/* find best approximation for b/c = fVCO mod fOUT */ denom = 1000 * 1000; - lltmp = (*parent_rate) % rate; + lltmp = req->best_parent_rate % rate; lltmp *= denom; do_div(lltmp, rate); rfrac = (unsigned long)lltmp; @@ -724,7 +725,7 @@ static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate, }
/* recalculate rate by fOUT = fIN / (a + b/c) */ - lltmp = *parent_rate; + lltmp = req->best_parent_rate; lltmp *= c; do_div(lltmp, a * c + b); rate = (unsigned long)lltmp; @@ -749,9 +750,11 @@ static long si5351_msynth_round_rate(struct clk_hw *hw, unsigned long rate, dev_dbg(&hwdata->drvdata->client->dev, "%s - %s: a = %lu, b = %lu, c = %lu, divby4 = %d, parent_rate = %lu, rate = %lu\n", __func__, clk_hw_get_name(hw), a, b, c, divby4, - *parent_rate, rate); + req->best_parent_rate, rate);
- return rate; + req->rate = rate; + + return 0; }
static int si5351_msynth_set_rate(struct clk_hw *hw, unsigned long rate, @@ -791,7 +794,7 @@ static const struct clk_ops si5351_msynth_ops = { .set_parent = si5351_msynth_set_parent, .get_parent = si5351_msynth_get_parent, .recalc_rate = si5351_msynth_recalc_rate, - .round_rate = si5351_msynth_round_rate, + .determine_rate = si5351_msynth_determine_rate, .set_rate = si5351_msynth_set_rate, };
The SI5351 clkout clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk-si5351.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c index bfab05f4fe28..11aaa934da29 100644 --- a/drivers/clk/clk-si5351.c +++ b/drivers/clk/clk-si5351.c @@ -1037,11 +1037,12 @@ static unsigned long si5351_clkout_recalc_rate(struct clk_hw *hw, return parent_rate >> rdiv; }
-static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int si5351_clkout_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct si5351_hw_data *hwdata = container_of(hw, struct si5351_hw_data, hw); + unsigned long rate = req->rate; unsigned char rdiv;
/* clkout6/7 can only handle output freqencies < 150MHz */ @@ -1063,13 +1064,13 @@ static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate, rdiv += 1; rate *= 2; } - *parent_rate = rate; + req->best_parent_rate = rate; } else { unsigned long new_rate, new_err, err;
/* round to closed rdiv */ rdiv = SI5351_OUTPUT_CLK_DIV_1; - new_rate = *parent_rate; + new_rate = req->best_parent_rate; err = abs(new_rate - rate); do { new_rate >>= 1; @@ -1080,14 +1081,15 @@ static long si5351_clkout_round_rate(struct clk_hw *hw, unsigned long rate, err = new_err; } while (1); } - rate = *parent_rate >> rdiv; + rate = req->best_parent_rate >> rdiv;
dev_dbg(&hwdata->drvdata->client->dev, "%s - %s: rdiv = %u, parent_rate = %lu, rate = %lu\n", __func__, clk_hw_get_name(hw), (1 << rdiv), - *parent_rate, rate); + req->best_parent_rate, rate);
- return rate; + req->rate = rate; + return 0; }
static int si5351_clkout_set_rate(struct clk_hw *hw, unsigned long rate, @@ -1147,7 +1149,7 @@ static const struct clk_ops si5351_clkout_ops = { .set_parent = si5351_clkout_set_parent, .get_parent = si5351_clkout_get_parent, .recalc_rate = si5351_clkout_recalc_rate, - .round_rate = si5351_clkout_round_rate, + .determine_rate = si5351_clkout_determine_rate, .set_rate = si5351_clkout_set_rate, };
The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/davinci/da8xx-cfgchip.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c b/drivers/clk/davinci/da8xx-cfgchip.c index 4c1cc59bba53..f60c97091818 100644 --- a/drivers/clk/davinci/da8xx-cfgchip.c +++ b/drivers/clk/davinci/da8xx-cfgchip.c @@ -462,10 +462,12 @@ static unsigned long da8xx_usb0_clk48_recalc_rate(struct clk_hw *hw, return 48000000; }
-static long da8xx_usb0_clk48_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int da8xx_usb0_clk48_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { - return 48000000; + req->rate = 48000000; + + return 0; }
static int da8xx_usb0_clk48_set_parent(struct clk_hw *hw, u8 index) @@ -494,7 +496,7 @@ static const struct clk_ops da8xx_usb0_clk48_ops = { .disable = da8xx_usb0_clk48_disable, .is_enabled = da8xx_usb0_clk48_is_enabled, .recalc_rate = da8xx_usb0_clk48_recalc_rate, - .round_rate = da8xx_usb0_clk48_round_rate, + .determine_rate = da8xx_usb0_clk48_determine_rate, .set_parent = da8xx_usb0_clk48_set_parent, .get_parent = da8xx_usb0_clk48_get_parent, };
On 11/4/22 8:18 AM, Maxime Ripard wrote:
The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
I think this one should be the same as the clk:davinci changes and not allow re-parenting. Since this is a USB 48MHz PHY clock, a rate change will never be requested.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/davinci/da8xx-cfgchip.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/davinci/da8xx-cfgchip.c b/drivers/clk/davinci/da8xx-cfgchip.c index 4c1cc59bba53..f60c97091818 100644 --- a/drivers/clk/davinci/da8xx-cfgchip.c +++ b/drivers/clk/davinci/da8xx-cfgchip.c @@ -462,10 +462,12 @@ static unsigned long da8xx_usb0_clk48_recalc_rate(struct clk_hw *hw, return 48000000; }
-static long da8xx_usb0_clk48_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)+static int da8xx_usb0_clk48_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
- return 48000000;
req->rate = 48000000;
return 0; }
static int da8xx_usb0_clk48_set_parent(struct clk_hw *hw, u8 index)
@@ -494,7 +496,7 @@ static const struct clk_ops da8xx_usb0_clk48_ops = { .disable = da8xx_usb0_clk48_disable, .is_enabled = da8xx_usb0_clk48_is_enabled, .recalc_rate = da8xx_usb0_clk48_recalc_rate,
- .round_rate = da8xx_usb0_clk48_round_rate,
- .determine_rate = da8xx_usb0_clk48_determine_rate, .set_parent = da8xx_usb0_clk48_set_parent, .get_parent = da8xx_usb0_clk48_get_parent, };
Hi David,
On Fri, Nov 04, 2022 at 11:49:34AM -0500, David Lechner wrote:
On 11/4/22 8:18 AM, Maxime Ripard wrote:
The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
I think this one should be the same as the clk:davinci changes and not allow re-parenting. Since this is a USB 48MHz PHY clock, a rate change will never be requested.
I'm not sure, it doesn't seem to be the same clock, it's not doing the same thing (this one will always force the same rate, the others let the rate change), and we're not doing the same refactoring (this one had a round_rate implementation, the other one doesn't)
Maxime
The iMX SCU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. The round_rate() implementation being shared with other clocks, it's not removed.
And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/imx/clk-scu.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c index 66e49fea5f8a..bbdc1b23f6f5 100644 --- a/drivers/clk/imx/clk-scu.c +++ b/drivers/clk/imx/clk-scu.c @@ -250,6 +250,23 @@ static unsigned long clk_scu_recalc_rate(struct clk_hw *hw, return le32_to_cpu(msg.data.resp.rate); }
+/* + * clk_scu_determine_rate - Returns the closest rate for a SCU clock + * @hw: clock to round rate for + * @req: clock rate request + * + * Returns 0 on success, a negative error on failure + */ +static int clk_scu_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) +{ + /* + * Assume we support all the requested rate and let the SCU firmware + * to handle the left work + */ + return 0; +} + /* * clk_scu_round_rate - Round clock rate for a SCU clock * @hw: clock to round rate for @@ -425,7 +442,7 @@ static void clk_scu_unprepare(struct clk_hw *hw)
static const struct clk_ops clk_scu_ops = { .recalc_rate = clk_scu_recalc_rate, - .round_rate = clk_scu_round_rate, + .determine_rate = clk_scu_determine_rate, .set_rate = clk_scu_set_rate, .get_parent = clk_scu_get_parent, .set_parent = clk_scu_set_parent,
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/ingenic/cgu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c index 1f7ba30f5a1b..0c9c8344ad11 100644 --- a/drivers/clk/ingenic/cgu.c +++ b/drivers/clk/ingenic/cgu.c @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, return div; }
-static long -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate, - unsigned long *parent_rate) +static int ingenic_clk_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw); const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk); unsigned int div = 1;
if (clk_info->type & CGU_CLK_DIV) - div = ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate); + div = ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate, + req->rate); else if (clk_info->type & CGU_CLK_FIXDIV) div = clk_info->fixdiv.div; else if (clk_hw_can_set_rate_parent(hw)) - *parent_rate = req_rate; + req->best_parent_rate = req->rate;
- return DIV_ROUND_UP(*parent_rate, div); + req->rate = DIV_ROUND_UP(req->best_parent_rate, div); + return 0; }
static inline int ingenic_clk_check_stable(struct ingenic_cgu *cgu, @@ -626,7 +627,7 @@ static const struct clk_ops ingenic_clk_ops = { .set_parent = ingenic_clk_set_parent,
.recalc_rate = ingenic_clk_recalc_rate, - .round_rate = ingenic_clk_round_rate, + .determine_rate = ingenic_clk_determine_rate, .set_rate = ingenic_clk_set_rate,
.enable = ingenic_clk_enable,
Hi Maxime,
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/ingenic/cgu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c index 1f7ba30f5a1b..0c9c8344ad11 100644 --- a/drivers/clk/ingenic/cgu.c +++ b/drivers/clk/ingenic/cgu.c @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, return div; }
-static long -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate,
unsigned long *parent_rate)+static int ingenic_clk_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req){ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw); const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk); unsigned int div = 1;
if (clk_info->type & CGU_CLK_DIV)
div = ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate);
div = ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate,req->rate);
Sorry but I'm not sure that this works.
You replace the "parent_rate" with the "best_parent_rate", and that means you only check the requested rate vs. the parent with the highest frequency, and not vs. the actual parent that will be used.
Cheers, -Paul
else if (clk_info->type & CGU_CLK_FIXDIV) div = clk_info->fixdiv.div; else if (clk_hw_can_set_rate_parent(hw))
*parent_rate = req_rate;
req->best_parent_rate = req->rate;
- return DIV_ROUND_UP(*parent_rate, div);
- req->rate = DIV_ROUND_UP(req->best_parent_rate, div);
- return 0;
}
static inline int ingenic_clk_check_stable(struct ingenic_cgu *cgu, @@ -626,7 +627,7 @@ static const struct clk_ops ingenic_clk_ops = { .set_parent = ingenic_clk_set_parent,
.recalc_rate = ingenic_clk_recalc_rate,
- .round_rate = ingenic_clk_round_rate,
.determine_rate = ingenic_clk_determine_rate, .set_rate = ingenic_clk_set_rate,
.enable = ingenic_clk_enable,
-- b4 0.11.0-dev-99e3a
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/ingenic/cgu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c index 1f7ba30f5a1b..0c9c8344ad11 100644 --- a/drivers/clk/ingenic/cgu.c +++ b/drivers/clk/ingenic/cgu.c @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, return div; }
-static long -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate,
unsigned long *parent_rate)+static int ingenic_clk_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req){ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw); const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk); unsigned int div = 1;
if (clk_info->type & CGU_CLK_DIV)
div = ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate);
div = ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate,req->rate);Sorry but I'm not sure that this works.
You replace the "parent_rate" with the "best_parent_rate", and that means you only check the requested rate vs. the parent with the highest frequency, and not vs. the actual parent that will be used.
best_parent_rate is initialized to the current parent rate, not the parent with the highest frequency: https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/clk/clk.c#L1471
Maxime
Maxime Ripard maxime@cerno.tech writes:
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints.
That way allowing reparenting doesn't need to be an all-or-nothing thing, and it doesn't need to be decided at the clock driver level with special flags.
Regards, Aidan
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/ingenic/cgu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c index 1f7ba30f5a1b..0c9c8344ad11 100644 --- a/drivers/clk/ingenic/cgu.c +++ b/drivers/clk/ingenic/cgu.c @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, return div; }
-static long -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate,
unsigned long *parent_rate)+static int ingenic_clk_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req){ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw); const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk); unsigned int div = 1;
if (clk_info->type & CGU_CLK_DIV)
div = ingenic_clk_calc_div(hw, clk_info, *parent_rate, req_rate);
div = ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate,req->rate);Sorry but I'm not sure that this works.
You replace the "parent_rate" with the "best_parent_rate", and that means you only check the requested rate vs. the parent with the highest frequency, and not vs. the actual parent that will be used.
best_parent_rate is initialized to the current parent rate, not the parent with the highest frequency: https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/clk/clk.c#L1471
Maxime
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints.
I'm not really sure what you mean there, sorry. Isn't it what assigned-clock-parents/clk_set_parent() at probe, plus a determine_rate implementation that would affect best_parent_hw would already provide?
That way allowing reparenting doesn't need to be an all-or-nothing thing, and it doesn't need to be decided at the clock driver level with special flags.
Like I said, the default implementation is already working to what you suggested if I understood properly. However, this has never been tested for any of the drivers in that series so I don't want to introduce (and debug ;)) regressions in all those drivers that were not setting any constraint but never actually tested their reparenting code.
So that series is strictly equivalent to what you had before, it's just explicit now.
If you find that some other decision make sense for your driver in particular cases, feel free to change it. I barely know most of these platforms, so I won't be able to make that decision (and test it) unfortunately.
Maxime
Maxime Ripard maxime@cerno.tech writes:
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints.
I'm not really sure what you mean there, sorry. Isn't it what assigned-clock-parents/clk_set_parent() at probe, plus a determine_rate implementation that would affect best_parent_hw would already provide?
Assigning the parent clock in the DT works once, at boot, but going off what you wrote in the commit message, if the clock driver has a .determine_rate() implementation that *can* reparent clocks then it probably *will* reparent them, and the DT assignment will be lost.
What I'm suggesting is a runtime constraint that the clock subsystem would enforce, and actively prevent drivers from changing the parent. Either explicitly with clk_set_parent() or due to .determine_rate().
That way you could write a .determine_rate() implementation that *can* select a better parent, but if the DT applies a constraint to fix the clock to a particular parent, the clock subsystem will force that parent to be used so you can be sure the clock is never reparented by accident.
That way allowing reparenting doesn't need to be an all-or-nothing thing, and it doesn't need to be decided at the clock driver level with special flags.
Like I said, the default implementation is already working to what you suggested if I understood properly. However, this has never been tested for any of the drivers in that series so I don't want to introduce (and debug ;)) regressions in all those drivers that were not setting any constraint but never actually tested their reparenting code.
So that series is strictly equivalent to what you had before, it's just explicit now.
If you find that some other decision make sense for your driver in particular cases, feel free to change it. I barely know most of these platforms, so I won't be able to make that decision (and test it) unfortunately.
Maxime
That's OK, I didn't review the patch, I'm just making a general suggestion. :)
On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
Ideally there should be a way for drivers and the device tree to say, "clock X must be driven by clock Y", but the clock framework would be allowed to re-parent clocks freely as long as it doesn't violate any DT or driver constraints.
I'm not really sure what you mean there, sorry. Isn't it what assigned-clock-parents/clk_set_parent() at probe, plus a determine_rate implementation that would affect best_parent_hw would already provide?
Assigning the parent clock in the DT works once, at boot, but going off what you wrote in the commit message, if the clock driver has a .determine_rate() implementation that *can* reparent clocks then it probably *will* reparent them, and the DT assignment will be lost.
Yes, indeed, but assigned-clock-parents never provided any sort of guarantee on whether or not the clock was allowed to reparent or not. It's just a one-off thing, right before probe, and a clk_set_parent() call at probe will override that just fine.
Just like assigned-clock-rates isn't permanent.
What I'm suggesting is a runtime constraint that the clock subsystem would enforce, and actively prevent drivers from changing the parent. Either explicitly with clk_set_parent() or due to .determine_rate().
That way you could write a .determine_rate() implementation that *can* select a better parent, but if the DT applies a constraint to fix the clock to a particular parent, the clock subsystem will force that parent to be used so you can be sure the clock is never reparented by accident.
Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't too far off from this, it's just ignored by clk_set_parent() for now. I guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make clk_set_parent handle it, and set that flag whenever assigned-clock-parents is set on a clock.
It's out of scope for this series though, and I certainly don't want to deal with all the regressions it might create :)
Maxime
Quoting Maxime Ripard (2022-11-09 03:00:45)
On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Assigning the parent clock in the DT works once, at boot, but going off what you wrote in the commit message, if the clock driver has a .determine_rate() implementation that *can* reparent clocks then it probably *will* reparent them, and the DT assignment will be lost.
Yes, indeed, but assigned-clock-parents never provided any sort of guarantee on whether or not the clock was allowed to reparent or not. It's just a one-off thing, right before probe, and a clk_set_parent() call at probe will override that just fine.
Just like assigned-clock-rates isn't permanent.
What I'm suggesting is a runtime constraint that the clock subsystem would enforce, and actively prevent drivers from changing the parent. Either explicitly with clk_set_parent() or due to .determine_rate().
That way you could write a .determine_rate() implementation that *can* select a better parent, but if the DT applies a constraint to fix the clock to a particular parent, the clock subsystem will force that parent to be used so you can be sure the clock is never reparented by accident.
Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't too far off from this, it's just ignored by clk_set_parent() for now. I guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make clk_set_parent handle it, and set that flag whenever assigned-clock-parents is set on a clock.
It's out of scope for this series though, and I certainly don't want to deal with all the regressions it might create :)
This sounds like a new dt binding that says the assigned parent should never change. It sounds sort of like gpio hogs. A clock-hogs binding?
Stephen Boyd sboyd@kernel.org writes:
Quoting Maxime Ripard (2022-11-09 03:00:45)
On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Assigning the parent clock in the DT works once, at boot, but going off what you wrote in the commit message, if the clock driver has a .determine_rate() implementation that *can* reparent clocks then it probably *will* reparent them, and the DT assignment will be lost.
Yes, indeed, but assigned-clock-parents never provided any sort of guarantee on whether or not the clock was allowed to reparent or not. It's just a one-off thing, right before probe, and a clk_set_parent() call at probe will override that just fine.
Just like assigned-clock-rates isn't permanent.
What I'm suggesting is a runtime constraint that the clock subsystem would enforce, and actively prevent drivers from changing the parent. Either explicitly with clk_set_parent() or due to .determine_rate().
That way you could write a .determine_rate() implementation that *can* select a better parent, but if the DT applies a constraint to fix the clock to a particular parent, the clock subsystem will force that parent to be used so you can be sure the clock is never reparented by accident.
Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't too far off from this, it's just ignored by clk_set_parent() for now. I guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make clk_set_parent handle it, and set that flag whenever assigned-clock-parents is set on a clock.
It's out of scope for this series though, and I certainly don't want to deal with all the regressions it might create :)
This sounds like a new dt binding that says the assigned parent should never change. It sounds sort of like gpio hogs. A clock-hogs binding?
Ideally we want the clock driver to be able to reparent clocks freely to get the best rate. But we also need some control over that to stop consumers from being reparented in undesired ways. Eg. you might want to make sure the GPU gets its own PLL so it can be reclocked easily, and putting another device on the GPU's PLL could prevent that.
The only way to achieve this today is (1) never do any reparenting in the clock driver; and (2) use assigned-clock-parents in the DT to set up the entire clock tree manually.
Maxime said that (2) is basically wrong -- if assigned-clock-parents provides no guarantee on what the OS does "after boot" then the OS is pretty much free to ignore it.
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;
This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
Hi,
On Thu, Mar 23, 2023 at 03:35:30PM +0000, Aidan MacDonald wrote:
Stephen Boyd sboyd@kernel.org writes:
Quoting Maxime Ripard (2022-11-09 03:00:45)
On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Assigning the parent clock in the DT works once, at boot, but going off what you wrote in the commit message, if the clock driver has a .determine_rate() implementation that *can* reparent clocks then it probably *will* reparent them, and the DT assignment will be lost.
Yes, indeed, but assigned-clock-parents never provided any sort of guarantee on whether or not the clock was allowed to reparent or not. It's just a one-off thing, right before probe, and a clk_set_parent() call at probe will override that just fine.
Just like assigned-clock-rates isn't permanent.
What I'm suggesting is a runtime constraint that the clock subsystem would enforce, and actively prevent drivers from changing the parent. Either explicitly with clk_set_parent() or due to .determine_rate().
That way you could write a .determine_rate() implementation that *can* select a better parent, but if the DT applies a constraint to fix the clock to a particular parent, the clock subsystem will force that parent to be used so you can be sure the clock is never reparented by accident.
Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't too far off from this, it's just ignored by clk_set_parent() for now. I guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make clk_set_parent handle it, and set that flag whenever assigned-clock-parents is set on a clock.
It's out of scope for this series though, and I certainly don't want to deal with all the regressions it might create :)
This sounds like a new dt binding that says the assigned parent should never change. It sounds sort of like gpio hogs. A clock-hogs binding?
Ideally we want the clock driver to be able to reparent clocks freely to get the best rate. But we also need some control over that to stop consumers from being reparented in undesired ways. Eg. you might want to make sure the GPU gets its own PLL so it can be reclocked easily, and putting another device on the GPU's PLL could prevent that.
The only way to achieve this today is (1) never do any reparenting in the clock driver; and (2) use assigned-clock-parents in the DT to set up the entire clock tree manually.
Maxime said that (2) is basically wrong -- if assigned-clock-parents provides no guarantee on what the OS does "after boot" then the OS is pretty much free to ignore it.
I didn't really say it's wrong, just that it never provided the guarantee you expect it to provide. I can't really say whether it's an issue or not on your platform.
It's mostly unrelated to this series though, none of these patches affect that behavior in one way or the other.
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
Maxime
Maxime Ripard maxime@cerno.tech writes:
On Thu, Mar 23, 2023 at 03:35:30PM +0000, Aidan MacDonald wrote:
Stephen Boyd sboyd@kernel.org writes:
Quoting Maxime Ripard (2022-11-09 03:00:45)
On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote:
Maxime Ripard maxime@cerno.tech writes:
Hi,
On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote:
Assigning the parent clock in the DT works once, at boot, but going off what you wrote in the commit message, if the clock driver has a .determine_rate() implementation that *can* reparent clocks then it probably *will* reparent them, and the DT assignment will be lost.
Yes, indeed, but assigned-clock-parents never provided any sort of guarantee on whether or not the clock was allowed to reparent or not. It's just a one-off thing, right before probe, and a clk_set_parent() call at probe will override that just fine.
Just like assigned-clock-rates isn't permanent.
What I'm suggesting is a runtime constraint that the clock subsystem would enforce, and actively prevent drivers from changing the parent. Either explicitly with clk_set_parent() or due to .determine_rate().
That way you could write a .determine_rate() implementation that *can* select a better parent, but if the DT applies a constraint to fix the clock to a particular parent, the clock subsystem will force that parent to be used so you can be sure the clock is never reparented by accident.
Yeah, that sounds like a good idea, and CLK_SET_RATE_NO_REPARENT isn't too far off from this, it's just ignored by clk_set_parent() for now. I guess we could rename CLK_SET_RATE_NO_REPARENT to CLK_NO_REPARENT, make clk_set_parent handle it, and set that flag whenever assigned-clock-parents is set on a clock.
It's out of scope for this series though, and I certainly don't want to deal with all the regressions it might create :)
This sounds like a new dt binding that says the assigned parent should never change. It sounds sort of like gpio hogs. A clock-hogs binding?
Ideally we want the clock driver to be able to reparent clocks freely to get the best rate. But we also need some control over that to stop consumers from being reparented in undesired ways. Eg. you might want to make sure the GPU gets its own PLL so it can be reclocked easily, and putting another device on the GPU's PLL could prevent that.
The only way to achieve this today is (1) never do any reparenting in the clock driver; and (2) use assigned-clock-parents in the DT to set up the entire clock tree manually.
Maxime said that (2) is basically wrong -- if assigned-clock-parents provides no guarantee on what the OS does "after boot" then the OS is pretty much free to ignore it.
I didn't really say it's wrong, just that it never provided the guarantee you expect it to provide. I can't really say whether it's an issue or not on your platform.
It's mostly unrelated to this series though, none of these patches affect that behavior in one way or the other.
I know. Sorry for derailing your patch :(
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
Maxime
I'm confused. What's implicit in the example is clk1 and clk2 might have *other* possible choices of parent clock and the device tree is limiting what the OS is allowed to choose.
Why would you put such arbitrary limitations into the driver? They would be different from machine to machine, unless the clock tree is so simple there is only *one* meaningful way to configure it. Most SoCs are complicated enough that there will be tradeoffs depending on what peripherals you are using (typically a single machine will not use *every* peripheral device provided by the SoC).
On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote:
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
I'm confused. What's implicit in the example is clk1 and clk2 might have *other* possible choices of parent clock and the device tree is limiting what the OS is allowed to choose.
Why would you put such arbitrary limitations into the driver?
Why would we put such arbitrary limitations in the firmware? As this entire thread can attest, people are already using the device tree to work around the limitations of the Linux driver, or reduce the features of Linux because they can rely on the device tree. Either way, it's linked to the state of the Linux driver, and any other OS or Linux version could very well implement something more dynamic.
They would be different from machine to machine, unless the clock tree is so simple there is only *one* meaningful way to configure it.
If we look at the device trees we have in-tree, most of the users of assigned-clocks are the same from one board to another.
Most SoCs are complicated enough that there will be tradeoffs depending on what peripherals you are using (typically a single machine will not use *every* peripheral device provided by the SoC).
We already have APIs to lock parents or rates on a given clock from the consumer. It's far superior (feature-wise) than what the device tree will ever offer because it's code, and it depends on the usage already since an unused driver won't probe.
Maxime
Hi Maxime,
Le lundi 27 mars 2023 à 21:24 +0200, Maxime Ripard a écrit :
On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote:
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;
This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
I'm confused. What's implicit in the example is clk1 and clk2 might have *other* possible choices of parent clock and the device tree is limiting what the OS is allowed to choose.
Why would you put such arbitrary limitations into the driver?
Why would we put such arbitrary limitations in the firmware? As this entire thread can attest, people are already using the device tree to work around the limitations of the Linux driver, or reduce the features of Linux because they can rely on the device tree. Either way, it's linked to the state of the Linux driver, and any other OS or Linux version could very well implement something more dynamic.
Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware.
Especially when talking about clocks, as the firmware is already the one programming the boot clocks.
Cheers, -Paul
They would be different from machine to machine, unless the clock tree is so simple there is only *one* meaningful way to configure it.
If we look at the device trees we have in-tree, most of the users of assigned-clocks are the same from one board to another.
Most SoCs are complicated enough that there will be tradeoffs depending on what peripherals you are using (typically a single machine will not use *every* peripheral device provided by the SoC).
We already have APIs to lock parents or rates on a given clock from the consumer. It's far superior (feature-wise) than what the device tree will ever offer because it's code, and it depends on the usage already since an unused driver won't probe.
Maxime
On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote:
Le lundi 27 mars 2023 à 21:24 +0200, Maxime Ripard a écrit :
On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote:
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;
This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
I'm confused. What's implicit in the example is clk1 and clk2 might have *other* possible choices of parent clock and the device tree is limiting what the OS is allowed to choose.
Why would you put such arbitrary limitations into the driver?
Why would we put such arbitrary limitations in the firmware? As this entire thread can attest, people are already using the device tree to work around the limitations of the Linux driver, or reduce the features of Linux because they can rely on the device tree. Either way, it's linked to the state of the Linux driver, and any other OS or Linux version could very well implement something more dynamic.
Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware.
I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently?
Especially when talking about clocks, as the firmware is already the one programming the boot clocks.
I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver.
Maxime
Le mercredi 05 avril 2023 à 16:50 +0200, Maxime Ripard a écrit :
On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote:
Le lundi 27 mars 2023 à 21:24 +0200, Maxime Ripard a écrit :
On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote:
My suggestion: add a per-clock bitmap to keep track of which parents are allowed. Any operation that would select a parent clock not on the whitelist should fail. Automatic reparenting should only select from clocks on the whitelist. And we need new DT bindings for controlling the whitelist, for example:
clock-parents-0 = <&clk1>, <&pll_c>; clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;
This means that clk1 can only have pll_c as a parent, while clk2 can have pll_a or pll_b as parents. By default every clock will be able to use any parent, so a list is only needed if the machine needs a more restrictive policy.
assigned-clock-parents should disable automatic reparenting, but allow explicit clk_set_parent(). This will allow clock drivers to start doing reparenting without breaking old DTs.
I'm generally not a fan of putting all these policies in the device tree. Do you have an example where it wouldn't be possible to do exactly this from the driver itself?
I'm confused. What's implicit in the example is clk1 and clk2 might have *other* possible choices of parent clock and the device tree is limiting what the OS is allowed to choose.
Why would you put such arbitrary limitations into the driver?
Why would we put such arbitrary limitations in the firmware? As this entire thread can attest, people are already using the device tree to work around the limitations of the Linux driver, or reduce the features of Linux because they can rely on the device tree. Either way, it's linked to the state of the Linux driver, and any other OS or Linux version could very well implement something more dynamic.
Probably because if we have to choose between setting policy in the kernel or in the firmware, it is arguably better to set it in the firmware.
I have a very different view on this I guess. Firmware is (most of the time) hard to update, and the policy depend on the state of support of a given OS so it's likely to evolve. The kernel is the best place to me to put that kind of policy. Why do you think differently?
Because the clocks configuration can be board-specific. And you don't really want board-specific stuff in the driver.
If we take the Ingenic JZ4770 SoC as example, on one board we parent everything we can to the PLL1 clock and set it to 432 MHz (the least common multiple). Then the PLL0 (which drives the DDR and CPU clocks) can be updated to overclock/underclock the CPU and RAM.
So should that be hardcoded in the driver? Well, for a different board, for which overclock is not really needed, it's better to parent everything to PLL0 so that PLL1 can be shut down to save power. So what policy should be hardcoded in the driver?
Especially when talking about clocks, as the firmware is already the one programming the boot clocks.
I'm not sure what your point is there. I don't think I ever saw a firmware getting the clocks right for every possible scenario on a given platform. And if it was indeed the case, then we wouldn't even a kernel driver.
My point is that there is already policy in how the firmware sets up the hardware; and most often than not, the kernel driver won't change that (e.g. you're probably not going to touch the DDR clock). It's better to have all policy in the firmware then, instead of having some in the firmware, and some in the kernel driver.
Cheers, -Paul
Hi Maxime,
Le ven. 4 nov. 2022 à 15:59:46 +0100, Maxime Ripard maxime@cerno.tech a écrit :
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook,
but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name
implies,
change the parent of a clock. However, the most likely candidate
to
trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for
a
given rate.
The other trigger would be a call to clk_set_parent(), but it's
far less
used, and it doesn't look like there's any obvious user for that
clock.
So, the set_parent hook is effectively unused, possibly because
of an
oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit
call to
clk_set_parent().
The driver does implement round_rate() though, which means that
we can
change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or
not.
Since we'll start mandating a determine_rate() implementation,
let's
convert the round_rate() implementation to a determine_rate(),
which
will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
But that would introduce policy into the driver... The fact that I don't want the MMC parented to the PLLs, doesn't mean that it's an invalid configuration per se.
Cheers, -Paul
Signed-off-by: Maxime Ripard maxime@cerno.tech
drivers/clk/ingenic/cgu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c index 1f7ba30f5a1b..0c9c8344ad11 100644 --- a/drivers/clk/ingenic/cgu.c +++ b/drivers/clk/ingenic/cgu.c @@ -491,22 +491,23 @@ ingenic_clk_calc_div(struct clk_hw *hw, return div; }
-static long -ingenic_clk_round_rate(struct clk_hw *hw, unsigned long req_rate,
unsigned long *parent_rate)+static int ingenic_clk_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req){ struct ingenic_clk *ingenic_clk = to_ingenic_clk(hw); const struct ingenic_cgu_clk_info *clk_info = to_clk_info(ingenic_clk); unsigned int div = 1;
if (clk_info->type & CGU_CLK_DIV)
div = ingenic_clk_calc_div(hw, clk_info, *parent_rate,req_rate);
div = ingenic_clk_calc_div(hw, clk_info, req->best_parent_rate,req->rate);Sorry but I'm not sure that this works.
You replace the "parent_rate" with the "best_parent_rate", and that means you only check the requested rate vs. the parent with the highest frequency, and not vs. the actual parent that will be used.
best_parent_rate is initialized to the current parent rate, not the parent with the highest frequency: https://elixir.bootlin.com/linux/v6.1-rc3/source/drivers/clk/clk.c#L1471
Maxime
Hi Paul,
On Sat, Nov 05, 2022 at 10:33:54AM +0000, Paul Cercueil wrote:
Hi Maxime,
Le ven. 4 nov. 2022 à 15:59:46 +0100, Maxime Ripard maxime@cerno.tech a écrit :
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent hook,
but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name
implies,
change the parent of a clock. However, the most likely candidate
to
trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for
a
given rate.
The other trigger would be a call to clk_set_parent(), but it's
far less
used, and it doesn't look like there's any obvious user for that
clock.
So, the set_parent hook is effectively unused, possibly because
of an
oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit
call to
clk_set_parent().
The driver does implement round_rate() though, which means that
we can
change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or
not.
Since we'll start mandating a determine_rate() implementation,
let's
convert the round_rate() implementation to a determine_rate(),
which
will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent callback; in my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when requesting a rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or not it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a clock re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about it. The determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never ask to change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
But that would introduce policy into the driver...
I'm not sure why you're bringing policies into that discussion. There's plenty of policy in the driver already, and the current code doesn't do something that the old wasn't doing (implicitly).
And there's plenty of policies in drivers in general. Whether you limit the rate or not, whether you allow reparenting or not, even the CLK_SET_RATE_NO_REPARENT flag mentioned above is a policy decision set by drivers.
The fact that I don't want the MMC parented to the PLLs, doesn't mean that it's an invalid configuration per se.
Sure, and that's another policy :)
Maxime
Hi Maxime,
Le mer. 9 nov. 2022 à 11:53:01 +0100, Maxime Ripard maxime@cerno.tech a écrit :
Hi Paul,
On Sat, Nov 05, 2022 at 10:33:54AM +0000, Paul Cercueil wrote:
Hi Maxime,
Le ven. 4 nov. 2022 à 15:59:46 +0100, Maxime Ripard maxime@cerno.tech a écrit :
Hi Paul,
On Fri, Nov 04, 2022 at 02:31:20PM +0000, Paul Cercueil wrote:
Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard maxime@cerno.tech a écrit :
The Ingenic CGU clocks implements a mux with a set_parent
hook,
but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its
name
implies,
change the parent of a clock. However, the most likely
candidate
to
trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best
suited for
a
given rate.
The other trigger would be a call to clk_set_parent(), but
it's
far less
used, and it doesn't look like there's any obvious user for
that
clock.
So, the set_parent hook is effectively unused, possibly
because
of an
oversight. However, it could also be an explicit decision by
the
original author to avoid any reparenting but through an
explicit
call to
clk_set_parent().
The driver does implement round_rate() though, which means
that
we can
change the rate of the clock, but we will never get to
change the
parent.
However, It's hard to tell whether it's been done on purpose
or
not.
Since we'll start mandating a determine_rate()
implementation,
let's
convert the round_rate() implementation to a
determine_rate(),
which
will also make the current behavior explicit. And if it was
an
oversight, the clock behaviour can be adjusted later on.
So it's partly on purpose, partly because I didn't know about .determine_rate.
There's nothing odd about having a lonely .set_parent
callback; in
my case the clocks are parented from the device tree.
Having the clocks driver trigger a parent change when
requesting a
rate change sounds very dangerous, IMHO. My MMC controller can be parented to the external 48 MHz oscillator, and if the card requests 50 MHz, it could switch to one of the PLLs. That works as long as the PLLs don't change rate, but if one is configured as driving the CPU clock, it becomes messy. The thing is, the clocks driver has no way to know whether or
not
it is "safe" to use a designated parent.
For that reason, in practice, I never actually want to have a
clock
re-parented - it's almost always a bad idea vs. sticking to the parent clock configured in the DTS.
Yeah, and this is totally fine. But we need to be explicit about
it. The
determine_rate implementation I did in all the patches is an exact equivalent to the round_rate one if there was one. We will never
ask to
change the parent.
Given what you just said, I would suggest to set the CLK_SET_RATE_NO_REPARENT flag as well.
But that would introduce policy into the driver...
I'm not sure why you're bringing policies into that discussion. There's plenty of policy in the driver already, and the current code doesn't do something that the old wasn't doing (implicitly).
Yes, I was just talking about the CLK_SET_RATE_NO_REPARENT flag adding policy. The fact that there's plenty of policy in the driver already is not an argument for adding some more.
And there's plenty of policies in drivers in general. Whether you limit the rate or not, whether you allow reparenting or not, even the CLK_SET_RATE_NO_REPARENT flag mentioned above is a policy decision set by drivers.
Allowing reparenting and not limiting the rates is not a policy, it's just following what the hardware allows you to do. The absence of policy means that the driver allows you to configure the hardware in any way you might want to.
Limiting rates, forbidding reparenting, that's policy, and it doesn't belong in a driver.
You can argue that choosing not to reparent on rate change is a policy, and it is. That's why we need a way to enforce these policies outside the driver.
The fact that I don't want the MMC parented to the PLLs, doesn't mean that it's an invalid configuration per se.
Sure, and that's another policy :)
A policy that is not enforced by the driver.
Going back to the patch itself... I am fine with the change, although the patch description should probably be updated. We have .set_parent callbacks to configure clocks from DT, there's nothing more to it.
Cheers, -Paul
The Ingenic TCU clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/ingenic/tcu.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c index d5544cbc5c48..7d04ef40b7cf 100644 --- a/drivers/clk/ingenic/tcu.c +++ b/drivers/clk/ingenic/tcu.c @@ -178,18 +178,21 @@ static u8 ingenic_tcu_get_prescale(unsigned long rate, unsigned long req_rate) return 5; /* /1024 divider */ }
-static long ingenic_tcu_round_rate(struct clk_hw *hw, unsigned long req_rate, - unsigned long *parent_rate) +static int ingenic_tcu_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { - unsigned long rate = *parent_rate; + unsigned long rate = req->best_parent_rate; u8 prescale;
- if (req_rate > rate) - return rate; + if (req->rate > rate) { + req->rate = rate; + return 0; + }
- prescale = ingenic_tcu_get_prescale(rate, req_rate); + prescale = ingenic_tcu_get_prescale(rate, req->rate);
- return rate >> (prescale * 2); + req->rate = rate >> (prescale * 2); + return 0; }
static int ingenic_tcu_set_rate(struct clk_hw *hw, unsigned long req_rate, @@ -219,7 +222,7 @@ static const struct clk_ops ingenic_tcu_clk_ops = { .set_parent = ingenic_tcu_set_parent,
.recalc_rate = ingenic_tcu_recalc_rate, - .round_rate = ingenic_tcu_round_rate, + .determine_rate = ingenic_tcu_determine_rate, .set_rate = ingenic_tcu_set_rate,
.enable = ingenic_tcu_enable,
The Spreadtrum composite clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/sprd/composite.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sprd/composite.c b/drivers/clk/sprd/composite.c index ebb644820b1e..d3a852720c07 100644 --- a/drivers/clk/sprd/composite.c +++ b/drivers/clk/sprd/composite.c @@ -9,13 +9,19 @@
#include "composite.h"
-static long sprd_comp_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int sprd_comp_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct sprd_comp *cc = hw_to_sprd_comp(hw); + unsigned long rate;
- return sprd_div_helper_round_rate(&cc->common, &cc->div, - rate, parent_rate); + rate = sprd_div_helper_round_rate(&cc->common, &cc->div, + req->rate, &req->best_parent_rate); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static unsigned long sprd_comp_recalc_rate(struct clk_hw *hw, @@ -53,7 +59,7 @@ const struct clk_ops sprd_comp_ops = { .get_parent = sprd_comp_get_parent, .set_parent = sprd_comp_set_parent,
- .round_rate = sprd_comp_round_rate, + .determine_rate = sprd_comp_determine_rate, .recalc_rate = sprd_comp_recalc_rate, .set_rate = sprd_comp_set_rate, };
On Fri, 4 Nov 2022 at 21:33, Maxime Ripard maxime@cerno.tech wrote:
The Spreadtrum composite clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech
Acked-by: Chunyan Zhang zhang.lyra@gmail.com
Thanks, Chunyan
drivers/clk/sprd/composite.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sprd/composite.c b/drivers/clk/sprd/composite.c index ebb644820b1e..d3a852720c07 100644 --- a/drivers/clk/sprd/composite.c +++ b/drivers/clk/sprd/composite.c @@ -9,13 +9,19 @@
#include "composite.h"
-static long sprd_comp_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)+static int sprd_comp_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req){ struct sprd_comp *cc = hw_to_sprd_comp(hw);
unsigned long rate;
return sprd_div_helper_round_rate(&cc->common, &cc->div,rate, parent_rate);
rate = sprd_div_helper_round_rate(&cc->common, &cc->div,req->rate, &req->best_parent_rate);if (rate < 0)return rate;req->rate = rate;return 0;}
static unsigned long sprd_comp_recalc_rate(struct clk_hw *hw, @@ -53,7 +59,7 @@ const struct clk_ops sprd_comp_ops = { .get_parent = sprd_comp_get_parent, .set_parent = sprd_comp_set_parent,
.round_rate = sprd_comp_round_rate,
.determine_rate = sprd_comp_determine_rate, .recalc_rate = sprd_comp_recalc_rate, .set_rate = sprd_comp_set_rate,};
-- b4 0.11.0-dev-99e3a
The ST Flexgen clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/st/clk-flexgen.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/st/clk-flexgen.c b/drivers/clk/st/clk-flexgen.c index 7ae4f656191e..5292208c4dd8 100644 --- a/drivers/clk/st/clk-flexgen.c +++ b/drivers/clk/st/clk-flexgen.c @@ -119,20 +119,21 @@ clk_best_div(unsigned long parent_rate, unsigned long rate) return parent_rate / rate + ((rate > (2*(parent_rate % rate))) ? 0 : 1); }
-static long flexgen_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *prate) +static int flexgen_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { unsigned long div;
/* Round div according to exact prate and wished rate */ - div = clk_best_div(*prate, rate); + div = clk_best_div(req->best_parent_rate, req->rate);
if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) { - *prate = rate * div; - return rate; + req->best_parent_rate = req->rate * div; + return 0; }
- return *prate / div; + req->rate = req->best_parent_rate / div; + return 0; }
static unsigned long flexgen_recalc_rate(struct clk_hw *hw, @@ -197,7 +198,7 @@ static const struct clk_ops flexgen_ops = { .is_enabled = flexgen_is_enabled, .get_parent = flexgen_get_parent, .set_parent = flexgen_set_parent, - .round_rate = flexgen_round_rate, + .determine_rate = flexgen_determine_rate, .recalc_rate = flexgen_recalc_rate, .set_rate = flexgen_set_rate, };
The STM32 composite clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/stm32/clk-stm32-core.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/stm32/clk-stm32-core.c b/drivers/clk/stm32/clk-stm32-core.c index 3247539683c9..4027ca7d9806 100644 --- a/drivers/clk/stm32/clk-stm32-core.c +++ b/drivers/clk/stm32/clk-stm32-core.c @@ -349,14 +349,15 @@ static int clk_stm32_divider_set_rate(struct clk_hw *hw, unsigned long rate, return ret; }
-static long clk_stm32_divider_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *prate) +static int clk_stm32_divider_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct clk_stm32_div *div = to_clk_stm32_divider(hw); const struct stm32_div_cfg *divider; + unsigned long rate;
if (div->div_id == NO_STM32_DIV) - return rate; + return 0;
divider = &div->clock_data->dividers[div->div_id];
@@ -367,14 +368,24 @@ static long clk_stm32_divider_round_rate(struct clk_hw *hw, unsigned long rate, val = readl(div->base + divider->offset) >> divider->shift; val &= clk_div_mask(divider->width);
- return divider_ro_round_rate(hw, rate, prate, divider->table, - divider->width, divider->flags, - val); + rate = divider_ro_round_rate(hw, req->rate, &req->best_parent_rate, + divider->table, divider->width, divider->flags, + val); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
- return divider_round_rate_parent(hw, clk_hw_get_parent(hw), - rate, prate, divider->table, - divider->width, divider->flags); + rate = divider_round_rate_parent(hw, clk_hw_get_parent(hw), + req->rate, &req->best_parent_rate, + divider->table, divider->width, divider->flags); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static unsigned long clk_stm32_divider_recalc_rate(struct clk_hw *hw, @@ -602,7 +613,7 @@ static void clk_stm32_composite_disable_unused(struct clk_hw *hw) const struct clk_ops clk_stm32_composite_ops = { .set_rate = clk_stm32_composite_set_rate, .recalc_rate = clk_stm32_composite_recalc_rate, - .round_rate = clk_stm32_composite_round_rate, + .determine_rate = clk_stm32_composite_determine_rate, .get_parent = clk_stm32_composite_get_parent, .set_parent = clk_stm32_composite_set_parent, .enable = clk_stm32_composite_gate_enable,
The Tegra periph clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/tegra/clk-periph.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c index 367396c62259..ce8cab5f1978 100644 --- a/drivers/clk/tegra/clk-periph.c +++ b/drivers/clk/tegra/clk-periph.c @@ -45,16 +45,22 @@ static unsigned long clk_periph_recalc_rate(struct clk_hw *hw, return div_ops->recalc_rate(div_hw, parent_rate); }
-static long clk_periph_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *prate) +static int clk_periph_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct tegra_clk_periph *periph = to_clk_periph(hw); const struct clk_ops *div_ops = periph->div_ops; struct clk_hw *div_hw = &periph->divider.hw; + unsigned long rate;
__clk_hw_set_clk(div_hw, hw);
- return div_ops->round_rate(div_hw, rate, prate); + rate = div_ops->round_rate(div_hw, req->rate, &req->best_parent_rate); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static int clk_periph_set_rate(struct clk_hw *hw, unsigned long rate, @@ -130,7 +136,7 @@ const struct clk_ops tegra_clk_periph_ops = { .get_parent = clk_periph_get_parent, .set_parent = clk_periph_set_parent, .recalc_rate = clk_periph_recalc_rate, - .round_rate = clk_periph_round_rate, + .determine_rate = clk_periph_determine_rate, .set_rate = clk_periph_set_rate, .is_enabled = clk_periph_is_enabled, .enable = clk_periph_enable, @@ -154,7 +160,7 @@ static const struct clk_ops tegra_clk_periph_no_gate_ops = { .get_parent = clk_periph_get_parent, .set_parent = clk_periph_set_parent, .recalc_rate = clk_periph_recalc_rate, - .round_rate = clk_periph_round_rate, + .determine_rate = clk_periph_determine_rate, .set_rate = clk_periph_set_rate, .restore_context = clk_periph_restore_context, };
The Tegra super clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/tegra/clk-super.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/tegra/clk-super.c b/drivers/clk/tegra/clk-super.c index 8ad62e04fd8b..c035f0eb030d 100644 --- a/drivers/clk/tegra/clk-super.c +++ b/drivers/clk/tegra/clk-super.c @@ -142,15 +142,22 @@ static const struct clk_ops tegra_clk_super_mux_ops = { .restore_context = clk_super_mux_restore_context, };
-static long clk_super_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int clk_super_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct tegra_clk_super_mux *super = to_clk_super_mux(hw); struct clk_hw *div_hw = &super->frac_div.hw; + unsigned long rate;
__clk_hw_set_clk(div_hw, hw);
- return super->div_ops->round_rate(div_hw, rate, parent_rate); + rate = super->div_ops->round_rate(div_hw, req->rate, + &req->best_parent_rate); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static unsigned long clk_super_recalc_rate(struct clk_hw *hw, @@ -193,7 +200,7 @@ const struct clk_ops tegra_clk_super_ops = { .get_parent = clk_super_get_parent, .set_parent = clk_super_set_parent, .set_rate = clk_super_set_rate, - .round_rate = clk_super_round_rate, + .determine_rate = clk_super_determine_rate, .recalc_rate = clk_super_recalc_rate, .restore_context = clk_super_restore_context, };
The tlv320aic32x4 PLL clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- sound/soc/codecs/tlv320aic32x4-clk.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c index 65b72373cb95..d8b8ea3eaa12 100644 --- a/sound/soc/codecs/tlv320aic32x4-clk.c +++ b/sound/soc/codecs/tlv320aic32x4-clk.c @@ -205,18 +205,23 @@ static unsigned long clk_aic32x4_pll_recalc_rate(struct clk_hw *hw, return clk_aic32x4_pll_calc_rate(&settings, parent_rate); }
-static long clk_aic32x4_pll_round_rate(struct clk_hw *hw, - unsigned long rate, - unsigned long *parent_rate) +static int clk_aic32x4_pll_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { struct clk_aic32x4_pll_muldiv settings; + unsigned long rate; int ret;
- ret = clk_aic32x4_pll_calc_muldiv(&settings, rate, *parent_rate); + ret = clk_aic32x4_pll_calc_muldiv(&settings, req->rate, req->best_parent_rate); if (ret < 0) - return 0; + return -EINVAL;
- return clk_aic32x4_pll_calc_rate(&settings, *parent_rate); + rate = clk_aic32x4_pll_calc_rate(&settings, req->best_parent_rate); + if (rate < 0) + return rate; + + req->rate = rate; + return 0; }
static int clk_aic32x4_pll_set_rate(struct clk_hw *hw, @@ -267,7 +272,7 @@ static const struct clk_ops aic32x4_pll_ops = { .unprepare = clk_aic32x4_pll_unprepare, .is_prepared = clk_aic32x4_pll_is_prepared, .recalc_rate = clk_aic32x4_pll_recalc_rate, - .round_rate = clk_aic32x4_pll_round_rate, + .determine_rate = clk_aic32x4_pll_determine_rate, .set_rate = clk_aic32x4_pll_set_rate, .set_parent = clk_aic32x4_pll_set_parent, .get_parent = clk_aic32x4_pll_get_parent,
The tlv320aic32x4 divider clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Signed-off-by: Maxime Ripard maxime@cerno.tech --- sound/soc/codecs/tlv320aic32x4-clk.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c index d8b8ea3eaa12..707c9951fac0 100644 --- a/sound/soc/codecs/tlv320aic32x4-clk.c +++ b/sound/soc/codecs/tlv320aic32x4-clk.c @@ -333,16 +333,17 @@ static int clk_aic32x4_div_set_rate(struct clk_hw *hw, unsigned long rate, AIC32X4_DIV_MASK, divisor); }
-static long clk_aic32x4_div_round_rate(struct clk_hw *hw, unsigned long rate, - unsigned long *parent_rate) +static int clk_aic32x4_div_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req) { unsigned long divisor;
- divisor = DIV_ROUND_UP(*parent_rate, rate); + divisor = DIV_ROUND_UP(req->best_parent_rate, req->rate); if (divisor > 128) return -EINVAL;
- return DIV_ROUND_UP(*parent_rate, divisor); + req->rate = DIV_ROUND_UP(req->best_parent_rate, divisor); + return 0; }
static unsigned long clk_aic32x4_div_recalc_rate(struct clk_hw *hw, @@ -361,7 +362,7 @@ static const struct clk_ops aic32x4_div_ops = { .prepare = clk_aic32x4_div_prepare, .unprepare = clk_aic32x4_div_unprepare, .set_rate = clk_aic32x4_div_set_rate, - .round_rate = clk_aic32x4_div_round_rate, + .determine_rate = clk_aic32x4_div_determine_rate, .recalc_rate = clk_aic32x4_div_recalc_rate, };
@@ -389,7 +390,7 @@ static const struct clk_ops aic32x4_bdiv_ops = { .set_parent = clk_aic32x4_bdiv_set_parent, .get_parent = clk_aic32x4_bdiv_get_parent, .set_rate = clk_aic32x4_div_set_rate, - .round_rate = clk_aic32x4_div_round_rate, + .determine_rate = clk_aic32x4_div_determine_rate, .recalc_rate = clk_aic32x4_div_recalc_rate, };
The determine_rate hook allows to select the proper parent and its rate for a given clock configuration. On another hand, set_parent is there to change the parent of a mux.
Some clocks provide a set_parent hook but don't implement determine_rate. In such a case, set_parent is pretty much useless since the clock framework will always assume the current parent is to be used, and we will thus never change it.
This situation can be solved in two ways: - either we don't need to change the parent, and we thus shouldn't implement set_parent; - or we don't want to change the parent, in this case we should set CLK_SET_RATE_NO_REPARENT; - or we're missing a determine_rate implementation.
The latter is probably just an oversight from the driver's author, and we should thus raise their awareness about the fact that the current state of the driver is confusing.
It's not clear at this point how many drivers are affected though, so let's make it a warning instead of an error for now.
Reviewed-by: AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com Signed-off-by: Maxime Ripard maxime@cerno.tech --- drivers/clk/clk.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 495d7497cc43..9eb0343629cc 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -3701,6 +3701,13 @@ static int __clk_core_init(struct clk_core *core) goto out; }
+ if (core->ops->set_parent && !core->ops->determine_rate) { + pr_err("%s: %s must implement .set_parent & .determine_rate\n", + __func__, core->name); + ret = -EINVAL; + goto out; + } + if (core->num_parents > 1 && !core->ops->get_parent) { pr_err("%s: %s must implement .get_parent as it has multi parents\n", __func__, core->name);
On Fri, Nov 04, 2022 at 02:18:22PM +0100, Maxime Ripard wrote:
The determine_rate hook allows to select the proper parent and its rate for a given clock configuration. On another hand, set_parent is there to change the parent of a mux.
Some clocks provide a set_parent hook but don't implement determine_rate. In such a case, set_parent is pretty much useless since the clock framework will always assume the current parent is to be used, and we will thus never change it.
This situation can be solved in two ways:
- either we don't need to change the parent, and we thus shouldn't implement set_parent;
- or we don't want to change the parent, in this case we should set CLK_SET_RATE_NO_REPARENT;
- or we're missing a determine_rate implementation.
The latter is probably just an oversight from the driver's author, and we should thus raise their awareness about the fact that the current state of the driver is confusing.
It's not clear at this point how many drivers are affected though, so let's make it a warning instead of an error for now.
Commit message could probably use updated to make the new state of the chain.
Thanks, Charles
Quoting Maxime Ripard (2022-11-04 06:17:17)
Hi,
This is a follow-up to a previous series that was printing a warning when a mux has a set_parent implementation but is missing determine_rate().
The rationale is that set_parent() is very likely to be useful when changing the rate, but it's determine_rate() that takes the parenting decision. If we're missing it, then the current parent is always going to be used, and thus set_parent() will not be used. The only exception being a direct call to clk_set_parent(), but those are fairly rare compared to clk_set_rate().
Stephen then asked to promote the warning to an error, and to fix up all the muxes that are in that situation first. So here it is :)
Let me know what you think,
What's the plan here? Are you going to resend?
Hi Stephen,
On Tue, Mar 21, 2023 at 04:55:03PM -0700, Stephen Boyd wrote:
Quoting Maxime Ripard (2022-11-04 06:17:17)
Hi,
This is a follow-up to a previous series that was printing a warning when a mux has a set_parent implementation but is missing determine_rate().
The rationale is that set_parent() is very likely to be useful when changing the rate, but it's determine_rate() that takes the parenting decision. If we're missing it, then the current parent is always going to be used, and thus set_parent() will not be used. The only exception being a direct call to clk_set_parent(), but those are fairly rare compared to clk_set_rate().
Stephen then asked to promote the warning to an error, and to fix up all the muxes that are in that situation first. So here it is :)
Let me know what you think,
What's the plan here? Are you going to resend?
It wasn't clear to me whether or not this was something that you wanted, and I got some pushback on the drivers so I kind of forgot about it.
If you do want it (and it looks like you do), I'll resend it.
Maxime
Quoting Maxime Ripard (2023-03-22 03:01:53)
Hi Stephen,
On Tue, Mar 21, 2023 at 04:55:03PM -0700, Stephen Boyd wrote:
Quoting Maxime Ripard (2022-11-04 06:17:17)
Hi,
This is a follow-up to a previous series that was printing a warning when a mux has a set_parent implementation but is missing determine_rate().
The rationale is that set_parent() is very likely to be useful when changing the rate, but it's determine_rate() that takes the parenting decision. If we're missing it, then the current parent is always going to be used, and thus set_parent() will not be used. The only exception being a direct call to clk_set_parent(), but those are fairly rare compared to clk_set_rate().
Stephen then asked to promote the warning to an error, and to fix up all the muxes that are in that situation first. So here it is :)
Let me know what you think,
What's the plan here? Are you going to resend?
It wasn't clear to me whether or not this was something that you wanted, and I got some pushback on the drivers so I kind of forgot about it.
If you do want it (and it looks like you do), I'll resend it.
Let me read the whole series first. I was ignoring it because I was assuming it was going to be resent.
participants (13)
-
Aidan MacDonald -
Charles Keepax -
Chunyan Zhang -
David Lechner -
Geert Uytterhoeven -
Lee Jones -
Liam Beguin -
Linus Walleij -
Mark Brown -
Maxime Ripard -
Paul Cercueil -
Stephen Boyd -
Ulf Hansson