pm24.git/drivers/clk/clk.c, branch v4.9

clk: core: Force setting the phase delay when no change

2016-08-30T21:52:26Z

This patch reverts commit 023bd7166be0 ("clk: skip unnecessary set_phase if nothing to do"), fixing two problems: * in some SoCs, the hardware phase delay depends on the rate ratio of the clock and its parent. So, changing this ratio may imply to set new hardware values, even if the logical delay is the same. * when the delay was the same as previously, an error was returned. Signed-off-by: Jean-Francois Moine Fixes: 023bd7166be0 ("clk: skip unnecessary set_phase if nothing to do") Signed-off-by: Stephen Boyd

clk: Simplify __of_clk_get_hw_from_provider()

2016-08-26T19:28:27Z

__of_clk_get_hw_from_provider() is confusing because it will return EPROBE_DEFER if there isn't a ->get() or ->get_hw() function pointer in a provider. That's just a bug though, and we used to NULL pointer exception when ->get() was missing anyway, so let's make this more obvious that they're not optional. The assumption is that most providers will implement ->get_hw() so we only fallback to the ->get() function if necessary. This clarifies the intent and removes any possibility of probe defer happening if clk providers are buggy. Reported-by: Masahiro Yamada Reviewed-by: Sylwester Nawrocki Signed-off-by: Stephen Boyd

clk: Return errors from clk providers in __of_clk_get_from_provider()

2016-08-15T21:32:23Z

Before commit 0861e5b8cf80 (clk: Add clk_hw OF clk providers, 2016-02-05) __of_clk_get_from_provider() would return an error pointer of the provider's choosing if there was a provider registered and EPROBE_DEFER otherwise. After that commit, it would return EPROBE_DEFER regardless of whether or not the provider returned an error. This is odd and can lead to behavior where clk consumers keep probe deferring when they should be seeing some other error. Let's restore the previous behavior where we only return EPROBE_DEFER when there isn't a provider in our of_clk_providers list. Otherwise, return the error from the last provider we find that matches the node. Reported-by: Masahiro Yamada Fixes: 0861e5b8cf80 ("clk: Add clk_hw OF clk providers") Signed-off-by: Stephen Boyd

clk: use ERR_CAST() for __clk_create_clk()

2016-08-13T01:17:04Z

This code is clear enough, but the intention will be even clearer with this. Signed-off-by: Masahiro Yamada Signed-off-by: Stephen Boyd

clk: core: Avoid double initialization of clocks

2016-08-13T01:01:58Z

Some clock providers can be initialized via of_clk_init() and also via platform device probe. Avoid double initialization of them by setting the OF_POPULATED flag. Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Stephen Boyd

clk: migrate ref counts when orphans are reunited

2016-08-12T01:06:50Z

It's always nice to see families reunited, and this is equally true when talking about parent clocks and their children. However, if the orphan clk had a positive prepare_count or enable_count, then we would not migrate those counts up the parent chain correctly. This has manifested with the recent critical clocks feature, which often enables clocks very early, before their parents have been registered. Fixed by replacing the call to clk_core_reparent with calls to __clk_set_parent_{before,after}. Cc: James Liao Cc: Erin Lo Signed-off-by: Michael Turquette [sboyd@codeaurora.org: Recalc accuracies and rates too] Signed-off-by: Stephen Boyd

clk: core: support clocks which requires parents enable (part 2)

2016-07-02T00:42:56Z

On Freescale i.MX7D platform, all clocks operations, including enable/disable, rate change and re-parent, requires its parent clock on. Current clock core can not support it well. This patch adding flag CLK_OPS_PARENT_ENABLE to handle this special case in clock core that enable its parent clock firstly for each operation and disable it later after operation complete. The patch part 2 fixes set clock rate and set parent while its parent is off. The most special case is for set_parent() operation which requires all parents including both old and new one to be enabled at the same time during the operation. Cc: Michael Turquette Cc: Stephen Boyd Cc: Shawn Guo Signed-off-by: Dong Aisheng [sboyd@codeaurora.org: Move set_rate tracepoint after prepare_enable] Signed-off-by: Stephen Boyd

clk: core: support clocks which requires parents enable (part 1)

2016-07-02T00:40:23Z

On Freescale i.MX7D platform, all clocks operations, including enable/disable, rate change and re-parent, requires its parent clock enable. Current clock core can not support it well. This patch introduce a new flag CLK_OPS_PARENT_ENABLE to handle this special case in clock core that enable its parent clock firstly for each operation and disable it later after operation complete. The patch part 1 fixes the possible disabling clocks while its parent is off during kernel booting phase in clk_disable_unused_subtree(). Before the completion of kernel booting, clock tree is still not built completely, there may be a case that the child clock is on but its parent is off which could be caused by either HW initial reset state or bootloader initialization. Taking bootloader as an example, we may enable all clocks in HW by default. And during kernel booting time, the parent clock could be disabled in its driver probe due to calling clk_prepare_enable and clk_disable_unprepare. Because it's child clock is only enabled in HW while its SW usecount in clock tree is still 0, so clk_disable of parent clock will gate the parent clock in both HW and SW usecount ultimately. Then there will be a child clock is still on in HW but its parent is already off. Later in clk_disable_unused(), this clock disable accessing while its parent off will cause system hang due to the limitation of HW which must require its parent on. This patch simply enables the parent clock first before disabling if flag CLK_OPS_PARENT_ENABLE is set in clk_disable_unused_subtree(). This is a simple solution and only affects booting time. After kernel booting up the clock tree is already created, there will be no case that child is off but its parent is off. So no need do this checking for normal clk_disable() later. Cc: Michael Turquette Cc: Stephen Boyd Cc: Shawn Guo Signed-off-by: Dong Aisheng Signed-off-by: Stephen Boyd

clk: move clk_disable_unused after clk_core_disable_unprepare function

2016-07-02T00:40:20Z

No function level change, just moving code place. clk_disable_unused function will need to call clk_core_prepare_enable/ clk_core_disable_unprepare when adding CLK_OPS_PARENT_ENABLE features. So move it after clk_core_disable_unprepare to avoid adding forward declared functions later. Cc: Michael Turquette Cc: Stephen Boyd Cc: Shawn Guo Signed-off-by: Dong Aisheng Signed-off-by: Stephen Boyd

clk: introduce clk_core_enable_lock and clk_core_disable_lock functions

2016-07-02T00:40:18Z

This can be useful when clock core wants to enable/disable clocks. Then we don't have to convert the struct clk_core to struct clk to call clk_enable/clk_disable which is a bit un-align with exist using. And after introduce clk_core_{enable|disable}_lock, we can refine clk_enable and clk_disable a bit. As well as clk_core_{enable|disable}_lock, we also added clk_core_{prepare|unprepare}_lock and clk_core_prepare_enable/ clk_core_unprepare_disable for clock core to easily use. Cc: Michael Turquette Cc: Stephen Boyd Cc: Shawn Guo Signed-off-by: Dong Aisheng Signed-off-by: Stephen Boyd