1. 11 Dec, 2018 1 commit
  2. 05 Dec, 2018 1 commit
    • Matti Vaittinen's avatar
      clk: of-provider: look at parent if registered device has no provider info · 05502bf9
      Matti Vaittinen authored
      It seems to be usual for MFD devices that the created 'clock sub-device'
      do not have own DT node. The clock provider information is usually in the
      main device node which is owned by the MFD device. Change the devm variant
      of clk of-provider registration to check the parent device node if given
      device has no own node or if the node does not contain the #clock-cells
      property. In such case use the parent node if it contains the #clock-cells.
      Signed-off-by: default avatarMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      [sboyd@kernel.org: Add some comment in the code and pull out logic into
      a single function to return the provider device_node pointer]
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
  3. 04 Dec, 2018 1 commit
  4. 11 Oct, 2018 1 commit
  5. 03 Oct, 2018 2 commits
  6. 25 Jul, 2018 1 commit
  7. 06 Jul, 2018 1 commit
  8. 19 Jun, 2018 2 commits
    • Jerome Brunet's avatar
      clk: add duty cycle support · 9fba738a
      Jerome Brunet authored
      Add the possibility to apply and query the clock signal duty cycle ratio.
      This is useful when the duty cycle of the clock signal depends on some
      other parameters controlled by the clock framework.
      For example, the duty cycle of a divider may depends on the raw divider
      setting (ratio = N / div) , which is controlled by the CCF. In such case,
      going through the pwm framework to control the duty cycle ratio of this
      clock would be a burden.
      A clock provider is not required to implement the operation to set and get
      the duty cycle. If it does not implement .get_duty_cycle(), the ratio is
      assumed to be 50%.
      This change also adds a new flag, CLK_DUTY_CYCLE_PARENT. This flag should
      be used to indicate that a clock, such as gates and muxes, may inherit
      the duty cycle ratio of its parent clock. If a clock does not provide a
      get_duty_cycle() callback and has CLK_DUTY_CYCLE_PARENT, then the call
      will be directly forwarded to its parent clock, if any. For
      set_duty_cycle(), the clock should also have CLK_SET_RATE_PARENT for the
      call to be forwarded
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Link: lkml.kernel.org/r/20180619144141.8506-1-jbrunet@baylibre.com
    • Jerome Brunet's avatar
      clk: fix CLK_SET_RATE_GATE with clock rate protection · 9461f7b3
      Jerome Brunet authored
      CLK_SET_RATE_GATE should prevent any operation which may result in a rate
      change or glitch while the clock is prepared/enabled.
      IOW, the following sequence is not allowed anymore with CLK_SET_RATE_GATE:
      * clk_get()
      * clk_prepare_enable()
      * clk_get_rate()
      * clk_set_rate()
      At the moment this is enforced on the leaf clock of the operation, not
      along the tree. This problematic because, if a PLL has the CLK_RATE_GATE,
      it won't be enforced if the clk_set_rate() is called on its child clocks.
      Using clock rate protection, we can now enforce CLK_SET_RATE_GATE along the
      clock tree
      Acked-by: Linus Walleij's avatarLinus Walleij <linus.walleij@linaro.org>
      Tested-by: default avatarQuentin Schulz <quentin.schulz@free-electrons.com>
      Tested-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Link: lkml.kernel.org/r/20180619134051.16726-3-jbrunet@baylibre.com
  9. 15 Jun, 2018 1 commit
  10. 02 Jun, 2018 3 commits
  11. 19 Apr, 2018 1 commit
  12. 16 Apr, 2018 1 commit
    • Jerome Brunet's avatar
      clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux · 4ad69b80
      Jerome Brunet authored
      CLK_MUX_ROUND_CLOSEST is part of the clk_mux documentation but clk_mux
      directly calls __clk_mux_determine_rate(), which overrides the flag.
      As result, if clk_mux is instantiated with CLK_MUX_ROUND_CLOSEST, the
      flag will be ignored and the clock rounded down.
      To solve this, this patch expose clk_mux_determine_rate_flags() in the
      clk-provider API and uses it in the determine_rate() callback of clk_mux.
      Fixes: 15a02c1f ("clk: Add __clk_mux_determine_rate_closest")
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
  13. 19 Mar, 2018 2 commits
    • Shawn Lin's avatar
      clk: Don't show the incorrect clock phase · 1f9c63e8
      Shawn Lin authored
      It's found that the clock phase output from clk_summary is
      wrong compared to the actual phase reading from the register.
      cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
      sdio_sample     0        1        0 50000000          0 -22
      It exposes an issue that clk core, clk_core_get_phase, always
      returns the cached core->phase which should be either updated
      by calling clk_set_phase or directly from the first place the
      clk was registered.
      When registering the clk, the core->phase geting from ->get_phase()
      may return negative value indicating error. This is quite common
      since the clk's phase may be highly related to its parent chain,
      but it was temporarily orphan when registered, since its parent
      chains hadn't be ready at that time, so the clk drivers decide to
      return error in this case. However, if no clk_set_phase is called or
      maybe the ->set_phase() isn't even implemented, the core->phase would
      never be updated. This is wrong, and we should try to update it when
      all its parent chains are settled down, like the way of updating clock
      rate for that. But it's not deserved to complicate the code now and
      just update it anyway when calling clk_core_get_phase, which would be
      much simple and enough.
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Acked-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
    • Andy Shevchenko's avatar
      clk: Re-use DEFINE_SHOW_ATTRIBUTE() macro · fec0ef3f
      Andy Shevchenko authored
      ...instead of open coding file operations followed by custom ->open()
      callbacks per each attribute.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
  14. 16 Mar, 2018 1 commit
  15. 12 Mar, 2018 4 commits
    • Jerome Brunet's avatar
      clk: call the clock init() callback before any other ops callback · 541debae
      Jerome Brunet authored
      Some clocks may need to initialize things, whatever it is, before
      being able to properly operate. Move the .init() call before any
      other callback, such recalc_rate() or get_phase(), so the clock
      is properly setup before being used.
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
    • Jerome Brunet's avatar
      clk: fix determine rate error with pass-through clock · 04bf9ab3
      Jerome Brunet authored
      If we try to determine the rate of a pass-through clock (a clock which
      does not implement .round_rate() nor .determine_rate()),
      clk_core_round_rate_nolock() will directly forward the call to the
      parent clock. In the particular case where the pass-through actually
      does not have a parent, clk_core_round_rate_nolock() will directly
      return 0 with the requested rate still set to the initial request
      structure. This is interpreted as if the rate could be exactly achieved
      while it actually cannot be adjusted.
      This become a real problem when this particular pass-through clock is
      the parent of a mux with the flag CLK_SET_RATE_PARENT set. The
      pass-through clock will always report an exact match, get picked and
      finally error when the rate is actually getting set.
      This is fixed by setting the rate inside the req to 0 when core is NULL
      in clk_core_round_rate_nolock() (same as in __clk_determine_rate() when
      hw is NULL)
      Fixes: 0f6cc2b8 ("clk: rework calls to round and determine rate callbacks")
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
    • Jerome Brunet's avatar
      clk: migrate the count of orphaned clocks at init · 99652a46
      Jerome Brunet authored
      The orphan clocks reparents should migrate any existing count from the
      orphan clock to its new acestor clocks, otherwise we may have
      inconsistent counts in the tree and end-up with gated critical clocks
      Assuming we have two clocks, A and B.
      * Clock A has CLK_IS_CRITICAL flag set.
      * Clock B is an ancestor of A which can gate. Clock B gate is left
        enabled by the bootloader.
      Step 1: Clock A is registered. Since it is a critical clock, it is
      enabled. The clock being still an orphan, no parent are enabled.
      Step 2: Clock B is registered and reparented to clock A (potentially
      through several other clocks). We are now in situation where the enable
      count of clock A is 1 while the enable count of its ancestors is 0, which
      is not good.
      Step 3: in lateinit, clk_disable_unused() is called, the enable_count of
      clock B being 0, clock B is gated and and critical clock A actually gets
      This situation was found while adding fdiv_clk gates to the meson8b
      platform.  These clocks parent clk81 critical clock, which is the mother
      of all peripheral clocks in this system. Because of the issue described
      here, the system is crashing when clk_disable_unused() is called.
      The situation is solved by reverting
      commit f8f8f1d0 ("clk: Don't touch hardware when reparenting during registration").
      To avoid breaking again the situation described in this commit
      description, enabling critical clock should be done before walking the
      orphan list. This way, a parent critical clock may not be accidentally
      disabled due to the CLK_OPS_PARENT_ENABLE mechanism.
      Fixes: f8f8f1d0 ("clk: Don't touch hardware when reparenting during registration")
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Dong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: Heiko Stuebner's avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
    • Shawn Lin's avatar
      clk: update cached phase to respect the fact when setting phase · 7f95beea
      Shawn Lin authored
      It's found that the final phase set by driver doesn't match that of
      the output from clk_summary:
      dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 346
      mmc0: new ultra high speed SDR104 SDIO card at address 0001
      cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
      sdio_sample	0        1        0    50000000 0 0
      It seems the cached core->phase isn't updated after the clk was
      registered. So fix this issue by updating the core->phase if setting
      phase successfully.
      Fixes: 9e4d04ad ("clk: add clk_core_set_phase_nolock function")
      Cc: Stable <stable@vger.kernel.org>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Reviewed-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Tested-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
  16. 10 Jan, 2018 4 commits
    • David Lechner's avatar
      clk: fix reentrancy of clk_enable() on UP systems · a12aa8a6
      David Lechner authored
      Reentrant calls to clk_enable() are not working on UP systems. This is
      caused by the fact spin_trylock_irqsave() always returns true when
      CONFIG_SMP=n (and CONFIG_DEBUG_SPINLOCK=n) which causes the reference
      counting to not work correctly when clk_enable_lock() is called twice
      before clk_enable_unlock() is called (this happens when clk_enable()
      is called from within another clk_enable()).
      This fixes the problem by skipping the call to spin_trylock_irqsave() on UP
      systems and relying solely on reference counting. We also make sure to set
      flags in this case so that we are not returning an uninitialized value.
      Suggested-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarDavid Lechner <david@lechnology.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
    • Stephen Boyd's avatar
      clk: Simplify debugfs registration · db3188fa
      Stephen Boyd authored
      We don't need a goto here. Drop it.
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
    • Geert Uytterhoeven's avatar
      clk: Fix debugfs_create_*() usage · 4c8326d5
      Geert Uytterhoeven authored
      When exposing data access through debugfs, the correct
      debugfs_create_*() functions must be used, matching the data
      Remove all casts from data pointers passed to debugfs_create_*()
      functions, as such casts prevent the compiler from flagging bugs.
      clk_core.rate and .accuracy are "unsigned long", hence casting
      their addresses to "u32 *" exposed the wrong halves on big-endian
      64-bit systems. Fix this by using debugfs_create_ulong() instead.
      Octal permissions are preferred, as they are easier to read than
      symbolic permissions. Hence replace "S_IRUGO" by "0444"
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      [sboyd@codeaurora.org: Squash the octal change in too]
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
    • Geert Uytterhoeven's avatar
      clk: Show symbolic clock flags in debugfs · a6059ab9
      Geert Uytterhoeven authored
      Currently the virtual "clk_flags" file in debugfs shows the numeric
      value of the top-level framework flags for the specified clock.
      Hence the user must manually interpret these values.
      Moreover, on big-endian 64-bit systems, the wrong half of the value is
      shown, due to the cast from "unsigned long *" to "u32 *".
      Fix both issues by showing the symbolic flag names instead.
      Any non-standard flags are shown as a hex number.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
  17. 04 Jan, 2018 1 commit
  18. 27 Dec, 2017 1 commit
  19. 22 Dec, 2017 1 commit
    • Stephen Boyd's avatar
      clk: Don't touch hardware when reparenting during registration · f8f8f1d0
      Stephen Boyd authored
      The orphan clocks reparent operation shouldn't touch the hardware
      if clocks are enabled, otherwise it may get a chance to disable a
      newly registered critical clock which triggers the warning below.
      Assuming we have two clocks: A and B, B is the parent of A.
      Clock A has flag: CLK_OPS_PARENT_ENABLE
      Clock B has flag: CLK_IS_CRITICAL
      Step 1:
      Clock A is registered, then it becomes orphan.
      Step 2:
      Clock B is registered. Before clock B reach the critical clock enable
      operation, orphan A will find the newly registered parent B and do
      reparent operation, then parent B will be finally disabled in
      __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's
      still no users of B which will then trigger the following warning.
      WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373
      Hardware name: Generic DT based system
      [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c)
       r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000
      [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8)
      [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104)
       r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000
       r4:00000000 r3:c0e01d34
      [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30)
       r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80
      [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0)
      [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c)
       r4:000000d3 r3:c0e0af00
      [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28)
       r5:00000000 r4:ef00bf80
      [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54)
       r4:ef00bd80 r3:000010a0
      [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648)
       r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4
      [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c)
       r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500
      [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120)
      [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54)
       r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001
      [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98)
       r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808
      [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0)
       r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0
      [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38)
       r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000
      [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394)
      [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c)
       r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918
      We know that the clk isn't enabled with any sort of prepare_count
      here so we don't need to enable anything to prevent a race. And
      we're holding the prepare mutex so set_rate/set_parent can't race
      here either. Based on an earlier patch by Dong Aisheng.
      Fixes: fc8726a2 ("clk: core: support clocks which requires parents enable (part 2)")
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Reported-by: default avatarDong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
  20. 20 Dec, 2017 9 commits
  21. 19 Dec, 2017 1 commit
    • Jerome Brunet's avatar
      clk: check ops pointer on clock register · 29fd2a34
      Jerome Brunet authored
      Nothing really prevents a provider from (trying to) register a clock
      without providing the clock ops structure.
      We do check the individual fields before using them, but not the
      structure pointer itself. This may have the usual nasty consequences when
      the pointer is dereferenced, most likely when checking one the field
      during the initialization.
      This is fixed by returning an error on clock register if the ops pointer
      is NULL.
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Link: lkml.kernel.org/r/20171219083329.24746-1-jbrunet@baylibre.com