1. 25 2月, 2012 2 次提交
  2. 09 12月, 2011 3 次提交
    • J
      ARM: OMAP1: Always reprogram dpll1 rate at boot · c116abc4
      Janusz Krzysztofik 提交于
      DPLL1 reprogramming to a different rate is actually blocked inside
      omap1_select_table_rate(). However, it is already forced at boot, for
      boards which boot at unusable clock rates, and this seems to work
      correctly.
      
      OTOH, we now have a fine, run time performed clock selection algorithm
      implemented, which prevents less powerfull SoCs from being overclocked
      unintentionally.
      
      Allow reprogramming of dpll1 by default, and use it for switching to the
      higest supported clock rate with all boards, including those already
      booting at a usable rate of 60 MHz or above.
      
      Created against linux-omap/master tip as of Thu Dec 1,
      commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Requires the just
      submitted patch "ARM: OMAP1: Move dpll1 rates selection from config to
      runtime" to prevent from unintentional overclocking. Tested on Amstrad
      Delta.
      Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c116abc4
    • J
      ARM: OMAP1: Update dpll1 default rate reprogramming method · f9e5908f
      Janusz Krzysztofik 提交于
      According to comments in omap1_select_table_rate(), reprogramming dpll1
      is tricky, and should always be done from SRAM.
      
      While being at it, move OMAP730 special case handling inside
      omap_sram_reprogram_clock().
      
      Created on top of version 2 of the series "ARM: OMAP1: Fix dpll1
      reprogramming related issues", which it depends on.
      Tested on Amstrad Delta.
      Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f9e5908f
    • J
      ARM: OMAP1: Move dpll1 rates selection from config to runtime · 24ce2705
      Janusz Krzysztofik 提交于
      For still better multi-OMAP1 support, expand omap1_rate_table with flags
      for different SoC types and match them while selecting clock rates. The
      idea is stolen from current omap24xx clock rate selection algorithm.
      
      Since clkdev platform flag definitions are reused here, those had to be
      expanded with one extra entry for OMAP1710 subtype, as this is the only
      SoC for which we allow selection of the highest, 216 MHz rate.
      
      Once done, remove no longer needed clock rate configure time options.
      
      Tested on Amstrad Delta.
      Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      24ce2705
  3. 26 11月, 2010 1 次提交
  4. 27 7月, 2010 1 次提交
    • P
      OMAP1: clock: some cleanup · fb2fc920
      Paul Walmsley 提交于
      Convert most of the magic numbers in mach-omap1/clock_data.c to use
      macros.  Clean up a few comments to conform with Documentation/CodingStyle.
      Mark the current clkops_uart as being OMAP16xx-only, and add some comments
      to indicate that it does not belong there, for future cleanup.
      
      This patch should not cause any functional changes.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      fb2fc920
  5. 21 5月, 2010 1 次提交
  6. 25 2月, 2010 2 次提交
    • S
      OMAP4: clock: Add dummy clock nodes for interface clocks · 7c43d547
      Santosh Shilimkar 提交于
      On OMAP4 platform the iclk control is completly under hardware control
      and no software control is available.
      
      This difference w.r.t previous OMAP's needs all the common driver
      accross OMAP's , cpu_is_xxxx() checks. To avoid poulluting the
      drivers dummy clock nodes are created (The autogeneration
      script has been updated accordingly).
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      [paul@pwsan.com: made OMAP1 dummy_ck common and edited patch to reuse that]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7c43d547
    • P
      OMAP clock: drop RATE_FIXED clock flag · 51c19541
      Paul Walmsley 提交于
      The RATE_FIXED clock flag is pointless.  In the OMAP1 clock code, it
      simply causes the omap1_clk_round_rate() function to return the
      current rate of the clock.  omap1_clk_round_rate(), however, should
      never be called for a fixed-rate clock, since none of these clocks
      have a .round_rate function pointer set in their struct clk records.
      Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes
      the clock code to emit a warning if the OMAP clock maintainer was
      foolish enough to add a .round_rate function pointer to a fixed-rate
      clock.  "Doctor, it hurts when I pretend that a fixed-rate clock is
      rate-changeable."  "Then don't pretend that a fixed-rate clock is
      rate-changeable."  It has no functional value.  This patch drops the
      RATE_FIXED clock flag, removing it from all clocks that are so marked.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      51c19541
  7. 27 1月, 2010 1 次提交
  8. 21 1月, 2010 1 次提交
    • P
      OMAP1 clock: fix for "BUG: spinlock lockup on CPU#0" · af022faf
      Paul Walmsley 提交于
      Commit 52650505 caused clock initialization
      to fail on OMAP1 with "BUG: spinlock lockup on CPU#0" -- this is because
      omap1_select_table_rate() and omap1_round_to_table_rate() call clk_get_rate()
      with the clockfw spinlock held.  Fix by accessing the rate directly from
      the internal clock framework functions.
      
      Thanks to Tony Lindgren <tony@atomide.com> for reporting and testing the fix.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      af022faf
  9. 12 12月, 2009 3 次提交
  10. 23 11月, 2009 2 次提交
    • C
      omap1: omap_udc: Add clocking and disable vbus sense for omap7xx · 45f780a0
      Cory Maccarrone 提交于
      The l3_ocpi_ck clock is needed on omap7xx processors for USB.
      Additionally, bit 8 of the SOFT_REQ_REG needs to be enabled for
      the usb_dc_ck on omap7xx, which is a different bit than that
      of the omap16xx-defined clock of the same name.
      
      I added a provision for the usb_dc_ck and l3_ocpi_ck clocks as
      dc_clk and hhc_clk, respectively, for omap7xx CPUs.  Additionally,
      I added a check in machine_without_vbus_sense for all omap7xx
      devices, as presently I know of no omap7xx-based devices that
      have vbus sense, and it made more sense to me to use a cpu check
      here than to spell out each machine one at a time.  Finally, DMA
      is disabled for omap7xx, as it causes problems with these chips.
      
      Cc: linux-usb@vger.kernel.org
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      45f780a0
    • C
      omap1: mmc: Add platform init for omap7xx · 490a5665
      Cory Maccarrone 提交于
      The MMC mux pins normally used by omap chips in devices.c
      are different from what is needed by omap7xx chips.  This
      change adds a conditional around the mux setup code to
      enable the correct mux pins.
      
      The omap730 and omap850 both use a different clock for the "fck"
      clock of the MMC interface than other omap processors based on the
      SOFT_REQ_REG, pin 12.  The "ick" clock is the same as that used
      by other omap processors.
      
      * Added the missing clock definition as mmc3_ck to clock.h
      * Added the clock definition to omap_clks in clock.c
      * Added CK_7XX to the mmci-omap.0 "ick" clock already in clock.c
      
      With these changes, it is now possible to initialize and use MMC
      cards with omap730 and omap850 devices.
      Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      490a5665
  11. 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
  12. 08 10月, 2009 4 次提交
  13. 13 5月, 2009 1 次提交
  14. 06 4月, 2009 1 次提交
  15. 14 2月, 2009 1 次提交
    • R
      [ARM] omap: arrange for clock recalc methods to return the rate · 8b9dbc16
      Russell King 提交于
      linux-omap source commit 33d000c99ee393fe2042f93e8422f94976d276ce
      introduces a way to "dry run" clock changes before they're committed.
      However, this involves putting logic to handle this into each and
      every recalc function, and unfortunately due to the caching, led to
      some bugs.
      
      Solve both of issues by making the recalc methods always return the
      clock rate for the clock, which the caller decides what to do with.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8b9dbc16
  16. 09 2月, 2009 15 次提交