Quoting Marek Vasut (2022-05-17 16:59:19) > Some platforms require select clock to be always running, e.g. because > those clock supply vital devices which are not otherwise attached to > the system and thus do not have a matching DT node and clock consumer. > > An example is a system where the SoC serves as a crystal oscillator > replacement for a programmable logic device. The "critical-clocks" > property of a clock controller allows listing clock which must never > be turned off. > > Clock listed in the "critical-clocks" property may have other consumers > in DT, listing the clock in "critical-clocks" only assures those clock > are never turned off, and none of these optional additional consumers > can turn the clock off either. This is achieved by adding CLK_IS_CRITICAL > flag to these critical clock. > > This flag has thus far been added to select clock by hard-coding it in > various clock drivers, this patch provides generic DT interface to add > the flag to arbitrary clock that may be critical. > > The implementation is modeled after "protected-clocks", except the protected > clock property is currently driver specific. This patch attempts to provide > a generic implementation of "critical-clocks" instead. > > Unlike "assigned-clocks", the "critical-clocks" must be parsed much earlier > in __clk_register() to assign CLK_IS_CRITICAL flag to clk_init_data .flags > field. Why? Instead of using the CLK_IS_CRITICAL flag to enable at registration time for this, why can't we parse the property when a clk provider is registered and enable those clks manually and then set the CLK_IS_CRITICAL flag? Ideally we don't implement another clk_op for this. > > The new match_clkspec() callback is used to determine whether struct clk_hw > that is currently being registered matches the clock specifier in the DT > "critical-clocks" property, and if so, then the CLK_IS_CRITICAL is added to > these newly registered clock. This callback can only be driver specific. > > Signed-off-by: Marek Vasut <marex@xxxxxxx>
