1. 25 2月, 2012 1 次提交
  2. 17 12月, 2011 1 次提交
    • S
      ARM: OMAP4: clock: Add CPU local timer clock node · 30c95692
      Santosh Shilimkar 提交于
      Local timer clock is sourced from the CPU clock and hence changes
      along with CPU clock. These per CPU local timers are used as
      clock-events, so they need to be reconfigured on CPU frequency
      change as part of CPUfreq governor.
      
      Newly introduced clockevents_reconfigure() needs to know the
      twd clock-rate. Provide a clock-node to make clk_get_rate() work
      for TWD.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      [paul@pwsan.com: renamed clock node to 'mpu_periphclk' to indicate that this
       is the Cortex-A9 MPCore subsystem clock PERIPHCLK (DDI 0407G); moved
       clock and clkdev entries to match the autogenerated script output]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      30c95692
  3. 16 12月, 2011 1 次提交
  4. 05 11月, 2011 1 次提交
    • B
      ARM: OMAP2+: clock data: Remove redundant timer clkdev · 2847111c
      Benoit Cousson 提交于
      The commit 318c3e15
      added some "fck" clock alias to timer devices that are
      not needed anymore since hwmod framework will create
      them automatically.
      
      A warning was added to highlight and thus fix the redundancy.
      
      [    0.616424]  omap_timer.1: alias fck already exists
      [    0.621948]  omap_timer.2: alias fck already exists
      [    0.627380]  omap_timer.3: alias fck already exists
      [    0.632781]  omap_timer.4: alias fck already exists
      [    0.638214]  omap_timer.5: alias fck already exists
      [    0.643615]  omap_timer.6: alias fck already exists
      [    0.649078]  omap_timer.7: alias fck already exists
      [    0.654479]  omap_timer.8: alias fck already exists
      [    0.659881]  omap_timer.9: alias fck already exists
      [    0.665283]  omap_timer.10: alias fck already exists
      [    0.670776]  omap_timer.11: alias fck already exists
      
      Remove all the clkdev entries for timer fck alias.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2847111c
  5. 07 10月, 2011 3 次提交
    • J
      ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK · cf2a82d7
      Jon Hunter 提交于
      The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
      parent clock of the AESS_FCLK is the ABE_FCLK...
      
      ABE_FCLK --> AESS_FCLK --> OCP_ABE_ICLK
      
      The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
      determine their operational frequency. However, the dividers for
      the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
      which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
      0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
      Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
      and the OCP_ABE_ICLK is 1.
      
      The above relationship between the AESS_FCLK and OCP_ABE_ICLK
      dividers ensure that the OCP_ABE_ICLK clock is always half the
      frequency of the ABE_CLK...
      
      OCP_ABE_ICLK = ABE_FCLK/2
      
      The divider for the OCP_ABE_ICLK is currently missing so add a
      divider that will ensure the OCP_ABE_ICLK frequency is always half
      the ABE_FCLK frequency.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      cf2a82d7
    • P
      ARM: OMAP4460: Clock: Adding support for 4460 specific clocks · 52a3a4d4
      Paul Walmsley 提交于
      OMAP4460 specific clocks are not getting added as the
      cpu_is_omap44xx is choosing only OMAP4430 specific clock nodes.
      Changing it to add to OMAP4460 specific clocks also.
      This is clocks are required of temperature sensor.
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: NKeerthy <j-keerthy@ti.com>
      Cc: paul@pwsan.com
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      52a3a4d4
    • 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
  6. 22 9月, 2011 1 次提交
  7. 21 8月, 2011 1 次提交
    • P
      OMAP4: clock: fix compile warning · 450a37d2
      Paul Walmsley 提交于
      Fix the following compile warning:
      
      arch/arm/mach-omap2/clock44xx_data.c: In function 'omap4xxx_clk_init':
      arch/arm/mach-omap2/clock44xx_data.c:3371:6: warning: 'cpu_clkflg' may be used uninitialized in this function
      
      The approach taken here is intended to work if omap4xxx_clk_init() is
      converted into an initcall.
      
      Thanks to Bjarne Steinsbo <bsteinsbo@gmail.com> for proposing another
      approach.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Bjarne Steinsbo <bsteinsbo@gmail.com>
      450a37d2
  8. 20 8月, 2011 1 次提交
    • P
      OMAP4: clock: re-enable previous clockdomain enable/disable sequence · 9c5f5601
      Paul Walmsley 提交于
      After commit 665d0013 ("OMAP2+: hwmod:
      Follow the recommended PRCM module enable sequence"), device drivers
      for OMAP IP blocks that do not use runtime PM can cause oopses or
      kernel instability[1][2].
      
      This is because those non-runtime PM drivers do not use the hwmod
      code, which implements the correct IP block enable and disable
      sequence.
      
      Several options for dealing with this problem have been proposed:
      
      1. Add a new field to the OMAP struct clk to mark clocks that are
         currently used by non-runtime PM drivers.  Modify the clock code to
         use the old clockdomain sequence for these marked clocks.  As
         drivers are converted to use runtime PM, remove the annotation from
         the clocks.
      
      2. Similar to #1, but associate the flag with the struct omap_clk
         instead.
      
      3. Add IDLEST wait support to the OMAP4 clock code, similar to the way
         it is implemented for OMAP2/3, and enable it in each struct clk
         currently used by non-runtime PM drivers.  As drivers are converted
         to use runtime PM, remove the annotation from the clocks.
      
      4. Do nothing; leave the problem to those responsible for the
         unconverted drivers.
      
      5. Re-enable clock-based clockdomain control in the OMAP4 clock code.
         This would revert back to the behavior of Linux 3.0, simply with a
         slightly longer module enable/disable latency.
      
      Unfortunately, no approach seemed particularly good.  Options 1
      through 3 seemed unwise due to the following reasons:
      
      A. The OMAP struct clks are intended primarily to describe hardware
         clock nodes, and the intention is that no driver-specific data
         should be stored there (applies to #1)
      
      B. The resulting patch would have been quite large for the -rc series
         (applies to #1, #2, #3)
      
      C. The patch would have been a new, yet temporary hack; and similar fixes
         have drawn negative comments in the recent past (see for example [3])
      
      Option 4 is undesirable because commit
      665d0013 ("OMAP2+: hwmod: Follow the
      recommended PRCM module enable sequence") has resulted in a less
      stable kernel; and kernel stability is more important than OMAP4 power
      management.
      
      Option 5 is the approach taken in this patch.  This seemed to be the
      least intrusive approach for 3.1-rc.
      
      The approach in this patch was originally proposed by Ohad Ben-Cohen
      <ohad@wizery.com>.  I'm simply writing the commit message and passing
      it along.
      
      ...
      
      Thanks to Luciano Coelho <coelho@ti.com> for reporting the problem.
      Thanks to Ohad Ben-Cohen <ohad@wizery.com> for tracking the problem
      down, generating a temporary workaround, and proposing a patch to deal
      with the problem.  Thanks to Rajendra Nayak <rnayak@ti.com> for
      proposing another patch to deal with the problem.  Thanks to Felipe
      Balbi <balbi@ti.com> for comments.
      
      1. Coelho, Luciano <coelho@ti.com>.  _Re: Oops on ehci_hcd when
         booting 3.0.0-rc2 on panda_.  Tue, 09 Aug 2011 14:26:08 +0300.
         Posted to the <linux-omap@vger.kernel.org> mailing list.  Available
         from (among others)
         http://www.spinics.net/linux/lists/linux-omap/msg55213.html
      
      2. Munegowda, Keshava <keshava_mgowda@ti.com>. _Re: Oops on ehci_hcd
         when booting 3.0.0-rc2 on panda_.  Thu, 11 Aug 2011 13:51:05 +0530.
         Posted to the <linux-omap@vger.kernel.org> mailing list.  Available
         from (among others)
         http://www.spinics.net/linux/lists/linux-omap/msg55371.html
      
      3. King, Russell <linux@arm.linux.org.uk>.  _Re: [PATCH 5/8] OMAP4:
         PM: TEMP: Prevent l3init from idling/force sleep_.  Thu, 23 Jun
         2011 16:22:49 +0100.  Posted to the <linux-omap@vger.kernel.org>
         mailing list.  Available from (among others)
         http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51392.htmlSigned-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Luciano Coelho <coelho@ti.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      
      9c5f5601
  9. 10 7月, 2011 11 次提交
  10. 08 7月, 2011 1 次提交
  11. 21 4月, 2011 1 次提交
    • T
      OMAP4: clock data: Change DSS clock aliases · 2df122f5
      Tomi Valkeinen 提交于
      DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
      running, and also to get the pixel clock's source clock rate from the
      fck.
      
      On OMAP4 the clock data is set up in a different way, as there's no ick,
      dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
      dss_dss_clk if the DSS_FCK.
      
      >From DSS driver's point of view the dss_fck sounds like an ick, and
      dss_dss_clk is the fck. While this is not entirely correct from HW point
      of view, especially for the ick, configuring the clock aliases that way
      makes DSS "just work" with OMAP4's clock setup.
      
      In the (hopefully near) future DSS driver will be reworked to use
      pm_runtime support which should clean up the clock code.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      2df122f5
  12. 11 3月, 2011 2 次提交
  13. 02 3月, 2011 1 次提交
  14. 01 3月, 2011 1 次提交
  15. 26 2月, 2011 3 次提交
  16. 19 1月, 2011 1 次提交
    • F
      OMAP: PRCM: remove duplicated headers · bc9fcaf3
      Felipe Balbi 提交于
      A few headers are included twice, remove them.
      
      Found the following errors using make includecheck:
      arch/arm/mach-omap2/clock44xx_data.c: prm44xx.h is
      included more than once.
      arch/arm/mach-omap2/clockdomains44xx_data.c: cm1_44xx.h
      is included more than once.
      arch/arm/mach-omap2/clockdomains44xx_data.c: cm2_44xx.h
      is included more than once.
      arch/arm/mach-omap2/powerdomain2xxx_3xxx.c: prm-regbits-34xx.h
      is included more than once.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      [paul@pwsan.com: dropped lists from patch cc:s; tweaked subject line]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      bc9fcaf3
  17. 23 12月, 2010 1 次提交
    • J
      OMAP4: clock data: Add missing fixed divisors · f17f9726
      Jon Hunter 提交于
      The following OMAP4 clocks have the following fixed divisors that
      determine the frequency at which these clocks operate. These
      dividers are defined by the PRCM specification and without these
      dividers the rates of the below clocks are calculated incorrectly.
      This may cause internal peripherals using these clocks to operate
      at the wrong frequency.
      
      - abe_24m_fclk (freq = divided-by-8)
      - ddrphy_ck (freq = parent divided-by-2)
      - dll_clk_div_ck (freq = parent divided-by-2)
      - per_hs_clk_div_ck (freq = parent divided-by-2)
      - usb_hs_clk_div_ck (freq = parent divided-by-3)
      - func_12m_fclk (freq = parent divided-by-16)
      - func_24m_clk (freq = parent divided-by-4)
      - func_24mc_fclk (freq = parent divided-by-8)
      - func_48mc_fclk (freq = divided-by-4)
      - lp_clk_div_ck (freq = divided-by-16)
      - per_abe_24m_fclk (freq = divided-by-4)
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      f17f9726
  18. 22 12月, 2010 8 次提交