31 Aug, 2016
1 commit
-
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
27 Aug, 2016
1 commit
-
__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
16 Aug, 2016
1 commit
-
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
13 Aug, 2016
2 commits
-
This code is clear enough, but the intention will be even clearer
with this.Signed-off-by: Masahiro Yamada
Signed-off-by: Stephen Boyd -
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
12 Aug, 2016
1 commit
-
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
02 Jul, 2016
4 commits
-
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 -
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 -
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 -
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
21 Jun, 2016
2 commits
-
Correct comments for __clk_determine_rate.
Signed-off-by: Peng Fan
Cc: Michael Turquette
Cc: Stephen Boyd
Signed-off-by: Stephen Boyd -
Signed-off-by: Lee Jones
Signed-off-by: Stephen Boyd
17 Jun, 2016
1 commit
16 Jun, 2016
2 commits
-
This commit fixes the RCU use-from-idle bug corresponding the following
splat:> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1127 Not tainted
> -------------------------------
> include/trace/events/clk.h:45 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 2 locks held by swapper/0/0:
> #0: (&oh->hwmod_key#30){......}, at: [] omap_hwmod_enable+0x18/0x44
> #1: (enable_lock){......}, at: [] clk_enable_lock+0x18/0x124
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1127
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb0/0xe4)
> [] (dump_stack) from [] (clk_core_enable+0x1e0/0x36c)
> [] (clk_core_enable) from [] (clk_enable+0x1c/0x38)
> [] (clk_enable) from [] (_enable_clocks+0x18/0x7c)
> [] (_enable_clocks) from [] (_enable+0x114/0x2ec)
> [] (_enable) from [] (omap_hwmod_enable+0x24/0x44)
> [] (omap_hwmod_enable) from [] (omap_device_enable+0x3c/0x90)
> [] (omap_device_enable) from [] (_od_runtime_resume+0x10/0x38)
> [] (_od_runtime_resume) from [] (__rpm_callback+0x2c/0x60)
> [] (__rpm_callback) from [] (rpm_callback+0x20/0x80)
> [] (rpm_callback) from [] (rpm_resume+0x3d0/0x6f0)
> [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64)
> [] (__pm_runtime_resume) from [] (omap2_gpio_resume_after_idle+0x54/0x68)
> [] (omap2_gpio_resume_after_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
> [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
> [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
> [] (start_kernel) from [] (0x8000807c)Reported-by: Tony Lindgren
Signed-off-by: Paul E. McKenney
Tested-by: Tony Lindgren
Tested-by: Guenter Roeck
Cc: Russell King
Cc: Steven Rostedt
Cc: Michael Turquette
Cc: Stephen Boyd
Cc:
Cc:
Cc: -
This commit adds an _rcuidle suffix to a pair of trace events to
prevent the following splat:> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1114 Not tainted
> -------------------------------
> include/trace/events/clk.h:59 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 2 locks held by swapper/0/0:
> #0: (&oh->hwmod_key#30){......}, at: [] omap_hwmod_idle+0x18/0x44
> #1: (enable_lock){......}, at: [] clk_enable_lock+0x18/0x124
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1114
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb0/0xe4)
> [] (dump_stack) from [] (clk_core_disable+0x17c/0x348)
> [] (clk_core_disable) from [] (clk_disable+0x24/0x30)
> [] (clk_disable) from [] (_disable_clocks+0x18/0x7c)
> [] (_disable_clocks) from [] (_idle+0x12c/0x230)
> [] (_idle) from [] (omap_hwmod_idle+0x24/0x44)
> [] (omap_hwmod_idle) from [] (omap_device_idle+0x3c/0x90)
> [] (omap_device_idle) from [] (__rpm_callback+0x2c/0x60)
> [] (__rpm_callback) from [] (rpm_callback+0x20/0x80)
> [] (rpm_callback) from [] (rpm_suspend+0x100/0x768)
> [] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84)
> [] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70)
> [] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244)
> [] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
> [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
> [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
> [] (start_kernel) from [] (0x8000807c)Reported-by: Tony Lindgren
Signed-off-by: Paul E. McKenney
Tested-by: Tony Lindgren
Tested-by: Guenter Roeck
Cc: Russell King
Cc: Steven Rostedt
Cc: Michael Turquette
Cc: Stephen Boyd
Cc:
Cc:
Cc:
20 May, 2016
1 commit
-
The critical clock handling in __clk_core_init isn't taking the enable lock
before calling clk_core_enable, which in turns triggers the warning in the
lockdep_assert_held call in that function when lockep is enabled.Add the calls to clk_enable_lock/unlock to make sure it doesn't happen.
Fixes: 32b9b1096186 ("clk: Allow clocks to be marked as CRITICAL")
Signed-off-by: Maxime Ripard
Reviewed-by: Heiko Stuebner
Tested-by: Heiko Stuebner
Signed-off-by: Stephen Boyd
03 May, 2016
1 commit
-
Unlike devm_clk_register(), devm_clk_hw_register() returns integer.
So, the statement "Clocks returned from this function ..." sounds
odd. Adjust the comment for this new API.Signed-off-by: Masahiro Yamada
Signed-off-by: Stephen Boyd
22 Apr, 2016
1 commit
-
* 'clk-hw-register' (early part):
clk: fixed-rate: Add hw based registration APIs
clk: gpio: Add hw based registration APIs
clk: composite: Add hw based registration APIs
clk: fractional-divider: Add hw based registration APIs
clk: fixed-factor: Add hw based registration APIs
clk: mux: Add hw based registration APIs
clk: gate: Add hw based registration APIs
clk: divider: Add hw based registration APIs
clkdev: Add clk_hw based registration APIs
clk: Add clk_hw OF clk providers
clk: Add {devm_}clk_hw_{register,unregister}() APIs
clkdev: Remove clk_register_clkdevs()
20 Apr, 2016
2 commits
-
Now that we have a clk registration API that doesn't return
struct clks, we need to have some way to hand out struct clks via
the clk_get() APIs that doesn't involve associating struct clk
pointers with an OF node. Currently we ask the OF provider to
give us a struct clk pointer for some clkspec, turn that struct
clk into a struct clk_hw and then allocate a new struct clk to
return to the caller.Let's add a clk_hw based OF provider hook that returns a struct
clk_hw directly, so that we skip the intermediate step of
converting from struct clk to struct clk_hw. Eventually when
we've converted all OF clk providers to struct clk_hw based APIs
we can remove the struct clk based ones.It should also be noted that we change the onecell provider to
have a flex array instead of a pointer for the array of clk_hw
pointers. This allows providers to allocate one structure of the
correct length in one step instead of two.Signed-off-by: Stephen Boyd
-
We've largely split the clk consumer and provider APIs along
struct clk and struct clk_hw, but clk_register() still returns a
struct clk pointer for each struct clk_hw that's registered.
Eventually we'd like to only allocate struct clks when there's a
user, because struct clk is per-user now, so clk_register() needs
to change.Let's add new APIs to register struct clk_hws, but this time
we'll hide the struct clk from the caller by returning an int
error code. Also add an unregistration API that takes the clk_hw
structure that was passed to the registration API. This way
provider drivers never have to deal with a struct clk pointer
unless they're using the clk consumer APIs.Signed-off-by: Stephen Boyd
10 Apr, 2016
3 commits
-
This call matches clocks which have been marked as critical in DT
and sets the appropriate flag. These flags can then be used to
mark the clock core flags appropriately prior to registration.Legacy bindings requiring this feature must add the clock-critical
property to their binding descriptions, as it is not a part of
common-clock binding.Cc: devicetree@vger.kernel.org
Signed-off-by: Lee Jones
Reviewed-by: Stephen Boyd
Signed-off-by: Michael Turquette
Link: lkml.kernel.org/r/1455225554-13267-4-git-send-email-mturquette@baylibre.com -
Signed-off-by: Lee Jones
Reviewed-by: Stephen Boyd
Signed-off-by: Michael Turquette
Link: lkml.kernel.org/r/1455225554-13267-3-git-send-email-mturquette@baylibre.com -
Critical clocks are those which must not be gated, else undefined
or catastrophic failure would occur. Here we have chosen to
ensure the prepare/enable counts are correctly incremented, so as
not to confuse users with enabled clocks with no visible users.Signed-off-by: Lee Jones
Signed-off-by: Michael Turquette
Link: lkml.kernel.org/r/1455225554-13267-2-git-send-email-mturquette@baylibre.com
27 Feb, 2016
2 commits
-
Russell King recently pointed out a bug in the clk-gpio code
where it fails to register the clk if of_clk_get_parent_count()
returns an error because the "clocks" property isn't present in
the DT node. If we're trying to count parents from DT we'd like
to know the count, not if there is a "clocks" property or not.
Furthermore, some drivers are assigning the return value to their
clk_init_data::num_parents member which is unsigned, leading to
potentially large numbers of parents when the property isn't
present.Let's change the API to return an unsigned int instead of an int.
All the callers just want to know the count anyway, and this
avoids the bug that was in the clk-gpio driver.Signed-off-by: Stephen Boyd
-
of_clk_init() uses for_each_matching_node_and_match() to find clock
providers, which returns all matching device nodes, whether they are
enabled or not. Hence clock providers that are disabled explicitly in DT
using e.g."status = "disabled";
are still activated.
Add a check to ignore device nodes that are not enabled, like
of_irq_init() does.Reported-by: Ramesh Shanmugasundaram
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Stephen Boyd
26 Feb, 2016
1 commit
-
Let's compare the degrees from clk_set_rate with
clk->core->phase. If the requested degrees is already
there, skip the following steps.Signed-off-by: Shawn Lin
[sboyd@codeaurora.org: s/drgrees/degrees/ in commit text]
Signed-off-by: Stephen Boyd
23 Feb, 2016
2 commits
-
__clk_init() was renamed to __clk_core_init() but these comments
weren't updated.Cc: Masahiro Yamada
Signed-off-by: Stephen Boyd -
This reverts commit 858d5881564026cbc4e6f5e25ae878a27df5d4c9.
Joachim reports that this commit breaks lpc18xx boot. This is
because the hardware has circular clk topology where PLLs can
feed into dividers and the same dividers can feed into the PLLs.
The hardware is designed this way so that you can choose to put
the divider before the PLL or after the PLL depending on what you
configure to be the parent of the divider and what you configure
to be the parent of the PLL.So let's drop this patch for now because we have hardware that
actually has loops. A future patch could check for circular
parents when we change parents and fail the switch, but that's
probably best left to some debugging Kconfig option so that we
don't suffer the sanity checking cost all the time.Reported-by: Joachim Eastwood
Cc: Masahiro Yamada
Signed-off-by: Stephen Boyd
18 Feb, 2016
1 commit
-
Export symbol of_clk_get_from_provider so it can be used in
loadable kernel modulesSigned-off-by: Andrew F. Davis
Signed-off-by: Michael Turquette
10 Feb, 2016
1 commit
-
Before commit b3d192d5121f ("clk: simplify __clk_init_parent()"),
__clk_init_parent() called .get_parent() only for multi-parent
clocks. That commit changed the behavior to call .get_parent()
if available even for single-parent clocks and root clocks.It turned out a problem because there are some single-parent clocks
that implement .get_parent() callback and return non-zero index.
The SOCFPGA clock is the case; the commit broke the SOCFPGA boards.To keep the original behavior, invoke .get_parent() only when
num_parents is greater than 1.Fixes: b3d192d5121f ("clk: simplify __clk_init_parent()")
Signed-off-by: Masahiro Yamada
Reported-by: Dinh Nguyen
Signed-off-by: Stephen Boyd
07 Feb, 2016
1 commit
-
We don't use CLK_IS_ROOT but in a few places in the common clk
framework core. Let's replace those checks with a check for the
number of parents a clk has instead of the flag, freeing up one
flag for something else. We don't remove the flag yet so that
things keep building, but we'll remove it once all drivers have
removed their flag usage.Signed-off-by: Stephen Boyd
03 Feb, 2016
8 commits
-
If clock is already unregistered, it returns with holding lock.
It needs to be unlocked.Signed-off-by: Insu Yun
[sboyd@codeaurora.org: Use goto instead]
Signed-off-by: Stephen Boyd -
If clk_fetch_parent_index() fails, p_rate is unused. Move the
assignment after the error checking.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd -
The clk_core_get_parent_by_index can be used as a helper function
to simplify the implementation of clk_fetch_parent_index().Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd -
If parent is given with NULL, clk_fetch_parent_index() could return
a positive index value.Currently, parent is checked by the callers of this function, but
it would be safer to do it in this function.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd -
This loop can be much simpler. If a new parent is available for
orphan clocks, __clk_init_parent(orphan) can detect it.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd -
Currently, clk_register() never checks a circular parent looping,
but clock providers could register such an insane clock topology.
For example, "clk_a" could have "clk_b" as a parent, and vice versa.
In this case, clk_core_reparent() creates a circular parent list
and __clk_recalc_accuracies() calls itself recursively forever.The core infrastructure should be kind enough to bail out, showing
an appropriate error message in such a case. This helps to easily
find a bug in clock providers. (uh, I made such a silly mistake
when I was implementing my clock providers first. I was upset
because the kernel did not respond, without any error message.)This commit adds a new helper function, __clk_is_ancestor(). It
returns true if the second argument is a possible ancestor of the
first one. If a clock core is a possible ancestor of itself, it
would make a loop when it were registered. That should be detected
as an error.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd -
The translation from the index into clk_core is done by
clk_core_get_parent_by_index(). The if-block for num_parents == 1
case is duplicating the code in the clk_core_get_parent_by_index().Drop the "if (num_parents == 1)" from the special case. Instead,
set the index to zero if .get_parent() is missing.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd -
The .get_parent is mandatory for multi-parent clocks. Move the check
to __clk_core_init(), like other callback checkings.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
[sboyd@codeaurora.org: Squashed in error path handling, fix typos
in commit message]
Signed-off-by: Stephen Boyd
02 Feb, 2016
1 commit
-
These three cases let clk_register() fail. They should be considered
as error messages.Signed-off-by: Masahiro Yamada
Reviewed-by: Vladimir Zapolskiy
Signed-off-by: Stephen Boyd