On Mon, Nov 07, 2022 at 08:57:22PM +0000, Aidan MacDonald wrote: > > Maxime Ripard <maxime@xxxxxxxxxx> writes: > > > Hi, > > > > On Fri, Nov 04, 2022 at 05:35:29PM +0000, Aidan MacDonald wrote: > >> > >> Maxime Ripard <maxime@xxxxxxxxxx> 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@xxxxxxxxxx> 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
