1. 10 12月, 2013 2 次提交
    • N
      ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present · 0e7dc862
      Nishanth Menon 提交于
      commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced
      missing braces, however, we just set return result if clk_get fail
      and we populate the error pointer in clk pointer and pass it along to
      clk_prepare. This is wrong. The intent seems to be retry remaining
      clocks if they are available and warn the ones we cant find clks for.
      
      With the current logic, we see the following crash:
      omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick
      Unable to handle kernel NULL pointer dereference at virtual address 00000032
      pgd = c0004000
      [00000032] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19
      task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000
      PC is at __clk_prepare+0x10/0x74
      LR is at clk_prepare+0x14/0x24
        <snip>
      [<c044d59c>] (__clk_prepare+0x10/0x74) from [<c044d9b0>] (clk_prepare+0x14/0x24)
      [<c044d9b0>] (clk_prepare+0x14/0x24) from [<c077d8c4>] (_init+0x24c/0x3bc)
      [<c077d8c4>] (_init+0x24c/0x3bc) from [<c0027328>] (omap_hwmod_for_each+0x34/0x5c)
      [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) from [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40)
      [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) from [<c0008928>] (do_one_initcall+0x38/0x168)
      [<c0008928>] (do_one_initcall+0x38/0x168) from [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc)
      [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) from [<c0521064>] (kernel_init+0x8/0x110)
      [<c0521064>] (kernel_init+0x8/0x110) from [<c000e568>] (ret_from_fork+0x14/0x2c)
      Code: e92d4038 e2504000 01a05004 0a000005 (e5943034)
      
      So, just warn and continue instead of proceeding and crashing, with
      missing clock nodes/bad data, we will eventually fail, however we
      should now have enough information to identify the culprit.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0e7dc862
    • R
      ARM: OMAP2+: hwmod: Fix SOFTRESET logic · 313a76ee
      Roger Quadros 提交于
      In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
      the hwmod's sysc_cache will always contain SOFTRESET bit set
      so all further writes to sysconfig using this cache will initiate
      a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
      platforms that have RESET_DONE status in the SYSSTATUS register and
      so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
      It is not a problem for OMAP4 like platforms that indicate RESET
      completion by clearing the SOFTRESET bit in the SYSCONFIG register.
      
      This repeated SOFTRESET is undesired and was the root cause of
      USB host issues on OMAP3 platforms when hwmod was allowed to do the
      SOFTRESET for the USB Host module.
      
      To fix this we clear the SOFTRESET bit and update the sysconfig
      register + sysc_cache using write_sysconfig().
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
      [paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      313a76ee
  2. 14 10月, 2013 1 次提交
  3. 09 10月, 2013 2 次提交
    • R
      ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT · f92d9597
      Rajendra Nayak 提交于
      Now that we have DT bindings to specify which devices should not
      be reset and idled during init, make hwmod extract the information
      (and store them in internal flags) from Device tree.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f92d9597
    • S
      ARM: OMAP2+: hwmod: check for module address space during init · 6423d6df
      Suman Anna 提交于
      The hwmod init sequence involves initializing and idling all the
      hwmods during bootup. If a module class has sysconfig, the init
      sequence utilizes the module register base for performing any
      sysc configuration.
      
      The module address space is being removed from hwmod database and
      retrieved from the <reg> property of the corresponding DT node.
      If a hwmod does not have its corresponding DT node defined and the
      memory address space is not defined in the corresponding
      omap_hwmod_ocp_if, then the module register target address space
      would be NULL and any sysc programming would result in a NULL
      pointer dereference and a kernel boot hang.
      
      Handle this scenario by checking for a valid module address space
      during the _init of each hwmod, and leaving it in the registered
      state if no module register address base is defined in either of
      the hwmod data or the DT data.
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NNishanth Menon <nm@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      [paul@pwsan.com: use -ENXIO rather than -ENOMEM to indicate a missing address
       space error; fixed checkpatch.pl problem]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6423d6df
  4. 23 8月, 2013 1 次提交
    • J
      ARM: OMAP2+: Only write the sysconfig on idle when necessary · 127500cc
      Jon Hunter 提交于
      Currently, whenever we idle a device _idle_sysc() is called and writes to the
      devices SYSCONFIG register to set the idle mode. A lot devices are using the
      smart-idle mode and so the write to the SYSCONFIG register is programming the
      same value that is already stored in the register.
      
      Writes to the devices SYSCONFIG register can be slow, for example, writing to
      the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional
      clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can
      take ~100us.
      
      Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
      calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
      the SYSCONFIG register with a new value.
      
      Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
      idling the device, only write the value if the value has changed. It should be
      safe to do this on idle as the context of the register will never be lost while
      the device is active.
      
      Verified that suspend, CORE off and retention states are working with this
      change on OMAP3430 Beagle board.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      127500cc
  5. 13 8月, 2013 1 次提交
  6. 30 7月, 2013 1 次提交
    • A
      ARM: OMAP2+: hwmod: rt address space index for DT · 130142d9
      Afzal Mohammed 提交于
      Address space is being removed from hwmod database and DT information
      in <reg> property is being used. Currently the 0th index of device
      address space is used to map for register target address. This is not
      always true, eg. cpgmac has it's sysconfig in second address space.
      
      Handle it by specifying index of device address space to be used for
      register target. As default value of this field would be zero with
      static initialization, existing behaviour of using first address space
      for register target while using DT would be kept as such.
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Tested-by: NMugunthan V N <mugunthanvnm@ti.com>
      [paul@pwsan.com: use u8 rather than int to save memory]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      130142d9
  7. 20 5月, 2013 3 次提交
  8. 17 5月, 2013 1 次提交
    • J
      ARM: OMAP: fix __init section mismatch for _enable_preprogram · 0f497039
      jean-philippe francois 提交于
      _enable_preprogram is marked as __init, but is called from _enable
      which is not. Without this patch, the board oopses after init. Tested
      on custom hardware and on beagle board xM. Otherwise we can get:
      
      Unable to handle kernel paging request at virtual address 000b0012
      pgd = cf968000
      *pgd=8fb06831, *pte=00000000, *ppte=00000000
      PREEMPT ARM
      Modules linked in:
      CPU: 0    Not tainted  (3.9.0 #2)
      PC is at _enable_preprogram+0x1c/0x24
      LR is at omap_hwmod_enable+0x34/0x60
         psr: 80000093
      sp : cf95de08  ip : 00002de5  fp : bec33d4c
      r10: 00000000  r9 : 00000002  r8 : b6dd2c78
      r7 : 00000004  r6 : 00000000  r5 : a0000013  r4 : cf95c000
      r3 : 00000000  r2 : b6dd2c7c  r1 : 00000000  r0 : 000b0012
      Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: 8f968019  DAC: 00000015
      Process otpcmd (pid: 607, stack limit = 0xcf95c230)
      Stack: (0xcf95de08 to 0xcf95e000)
      de00:                   00000001 cf91f840 00000000 c001d6fc 00000002 cf91f840
      de20: cf8f7e10 c001de54 cf8f7e10 c001de78 c001de68 c01d5e80 00000000 cf8f7e10
      de40: cf8f7e10 c01d5f28 cf8f7e10 c0530d30 00000000 c01d6f28 00000000 c0088664
      de60: b6ea1000 cfb05284 cf95c000 00000001 cf95c000 60000013 00000001 cf95dee4
      de80: cf870050 c01d7308 cf870010 cf870050 00000001 c0278b14 c0526f28 00000000
      dea0: cf870050 ffff8e18 00000001 cf95dee4 00000000 c0274f7c cf870050 00000001
      dec0: cf95dee4 cf1d8484 000000e0 c0276464 00000008 cf9c0000 00000007 c0276980
      dee0: cf9c0000 00000064 00000008 cf1d8404 cf1d8400 c01cc05c 0000270a cf1d8504
      df00: 00000023 cf1d8484 00000007 c01cc670 00000bdd 00000001 00000000 cf449e60
      df20: cf1dde70 cf1d8400 bec33d18 cf1d8504 c0246f00 00000003 cf95c000 00000000
      df40: bec33d4c c01cd078 00000003 cf1d8504 00000081 c01cbcb8 bec33d18 00000003
      df60: bec33d18 c00a9034 00002000 c00a9c68 cf92fe00 00000003 c0246f00 cf92fe00
      df80: 00000000 c00a9cb0 00000003 00000000 00008e70 00000000 b6f17000 00000036
      dfa0: c000e484 c000e300 00008e70 00000000 00000003 c0246f00 bec33d18 bec33d18
      dfc0: 00008e70 00000000 b6f17000 00000036 00000000 00000000 b6f6d000 bec33d4c
      dfe0: b6ea1bd0 bec33d0c 00008c9c b6ea1bdc 60000010 00000003 00000000 00000000
      (_omap_device_enable_hwmods+0x20/0x34)
      (omap_device_enable+0x3c/0x50)
      (_od_runtime_resume+0x10/0x1c)
      (__rpm_callback+0x54/0x98)
      (rpm_callback+0x64/0x7c)
      (rpm_resume+0x434/0x554)
      (__pm_runtime_resume+0x48/0x74)
      (omap_i2c_xfer+0x28/0xe8)
      (__i2c_transfer+0x3c/0x78)
      (i2c_transfer+0x6c/0xc0)
      (i2c_master_send+0x38/0x48)
      (sha204p_send_command+0x60/0x9c)
      (sha204c_send_and_receive+0x5c/0x1e0)
      (sha204m_read+0x94/0xa0)
      (otp_do_read+0x50/0xa4)
      (vfs_ioctl+0x24/0x40)
      (do_vfs_ioctl+0x1b0/0x1c0)
      (sys_ioctl+0x38/0x54)
      (ret_fast_syscall+0x0/0x30)
      Code: e1a08002 ea000009 e598003c e592c05c (e7904003)
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJean-Philippe Fran=C3=A7ois <jp.francois@cynove.com>
      Acked-by: NKevin Hilman <khilman@linaro.org>
      [tony@atomide.com: updated description with oops]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0f497039
  9. 03 5月, 2013 1 次提交
    • R
      ARM: OMAP: use consistent error checking · c48cd659
      Russell King 提交于
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      {
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      {
      ...
      	return gpmc_cs_set_timings(cs, t);
      
      .....
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      errors...
      
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      {
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      }
      
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c48cd659
  10. 09 4月, 2013 2 次提交
  11. 08 4月, 2013 1 次提交
  12. 01 4月, 2013 1 次提交
  13. 14 3月, 2013 1 次提交
    • R
      ARM: OMAP: use consistent error checking · 71856843
      Russell King 提交于
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      {
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      {
      ...
      	return gpmc_cs_set_timings(cs, t);
      
      .....
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      errors...
      
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      {
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      }
      
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      71856843
  14. 13 3月, 2013 1 次提交
    • G
      ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb · 092bc089
      Grazvydas Ignotas 提交于
      For some unknown reason, allowing hwmod to control MIDLEMODE causes
      core_pwrdm to not hit idle states for musb in DM3730 at least.
      I've verified that setting any MIDLEMODE value other than "force
      standby" before enabling the device causes subsequent suspend
      attempts to fail with core_pwrdm not entering idle states, even
      if the driver is unloaded and "force standby" is restored before
      suspend attempt. To recover from this, soft reset can be used, but
      that's not suitable solution for suspend.
      
      Keeping the register set at force standby (reset value) makes it work
      and device still functions properly, as musb has driver-controlled
      OTG_FORCESTDBY register that controls MSTANDBY signal.
      Note that TI PSP kernels also have similar workarounds.
      
      This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
      actual flag name.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      092bc089
  15. 11 2月, 2013 1 次提交
    • P
      ARM: OMAP2+: hwmod: add enable_preprogram hook · 6d266f63
      Paul Walmsley 提交于
      After setup/enable, some IP blocks need some additional setting to
      indicate the PRCM that they are inactive until they are configured.
      Some examples on OMAP4 include the AESS and FSUSB IP blocks.
      
      To fix this cleanly, this patch adds another optional function
      pointer, enable_preprogram, to the IP block's hwmod data.  The function
      that is pointed to is called by the hwmod code immediately after the
      IP block is reset.
      
      This version of the patch includes a patch description fix from Felipe.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NSebastien Guiriec <s-guiriec@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Felipe Balbi <balbi@ti.com>
      6d266f63
  16. 08 2月, 2013 1 次提交
  17. 07 2月, 2013 1 次提交
    • P
      ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active · db27c0c0
      Paul Walmsley 提交于
      Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
      certain peripherals are active.  It's not clear why, and it's likely
      that there is simply some other bug in the driver or integration code.
      But since the likelihood that anyone will have the time to track these
      problems down in the future seems quite small, we'll provide a
      flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      db27c0c0
  18. 26 1月, 2013 1 次提交
    • P
      ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active · fa200222
      Paul Walmsley 提交于
      Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
      certain peripherals are active.  It's not clear why, and it's likely
      that there is simply some other bug in the driver or integration code.
      But since the likelihood that anyone will have the time to track these
      problems down in the future seems quite small, we'll provide a
      flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      fa200222
  19. 12 1月, 2013 1 次提交
    • T
      ARM: OMAP2+: Use omap initcalls · b76c8b19
      Tony Lindgren 提交于
      This way the initcalls don't run on other SoCs on multiplatform
      kernels. Otherwise we'll get something like this when booting
      on vexpress:
      
      omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
      ...
      WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
      _init_omap_device: could not find omap_hwmod for mpu
      ...
      omap-dma-engine omap-dma-engine: OMAP DMA engine driver
      ...
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b76c8b19
  20. 22 11月, 2012 2 次提交
    • P
      ARM: OMAP2+: hwmod: Add possibility to count hwmod resources based on type · dad4191d
      Peter Ujfalusi 提交于
      Add flags parameter for omap_hwmod_count_resources() so users can tell which
      type of resources they are interested when counting them in hwmod database.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: NBenoît Cousson <b-cousson@ti.com>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      dad4191d
    • R
      ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count · e6d3a8b0
      Rajendra Nayak 提交于
      OMAP4 has module specific context lost registers which makes it now
      possible to have module level context loss count, instead of relying
      on the powerdomain level context count.
      
      Add 2 private hwmod api's to update/clear the hwmod/module specific
      context lost counters/register.
      
      Update the module specific context_lost_counter and clear the hardware
      bits just after enabling the module.
      
      omap_hwmod_get_context_loss_count() now returns the hwmod context loss
      count them on platforms where they exist (OMAP4), else fall back on
      the pwrdm level counters for older platforms.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
       rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
       prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
       and clear, merged patches]
      [t-kristo@ti.com: added support for arch specific hwmod ops, and changed
       the no context offset indicator to USHRT_MAX]
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
       convert unsigned context lost counter to int to match the return type;
       get rid of hwmod_ops in favor of the existing soc_ops mechanism;
       move context loss low-level accesses to the PRM code]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e6d3a8b0
  21. 13 11月, 2012 3 次提交
  22. 09 11月, 2012 3 次提交
  23. 31 10月, 2012 1 次提交
    • P
      ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init · 5fb3d522
      Paul Walmsley 提交于
      Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
      dependent on an off-chip functional clock that is not guaranteed to be
      present during initialization.  IP blocks marked with this flag are
      left in the INITIALIZED state during kernel init.
      
      This is a workaround for a hardware problem.  It should be possible to
      guarantee that at least one clock source will be present and active
      for any IP block's main functional clock.  This ensures that the hwmod
      code can enable and reset the IP block.  Resetting the IP block during
      kernel init prevents any bogus bootloader, ROM code, or previous OS
      configuration from affecting the kernel.  Hopefully a clock
      multiplexer can be added on future SoCs.
      
      N.B., at some point in the future, it should be possible to query the
      clock framework for this type of information.  Then this flag should
      no longer be needed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      5fb3d522
  24. 30 10月, 2012 1 次提交
    • T
      ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod · 613ad0e9
      Tero Kristo 提交于
      When waking up from off-mode, some IP blocks are reset automatically by
      hardware. For this reason, software must wait until the reset has
      completed before attempting to access the IP block.
      
      This patch fixes for example the bug introduced by commit
      6c31b215 ("mmc: omap_hsmmc: remove access
      to SYSCONFIG register"), in which the MMC IP block is reset during
      off-mode entry, but the code expects the module to be already available
      during the execution of context restore.
      
      This version includes a fix from Kevin Hilman <khilman@ti.com> for
      GPIO problems on the 37xx EVM - thanks Kevin.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Venkatraman S <svenkatr@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      [paul@pwsan.com: moved softreset wait code into separate function; call
       from top of _enable_sysc() rather than the bottom; include fix from Kevin
       Hilman for GPIO sluggishness]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      613ad0e9
  25. 21 10月, 2012 2 次提交
  26. 19 10月, 2012 2 次提交
  27. 09 10月, 2012 1 次提交
    • P
      ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling · e9332b6e
      Paul Walmsley 提交于
      Commit eb05f691 ("ARM: OMAP: hwmod:
      partially un-reset hwmods might not be properly enabled") added code
      to skip the IP block disable sequence if all of the block's hardreset
      lines weren't asserted.  But this did not handle the case when no
      hardreset lines were associated with a module, which is the general
      case.  In that situation, the IP block disable would be skipped.  This
      is likely to cause PM regressions.
      
      So, modify _omap4_disable_module() and _am33xx_disable_module() to
      only bail out early if there are any hardreset lines asserted.  And
      move the AM33xx test above the actual module disable code to ensure
      that the behavior is consistent.
      Reported-by: NArchit Taneja <a0393947@ti.com>
      Tested-by: Archit Taneja <a0393947@ti.com> # DSS
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> # AM335x
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e9332b6e
  28. 24 9月, 2012 1 次提交
    • P
      ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems · b71c7217
      Paul Walmsley 提交于
      The idle status of the IP blocks and clocks inside the EMU clockdomain
      isn't taken into account by the PRCM hardware when deciding whether
      the clockdomain is idle.  Add a workaround flag in the clockdomain
      code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
      the code necessary to support it.
      
      If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
      clockdomain will be forced active whenever an IP block inside that
      clockdomain is in use, even if the clockdomain supports
      hardware-supervised idle.  When the kernel indicates that the last
      active IP block inside the clockdomain is no longer used, the
      clockdomain will be forced idle, or, if that mode is not supported in
      the hardware, it will be placed into hardware-supervised idle.
      
      This patch is an equal collaboration with Jon Hunter
      <jon-hunter@ti.com>.  Ming Lei <ming.lei@canonical.com>, Will Deacon
      <will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman
      <khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh
      Shilimkar <santosh.shilimkar@ti.com> all made essential contributions
      to the understanding of EMU clockdomain power management on OMAP.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Madhav Vij <mvij@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NJon Hunter <jon-hunter@ti.com>
      b71c7217