1. 02 Jun, 2015 3 commits
  2. 31 Mar, 2015 1 commit
  3. 27 Mar, 2015 1 commit
  4. 02 Feb, 2015 2 commits
    • Michael Turquette's avatar
      arm: omap2+ remove dead clock code · 42ed83f5
      Michael Turquette authored
      Remove omap_clocks_register and dummy_ck. The former is not used anymore
      now that the statically defined clk stuctures are replaced with proper
      descriptors and registered with the framework.
      The dummy clock in arch/arm/mach-omap2 is made redundant by the OMAP3+
      clock data that migrated to drivers/clk.
      An additional benefit to this clean-up is removing the references to
      clk-private.h which will be removed.
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
    • Tomeu Vizoso's avatar
      clk: Make clk API return per-user struct clk instances · 035a61c3
      Tomeu Vizoso authored
      Moves clock state to struct clk_core, but takes care to change as little API as
      struct clk_hw still has a pointer to a struct clk, which is the
      implementation's per-user clk instance, for backwards compatibility.
      The struct clk that clk_get_parent() returns isn't owned by the caller, but by
      the clock implementation, so the former shouldn't call clk_put() on it.
      Because some boards in mach-omap2 still register clocks statically, their clock
      registration had to be updated to take into account that the clock information
      is stored in struct clk_core now.
      Signed-off-by: default avatarTomeu Vizoso <tomeu.vizoso@collabora.com>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Tested-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
      [mturquette@linaro.org: adapted clk_has_parent to struct clk_core
                              applied OMAP3+ DPLL fix from Tero & Tony]
  5. 07 Jan, 2015 1 commit
  6. 13 Nov, 2014 1 commit
  7. 12 Nov, 2014 1 commit
  8. 15 Jul, 2014 5 commits
  9. 11 Jul, 2014 1 commit
  10. 02 Jul, 2014 1 commit
  11. 28 May, 2014 3 commits
  12. 17 Jan, 2014 6 commits
  13. 19 Oct, 2013 1 commit
  14. 18 Mar, 2013 1 commit
  15. 31 Jan, 2013 1 commit
  16. 15 Dec, 2012 1 commit
    • Jon Hunter's avatar
      ARM: OMAP4: Enhance support for DPLLs with 4X multiplier · 3ff51ed8
      Jon Hunter authored
      On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
      be enabled or disabled in addition to the standard configurable
      multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
      multiplier is accounted for by checking to see whether it is enabled or
      not. However, when calculating a new rate we only check to see if the
      rate can be achieved with the current setting for the 4X multiplier.
      Enhance the round_rate() function for such DPLLs to see if the rate
      can be achieved with the 4X multiplier if it cannot be achieved without
      the 4X multiplier.
      This change is necessary, because when using the 32kHz clock as the
      source clock for the ABE DPLL, the default DPLL frequency for the ABE
      DPLL cannot be achieved without enabling the 4X multiplier.
      When using the 32kHz clock as the source clock for the ABE DPLL and
      attempting to lock the DPLL to 98.304MHz (default frequency), it was
      found that the DPLL would fail to lock if the low-power mode for the DPLL
      was not enabled. From reviewing boot-loader settings that configure the
      ABE DPLL it was found that the low-power mode is enabled when using the
      32kHz clock source, however, the documentation for OMAP does not state
      that this is a requirement. Therefore, introduce a new function for
      OMAP4 devices to see if low-power mode can be enabled when calculating a
      new rate to ensure the DPLL will lock.
      New variables for the last calculated 4X multiplier and low-power
      setting have been added to the dpll data structure as well as variables
      defining the bit mask for enabling these features via the DPLL's
      control_reg. It is possible that we could eliminate these bit masks from
      the dpll data structure as these bit masks are not unique to OMAP4, if
      it is preferred.
      The function omap3_noncore_program_dpll() has been updated to avoid
      passing the calculated values for the multiplier (M) and divider (N) as
      these are stored in the clk structure.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
  17. 12 Nov, 2012 9 commits
  18. 08 Nov, 2012 1 commit