1. 16 9月, 2011 17 次提交
  2. 15 9月, 2011 8 次提交
  3. 14 9月, 2011 1 次提交
    • P
      OMAP3: id: remove identification codes that only correspond to marketing names · 1f1b0353
      Paul Walmsley 提交于
      The OMAP3505/AM3505 appears to be based on the same silicon as the
      OMAP3517/AM3517, with some features disabled via eFuse bits.  Follow
      the same practice as OMAP3430 and identify these devices internally as
      part of the OMAP3517/AM3517 family.
      
      The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
      as the OMAP3430, with some features disabled via eFuse bits.  Identify
      these devices internally as part of the OMAP3430 family.
      
      Remove the old OMAP35XX_CLASS, which actually covered two very different
      chip families.  The OMAP3503/3515/3525/3530 chips will now be covered by
      OMAP343X_CLASS, since the silicon appears to be identical.  For the
      OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.
      
      Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
      revision of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Sanjeev Premi <premi@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
      Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
      1f1b0353
  4. 05 9月, 2011 1 次提交
    • P
      OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[] · 10167873
      Paul Walmsley 提交于
      Add a missing array terminator to omap2430_usbhsotg_addrs[].  Without
      this terminator, the omap_hwmod resource building code runs off the
      end of the array, resulting in at least this error -- if not worse
      behavior:
      
      [    0.578002] musb-omap2430: failed to claim resource 4
      [    0.583465] omap_device: musb-omap2430: build failed (-16)
      [    0.589294] Could not build omap_device for musb-omap2430 usb_otg_hs
      
      This should have been part of commit
      78183f3f ("omap_hwmod: use a null
      structure record to terminate omap_hwmod_addr_space arrays") but was
      evidently missed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      10167873
  5. 23 8月, 2011 1 次提交
    • P
      OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomain · e21757a0
      Paul Walmsley 提交于
      The oscillator that supplies GPT12_FCLK and WDT1_FCLK exists in the
      WKUP powerdomain[1].  This resolves at least one boot-time warning:
      
      omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
      
      1. _OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.1.x
         Security Addendum Version K (SWPU119K)_  Figure 3-29.  August 2010.
      e21757a0
  6. 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
  7. 20 8月, 2011 3 次提交
    • 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
    • S
      OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup · b1cbdb00
      Santosh Shilimkar 提交于
      While using clockdomain force wakeup method, not waiting for powerdomain
      to be effectively ON may end up locking the clockdomain FSM until a
      next wakeup event occurs.
      
      One such issue was seen on OMAP4430, where L4_PER was periodically
      getting stuck in in-transition state when transitioning from from OSWR to ON.
      
      This issue was reported and investigated by Patrick Titiano <p-titiano@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Reported-by: NPatrick Titiano <p-titiano@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      [paul@pwsan.com: updated to apply; added transition wait on clkdm_deny_idle();
       remove two superfluous pwrdm_wait_transition() calls]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b1cbdb00
    • R
      OMAP: powerdomains: Make all powerdomain target states as ON at init · c956b753
      Rajendra Nayak 提交于
      Program all powerdomain target state as ON; this is to prevent domains
      from hitting low power states (if bootloader has target states set to
      something other than ON) and potentially even losing context while PM
      is not fully initialized, which can cause the system to crash.  The PM
      late init code can then program the desired target state for all the
      power domains.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      [paul@pwsan.com: dropped comment typo hunk; fixed comment indent and moved
       to kerneldoc; moved code to pwrdm_init(); changed pwrdm_init() argument name
       to prevent clash; cleaned up patch description]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c956b753
  8. 10 8月, 2011 5 次提交
    • H
      omap: timer: Set dmtimer used as clocksource in autoreload mode · e9d0b97e
      Hemant Pedanekar 提交于
      If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the
      timer stops counting once overflow occurs as it was not set in autoreload mode.
      This results into timekeeping failure: for example, 'sleep 1' at the shell after
      the timer counter overflow would hang.
      
      This patch sets up autoreload when starting the clocksource timer which fixes
      the above issue.
      Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e9d0b97e
    • J
      OMAP3: am3517crane: remove NULL board_mux from board file · 133e6b55
      Johan Hovold 提交于
      Since 7203f8a4 (arm: mach-omap2: remove
      NULL board_mux from board files) NULL board_mux is defined in mux.h.
      Signed-off-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      133e6b55
    • T
      arm: mach-omap2: mux: use kstrdup() · dccb3b0e
      Thomas Meyer 提交于
      Use kstrdup rather than duplicating its implementation
      
      The semantic patch that makes this output is available
      in scripts/coccinelle/api/kstrdup.cocci.
      
      More information about semantic patching is available at
      http://coccinelle.lip6.fr/Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dccb3b0e
    • P
      OMAP: hwmod: fix build break on non-OMAP4 multi-OMAP2 builds · c9a48c2a
      Paul Walmsley 提交于
      Builds for multi-OMAP2 (e.g., OMAP2420 with OMAP2430) with
      CONFIG_ARCH_OMAP4=n fail with the following errors:
      
      arch/arm/mach-omap2/built-in.o: In function `_enable_module':
      arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to `omap4_cminst_module_enable'
      arch/arm/mach-omap2/built-in.o: In function `_disable_module':
      arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to `omap4_cminst_module_disable'
      arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable':
      arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to `omap4_cminst_wait_module_idle'
      
      This is probably due to the preprocessor directives in
      arch/arm/plat-omap/include/plat/cpu.h that convert some cpu_is_omap*()
      expressions from preprocessor directives into something that is only
      resolvable during runtime, if multiple OMAP2 build targets are
      selected.
      
      Thanks to Tony Lindgren <tony@atomide.com> for reporting.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c9a48c2a
    • P
      OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds · d12d1fca
      Peter Ujfalusi 提交于
      Commit b22f954b (OMAP4: Move common twl6030 configuration to twl-common)
      caused compile failures for code for OMAP arch which is not selected by
      the config.
      
      Fixes issues like:
      With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
      
      arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
      arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
      
      Fix the problem by moving the code to ifdef sections for omap3 and omap4.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d12d1fca
  9. 06 8月, 2011 3 次提交
    • C
      OMAP2+: PM: SmartReflex: use put_sync_suspend for IRQ-safe disabling · 98333b3d
      Colin Cross 提交于
      omap_sr_disable_reset_volt is called with irqs off in omapx_enter_sleep,
      as part of idle sequence, this eventually calls sr_disable and
      pm_runtime_put_sync. pm_runtime_put_sync calls rpm_idle, which will
      enable interrupts in order to call the callback. In this short interval
      when interrupts are enabled, scenarios such as the following can occur:
      while interrupts are enabled, the timer interrupt that is supposed to
      wake the device out of idle occurs and is acked, so when the CPU finally
      goes to off, the timer is already gone, missing a wakeup event.
      
      Further, as the documentation for runtime states:"
       However, subsystems can use the pm_runtime_irq_safe() helper function
       to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
       callbacks should be invoked in atomic context with interrupts disabled
       (->runtime_idle() is still invoked the default way)."
      
      Hence, replace pm_runtime_put_sync with pm_runtime_put_sync_suspend
      to invoke the suspend handler and shut off the fclk for SmartReflex
      module instead of using the idle handler in interrupt disabled context.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NColin Cross <ccross@google.com>
      [khilman@ti.com: minor Subject edits]
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      98333b3d
    • K
      OMAP3: beagle: don't touch omap_device internals · 8c7f6594
      Kevin Hilman 提交于
      Board code should not touch omap_device internals.  To get the MPU/IVA devices,
      use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      8c7f6594
    • N
      OMAP3+: SR: ensure pm-runtime callbacks can be invoked with IRQs disabled · e13d8f38
      Nishanth Menon 提交于
      SmartReflex should be disabled while entering low power mode due to
      a) SmartReflex values are not defined for retention voltage, further
      b) with SmartReflex enabled, if CPU enters lower c-states, FSM will try
      to bump the voltage to current OPP's voltage for which it has entered c-state;
      hence SmartReflex needs to be disabled for MPU, CORE and IVA voltage
      domains in idle path before enabling auto retention voltage achievement
      on the device.
      
      However, since the current pm_runtime setup for SmartReflex devices are
      setup to allow callbacks to be invoked with interrupts enabled, calling
      SmartReflex enable/disable from other contexts such as idle paths
      where preemption is disabled causes warnings such as the following
      indicating of a potential race.
      [   82.023895] [<c04d079c>] (__irq_svc+0x3c/0x120) from [<c04d0484>] (_raw_spin_unlock_irq+0x28/0x2c)
      [   82.023895] [<c04d0484>] (_raw_spin_unlock_irq+0x28/0x2c) from [<c0323234>] (rpm_callback+0x4c/0x68)
      [   82.023956] [<c0323234>] (rpm_callback+0x4c/0x68) from [<c0323f7c>] (rpm_resume+0x338/0x53c)
      [   82.023956] [<c0323f7c>] (rpm_resume+0x338/0x53c) from [<c03243f4>] (__pm_runtime_resume+0x48/0x60)
      [   82.023986] [<c03243f4>] (__pm_runtime_resume+0x48/0x60) from [<c008aee0>] (sr_enable+0xa8/0x19c)
      [   82.023986] [<c008aee0>] (sr_enable+0xa8/0x19c) from [<c008b2fc>] (omap_sr_enable+0x50/0x90)
      [   82.024017] [<c008b2fc>] (omap_sr_enable+0x50/0x90) from [<c00888c0>] (omap4_enter_sleep+0x138/0x168)
      
      Instead, we use pm_runtime_irq_safe to tell the PM core that callbacks can be
      invoked in interrupt disabled contexts.
      Acked-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      [khilman@ti.com: minor changelog edits]
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      e13d8f38