1. 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
  2. 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
  3. 10 7月, 2011 11 次提交
  4. 08 7月, 2011 1 次提交
  5. 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
  6. 11 3月, 2011 2 次提交
  7. 02 3月, 2011 1 次提交
  8. 01 3月, 2011 1 次提交
  9. 26 2月, 2011 3 次提交
  10. 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
  11. 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
  12. 22 12月, 2010 11 次提交
  13. 21 12月, 2010 1 次提交
  14. 10 12月, 2010 2 次提交
  15. 01 12月, 2010 1 次提交
  16. 09 10月, 2010 1 次提交
    • P
      OMAP: control: move plat-omap/control.h to mach-omap2/control.h · 4814ced5
      Paul Walmsley 提交于
      Only OMAP2+ platforms have the System Control Module (SCM) IP block.
      In the past, we've kept the SCM header file in plat-omap.  This has
      led to abuse - device drivers including it; includes being added that
      create implicit dependencies on OMAP2+ builds; etc.
      
      In response, move the SCM headers into mach-omap2/.
      
      As part of this, remove the direct SCM access from the OMAP UDC
      driver.  It was clearly broken.  The UDC code needs an indepth review for
      use on OMAP2+ chips.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      4814ced5