1. 13 9月, 2012 1 次提交
  2. 05 7月, 2012 1 次提交
  3. 04 7月, 2012 1 次提交
  4. 08 5月, 2012 1 次提交
  5. 07 10月, 2011 3 次提交
    • J
      ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate · 49642ac8
      Jon Hunter 提交于
      This is a continuation of Mike Turquette's patch "OMAP3+: use
      DPLL's round_rate when setting rate".
      
      omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
      omap2_get_dpll_rate() explicitly. It may be necessary for some
      DPLLs to use a different function and so use the DPLLs recalc()
      function pointer instead.
      
      An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
      in addition to the usual MN multipler and dividers and therefore
      uses a different round_rate and recalc function.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Cc: Mike Turquette <mturquette@ti.com>
      Cc: Misael Lopez Cruz <misael.lopez@ti.com>
      [paul@pwsan.com: merged this patch with Mike's "use clock's recalc in DPLL
       handling" patch; also reported by Misael]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      49642ac8
    • M
      ARM: OMAP3+: dpll: assign clk rate from rounded rate during rate set · 273a1ce9
      Mike Turquette 提交于
      The rounded rate can differ from target rate, so to better reflect
      reality set clk->rate equal to the rounded rate when setting DPLL frequency.
      This avoids issues where the DPLL frequency is slightly different than what
      debugfs clock tree reports using the old target rate.
      
      An example of a clock that requires this is DPLL_ABE on OMAP4 which
      can have a 4x multiplier on top of the usual MN dividers depending on
      register settings.  This requires a special round_rate function that
      might yield a rate different from the initial target.
      Signed-off-by: NMike Turquette <mturquette@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      273a1ce9
    • M
      ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate · addf888c
      Mike Turquette 提交于
      omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
      use the struct clk pointer's round_rate function to allow for DPLL's with
      special needs.
      
      An example of a clock that requires this is DPLL_ABE on OMAP4 which
      can have a 4x multiplier on top of the usual MN dividers depending on
      register settings.  This requires a special round_rate function that
      might yield a rate different from the initial target.
      Signed-off-by: NMike Turquette <mturquette@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: split rate assignment portion into a separate patch]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      addf888c
  6. 22 12月, 2010 2 次提交
    • J
      OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4 · a36795c1
      Jon Hunter 提交于
      J-Type DPLLs have additional configuration parameters that need to
      be programmed when setting the multipler and divider for the DPLL.
      These parameters being the sigma delta divider (SD_DIV) for the DPLL
      and the digital controlled oscillator (DCO) to be used by the DPLL.
      
      The current code is implemented specifically to configure the
      OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL
      and so this code needs to be updated to work for both OMAP3 and OMAP4
      devices and any other future devices that have J-TYPE DPLLs.
      
      For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are
      used but for the OMAP4430 USB DPLL only the SD_DIV field is used.
      The current implementation will only program the SD_DIV and DCO
      fields if the DPLL has both and hence this does not work for
      OMAP4430.
      
      In order to make the code more generic add two new fields to the
      dpll_data structure for the SD_DIV field and DCO field bit-masks
      and only program these fields if the masks are defined for a specific
      DPLL. This simplifies the code and allows us to remove the flag
      DPLL_NO_DCO_SEL.
      
      Tested on OMAP36xx Zoom3 and OMAP4 Blaze.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*()
       functions; added testing info to commit message; added 35xx comments back in]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a36795c1
    • P
      OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files · 59fb659b
      Paul Walmsley 提交于
      In preparation for adding OMAP4-specific PRCM accessor/mutator
      functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
      files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
      moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
      OMAP2xxx/3xxx-specific.
      
      This process also requires the #includes in each of these files to be
      changed to reference the new file name.  As part of doing so, add some
      comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
      "sideways includes", to indicate that these users of the PRM/CM includes
      should not be doing so.
      
      Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
      patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Cc: Liam Girdwood <lrg@slimlogic.co.uk>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      59fb659b
  7. 26 11月, 2010 1 次提交
  8. 17 6月, 2010 1 次提交
  9. 25 2月, 2010 3 次提交
    • P
      OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation · 93340a22
      Paul Walmsley 提交于
      The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
      one increment higher than they should be.  See for example the
      OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
      OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL".  Programming a 0 into
      the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
      the DPLL should enter MN-bypass mode.  Also, increase the minimum
      multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
      ensure that it does not inadvertently put the DPLL into bypass.
      
      Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
      does not make clear that the actual DPLL divider value (the "N") is
      the content of the appropriate register bitfield for the N value,
      _plus one_.  (In other words, an N register bitfield of 0 indicates a
      DPLL divider value of 1.)  This is only clearly documented in the
      OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
      "CM_CLKSEL_DPLL_USB".
      
      While here, update copyrights, add kerneldoc for struct dpll_data,
      drop the unused struct dpll_data.max_tolerance field, remove some
      unnecessary #includes in DPLL-related code, and replace the #include
      of <linux/module.h> with <linux/list.h>, which is what was really
      needed.  The OMAP4 clock autogenerator script has been updated
      accordingly.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      93340a22
    • R
      OMAP3 clock: introduce DPLL4 Jtype · 358965d7
      Richard Woodruff 提交于
      DPLL4 for 3630 introduces a changed block called j type dpll, requiring
      special divisor bits and additional reg fields. To allow for silicons to
      use this, this is introduced as a flag and is enabled for 3630 silicon.
      OMAP4 also has j type dpll for usb.
      
      Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
      Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
      [paul@pwsan.com: added some comments; updated copyrights and credits; fixed
       some style issues]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      358965d7
    • V
      OMAP3 clock: Remove FreqSel for 3630 · 5eb75f55
      Vishwanath BS 提交于
      DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
      OMAP3630. So remove references to that.
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      [paul@pwsan.com: added comment fix from Sergei Shtylyov]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5eb75f55
  10. 30 1月, 2010 1 次提交
  11. 27 1月, 2010 1 次提交
  12. 12 12月, 2009 5 次提交
  13. 09 12月, 2009 1 次提交
  14. 02 12月, 2009 1 次提交
  15. 18 11月, 2009 1 次提交
  16. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  17. 06 10月, 2009 1 次提交
  18. 04 9月, 2009 1 次提交
  19. 25 7月, 2009 2 次提交
    • P
      OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB · 3c82e229
      Paul Walmsley 提交于
      Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
      USBHOST, and HSOTGUSB devices.  These devices are both interconnect
      initiators and targets.  Without this patch, clk_enable()s on clocks for
      these modules can be very high latency (potentially up to ~200
      milliseconds) and message such as the following are generated:
      
          Clock usbhost_48m_fck didn't enable in 100000 tries
      
      Two bugs are fixed by this patch.  First, OMAP hardware only supports
      target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
      should not wait for these clocks to enable.  So, split the appropriate
      clocks into ES1 and ES2+ variants, so that kernels running on ES1
      devices won't try to wait.
      
      Second, the current heuristic in omap2_clk_dflt_find_idlest() will
      fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
      is the same as the CM_*CLKEN bit, which is false[1].  Fix by
      implementing custom clkops .find_idlest function pointers for the
      appropriate clocks that return the correct slave IDLEST bit shift.
      
      This was originally fixed in the linux-omap kernel during 2.6.29 in a
      slightly different manner[2][3].
      
      In the medium-term future, all of the module IDLEST code will
      eventually be moved to the omap_hwmod code.
      
      Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
      
          http://marc.info/?l=linux-omap&m=124306184903679&w=2
      
      ...
      
      1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
         DSS case).
      
      2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
      
      3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.htmlSigned-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      3c82e229
    • J
      OMAP3 SDRC: add support for 2 SDRAM chip selects · 58cda884
      Jean Pihet 提交于
      Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
      SDRAM parts connected to the SDRC.
      
      This patch adds the following:
      - add a new argument of type omap_sdrc_params struct*
      to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
      - adapted the OMAP boards files to the new prototype of
      omap2_init_common_hw
      - add the SDRC 2nd CS registers offsets defines
      - adapt the sram sleep code to configure the SDRC for the 2nd CS
      
      Note: If the 2nd param to omap2_init_common_hw is NULL, then the
      parameters are not programmed into the SDRC CS1 registers
      
      Tested on 3430 SDP and Beagleboard rev C2 and B5, with
      suspend/resume and frequency changes (cpufreq).
      Signed-off-by: NJean Pihet <jpihet@mvista.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      58cda884
  20. 20 6月, 2009 4 次提交
  21. 29 5月, 2009 1 次提交
  22. 16 5月, 2009 1 次提交
  23. 13 5月, 2009 4 次提交
  24. 20 2月, 2009 1 次提交
    • R
      [ARM] omap: add support for bypassing DPLLs · c0bf3132
      Russell King 提交于
      This roughly corresponds with OMAP commits: 7d06c48, 3241b19,
      88b5d9b, 18a5500, 9c909ac, 5c6497b, 8b1f0bd, 2ac1da8.
      
      For both OMAP2 and OMAP3, we note the reference and bypass clocks in
      the DPLL data structure.  Whenever we modify the DPLL rate, we first
      ensure that both the reference and bypass clocks are enabled.  Then,
      we decide whether to use the reference and DPLL, or the bypass clock
      if the desired rate is identical to the bypass rate, and program the
      DPLL appropriately.  Finally, we update the clock's parent, and then
      disable the unused clocks.
      
      This keeps the parents correctly balanced, and more importantly ensures
      that the bypass clock is running whenever we reprogram the DPLL.  This
      is especially important because the procedure for reprogramming the DPLL
      involves switching to the bypass clock.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c0bf3132