1. 25 2月, 2012 1 次提交
  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. 06 12月, 2011 1 次提交
  4. 02 12月, 2011 2 次提交
  5. 12 11月, 2011 1 次提交
    • T
      ARM: OMAP: Fix reprogramming of dpll1 rate · e9b7086b
      Tony Lindgren 提交于
      Commit a66cb345 (ARM: OMAP: Map SRAM
      later on with ioremap_exec()) moved the SRAM init to happen later
      to remove a dependency to early SoC detection for map_io.
      
      This broke booting on some boards not using Kconfig option for
      OMAP_CLOCKS_SET_BY_BOOTLOADER as the dpll1 reprogramming would
      cause the following error:
      
      kernel BUG at arch/arm/plat-omap/sram.c:226!
      Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
      Modules linked in:
      
      CPU: 0    Not tainted  (3.2.0-rc1-e3 #9)
      PC is at omap_sram_reprogram_clock+0x28/0x30
      LR is at omap1_select_table_rate+0x88/0xb4
      pc : [<c001b0c4>]    lr : [<c0019f54>]    psr: 600000d3
      sp : c035bf10  ip : c035bf20  fp : c035bf1c
      r10: c035bfd4  r9 : 54029252  r8 : c03f8120
      r7 : c0362b50  r6 : 00b71b00  r5 : c03873cc  r4 : c0362b40
      r3 : 00000000  r2 : c0362b40  r1 : 0000010a  r0 : 00002cb0
      Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      Control: 0000317f  Table: 10004000  DAC: 00000017
      Process swapper (pid: 0, stack limit = 0xc035a270)
      Stack: (0xc035bf10 to 0xc035c000)
      bf00:                                     c035bf3c c035bf20 c0019f54 c001b0ac
      bf20: 00001000 00002cb3 00000004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc
      bf40: c02f526c 00000002 00000015 bc058c9b 93111a16 c035335c 02000000 c035ed4c
      bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88
      bf80: c033bc24 c00194a0 c035bf90 c035bf98 00000000 00000000 00000000 00000000
      bfa0: 00000001 00000000 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8
      bfc0: c0338574 c033b598 00000000 00000000 00000000 c035467c 0000317d c035c03c
      bfe0: c0354678 c035ece4 00000000 c035bff8 10008040 c0338508 00000000 00000000
      Backtrace:
      [<c001b09c>] (omap_sram_reprogram_clock+0x0/0x30) from [<c0019f54>] (omap1_select_table_rate+0x88/0xb4)
      [<c0019ecc>] (omap1_select_table_rate+0x0/0xb4) from [<c033ea24>] (omap1_clk_init+0x148/0x334)
       r7:c035ed4c r6:00000004 r5:00002cb3 r4:00001000
      [<c033e8dc>] (omap1_clk_init+0x0/0x334) from [<c00194c4>] (omap1_init_early+0x34/0x48)
       r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:02000000 r4:c035335c
      [<c0019490>] (omap1_init_early+0x0/0x48) from [<c033bc24>] (setup_arch+0x69c/0x79c)
      [<c033b588>] (setup_arch+0x0/0x79c) from [<c0338574>] (start_kernel+0x7c/0x2f4)
      [<c03384f8>] (start_kernel+0x0/0x2f4) from [<10008040>] (0x10008040)
       r7:c035ece4 r6:c0354678 r5:c035c03c r4:0000317d
      Code: 0a000002 e1a0e00f e12fff13 e89da800 (e7f001f2)
      
      Fix this by adding omap1_clk_late_init() that only reprograms dpll1
      if the bootloader rate is less than 60MHz. This also allows removing
      of the OMAP_CLOCKS_SET_BY_BOOTLOADER option.
      Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e9b7086b
  6. 22 12月, 2010 1 次提交
  7. 21 12月, 2010 1 次提交
  8. 08 12月, 2010 1 次提交
    • V
      OMAP: GPIO: Implement GPIO as a platform device · 77640aab
      Varadarajan, Charulatha 提交于
      Implement GPIO as a platform device.
      
      GPIO APIs are used in machine_init functions. Hence it is
      required to complete GPIO probe before board_init. Therefore
      GPIO device register and driver register are implemented as
      postcore_initcalls.
      
      omap_gpio_init() does nothing now and this function would be
      removed in the next patch as it's usage is spread across most
      of the board files.
      
      Inorder to convert GPIO as platform device, modifications are
      required in clockxxxx_data.c file for OMAP1 so that device names
      can be used to obtain clock instead of getting clocks by
      name/NULL ptr.
      
      Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling
      or disabling the clocks, modify sysconfig settings and remove usage
      of clock FW APIs.
      Note 1: Converting GPIO driver to use runtime PM APIs is not done as a
      separate patch because GPIO clock names are different for various OMAPs
      and are different for some of the banks in the same CPU. This would need
      usage of cpu_is checks and bank id checks while using clock FW APIs in
      the gpio driver. Hence while making GPIO a platform driver framework,
      PM runtime APIs are used directly.
      
      Note 2: While implementing GPIO as a platform device, pm runtime APIs
      are used as mentioned above and modification is not done in gpio's
      prepare for idle/ resume after idle functions. This would be done
      in the next patch series and GPIO driver would be made to use dev_pm_ops
      instead of sysdev_class in that series only.
      
      Due to the above, the GPIO driver implicitly relies on
      CM_AUTOIDLE = 1 on its iclk for power management to work, since the
      driver never disables its iclk.
      This would be taken care in the next patch series (see Note 3 below).
      
      Refer to
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html
      for more details.
      
      Note 3: only pm_runtime_get_sync is called in gpio's probe() and
      pm_runtime_put* is never called. This is to make the implementation
      similar to the existing GPIO code. Another patch series would be sent
      to correct this.
      
      In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They
      are enabled/ disabled whenever required using clock framework APIs
      
      TODO:
      1. Cleanup the GPIO driver. Use function pointers and register
      offest pointers instead of using hardcoded values
      2. Remove all cpu_is_ checks and OMAP specific macros
      3. Remove usage of gpio_bank array so that only
         instance specific information is used in driver code
      4. Rename 'method'/ avoid it's usage
      5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4
      6. Modify gpio's prepare for idle/ resume after idle functions
         to use runtime pm implentation.
      Signed-off-by: NCharulatha V <charu@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Reviewed-by: NBasak, Partha <p-basak2@ti.com>
      Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
      [tony@atomide.com: updated for bank specific revision and updated boards]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      77640aab
  9. 02 8月, 2010 1 次提交
  10. 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
  11. 25 2月, 2010 3 次提交
    • 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
    • P
      OMAP clock: drop .id field; ensure each clock has a unique name · b92c170d
      Paul Walmsley 提交于
      After the clkdev conversion, the struct clk.id field became
      superfluous, so, drop it.  Bring the clock names closer to the TRMs
      and ensure they are unique for debugfs.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b92c170d
  12. 27 1月, 2010 1 次提交
  13. 09 1月, 2010 3 次提交
  14. 12 12月, 2009 3 次提交
  15. 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
  16. 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
  17. 09 2月, 2009 4 次提交
  18. 08 2月, 2009 1 次提交
  19. 02 2月, 2009 2 次提交
  20. 11 12月, 2008 1 次提交
    • T
      omap mmc: Add better MMC low-level init · d8874665
      Tony Lindgren 提交于
      This will simplify the MMC low-level init, and make it more
      flexible to add support for a newer MMC controller in the
      following patches.
      
      The patch rearranges platform data and gets rid of slot vs
      controller confusion in the old data structures. Also fix
      device id numbering in the clock code.
      
      Some code snippets are based on an earlier patch by
      Russell King <linux@arm.linux.org.uk>.
      
      Cc: Pierre Ossman <drzeus-mmc@drzeus.cx>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      
      
      
      
      
      d8874665
  21. 06 9月, 2008 1 次提交
  22. 21 9月, 2007 2 次提交
  23. 25 9月, 2006 1 次提交
  24. 03 4月, 2006 1 次提交
  25. 18 1月, 2006 1 次提交