1. 14 11月, 2014 1 次提交
  2. 16 7月, 2014 5 次提交
  3. 11 7月, 2014 1 次提交
  4. 02 7月, 2014 1 次提交
  5. 28 5月, 2014 3 次提交
  6. 18 1月, 2014 6 次提交
  7. 20 10月, 2013 1 次提交
  8. 18 3月, 2013 1 次提交
  9. 01 2月, 2013 1 次提交
  10. 15 12月, 2012 1 次提交
    • J
      ARM: OMAP4: Enhance support for DPLLs with 4X multiplier · 3ff51ed8
      Jon Hunter 提交于
      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: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3ff51ed8
  11. 13 11月, 2012 9 次提交
  12. 09 11月, 2012 1 次提交
  13. 19 10月, 2012 2 次提交
  14. 30 6月, 2012 1 次提交
    • V
      ARM: OMAP3+: clock33xx: Add AM33XX clock tree data · e30384ab
      Vaibhav Hiremath 提交于
      AM33XX clock implementation is different than any existing OMAP
      family of devices. Although DPLL module is similar to OMAP4
      device, but the usage is very much different than OMAP4.
      AM33XX has different peripheral set and each module gets
      integrated to the clock framework differently than OMAP
      family of devices.
      
      This patch adds full Clock tree data for AM33XX family
      of devices and also integrates it into existing OMAP framework.
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      CC: Tony Lindgren <tony@atomide.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      [paul@pwsan.com: updated to apply; changed 'soc_is_am33xx' to
       'cpu_is_am33xx' to match usage in Tony's current am33xx branch]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e30384ab
  15. 27 6月, 2012 1 次提交
  16. 15 4月, 2012 1 次提交
  17. 14 12月, 2011 1 次提交
    • A
      ARM: OMAP: am33xx: Update common omap platform files · 99541195
      Afzal Mohammed 提交于
      This patch updates the common platform files with AM335X device
      support (AM33XX family).
      
      The approach taken in this patch is,
      AM33XX device will be considered as OMAP3 variant, and a separate
      SoC class created for AM33XX family of devices with a subclass type
      for AM335X device, which is newly added device in the family.
      
      This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x()
      checks will return success on AM335X device.
      A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3
      to include support for AM33XX build.
      
      Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence
      struct clksel_rate.flags, struct prcm_config.flags and cpu_mask
      are changed to u16 from u8.
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Hemant Pedanekar <hemantp@ti.com>
      [tony@atomide.com: left out CK_AM33XX for now]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      99541195
  18. 07 10月, 2011 1 次提交
    • M
      ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE · a1900f2e
      Mike Turquette 提交于
      OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
      and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
      bit in CKGEN module of CM1. From the OMAP4 TRM:
      
      Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
      applicable to DPLL_ABE).
      
      Add new round_rate() and recalc() functions for OMAP4, that check the
      setting of REGM4XEN bit and handle this appropriately. The new functions
      are a simple wrapper on top of the existing omap2_dpll_round_rate() and
      omap2_dpll_get_rate() functions to handle the REGM4XEN bit.
      
      The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
      only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
      omap4_dpll_regm4xen_recalc() functions.
      Signed-off-by: NMike Turquette <mturquette@ti.com>
      Tested-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: fixed attempt to return a negative from a fn returning
      		 unsigned; pass along errors from omap2_dpll_round_rate();
      		 added documentation; added Jon's S-o-b]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a1900f2e
  19. 10 7月, 2011 1 次提交
    • P
      OMAP2+: clock: allow per-SoC clock init code to prevent clockdomain calls from clock code · 12706c54
      Paul Walmsley 提交于
      The OMAP2/3 clock code was written to notify the clockdomain code when
      the first clock in a clockdomain is enabled and when the last enabled
      clock in a clockdomain is disabled.  OMAP4 requires a different
      approach: the hwmod code needs to signal the clockdomain code when to
      force-enable and auto-idle a clockdomain during the IP block enable
      process.  The current conjecture is that once that hwmod sequence is
      implemented, it will no longer be necessary for the clock code to call
      into the clockdomain code for "optional clocks" on OMAP4.
      
      Add a static flag to the OMAP2+ clock code, clkdm_control, that by
      default preserves the OMAP2/3 behavior.  Also add a function,
      omap2_clk_disable_clkdm_control(), intended to be called from OMAP4
      and beyond clock initcalls, that disables the old behavior.
      
      Part of this patch was originally based on a patch by Rajendra Nayak
      <rnayak@ti.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      
      
      12706c54
  20. 08 3月, 2011 1 次提交
    • P
      OMAP2xxx: clock: remove dsp_irate_ick · 22411396
      Paul Walmsley 提交于
      After commit 81b34fbe ("OMAP2 clock:
      split OMAP2420, OMAP2430 clock data into their own files"), it's
      possible to remove dsp_irate_ick from the OMAP2420 and OMAP2430 clock
      files.  It was originally only needed due to a 2420/2430 clock tree difference,
      and now that the data is in separate files, it's superfluous.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      22411396