1. 13 8月, 2013 1 次提交
  2. 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
  3. 20 5月, 2013 3 次提交
  4. 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
  5. 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
  6. 09 4月, 2013 2 次提交
  7. 08 4月, 2013 1 次提交
  8. 01 4月, 2013 1 次提交
  9. 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
  10. 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
  11. 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
  12. 08 2月, 2013 1 次提交
  13. 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
  14. 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
  15. 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
  16. 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
  17. 13 11月, 2012 3 次提交
  18. 09 11月, 2012 3 次提交
  19. 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
  20. 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
  21. 21 10月, 2012 2 次提交
  22. 19 10月, 2012 2 次提交
  23. 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
  24. 24 9月, 2012 5 次提交
    • 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
    • O
      ARM: OMAP: hwmod: revise deassert sequence · e8e96dff
      Omar Ramirez Luna 提交于
      For a reset sequence to complete cleanly, a module needs its
      associated clocks to be enabled, otherwise the timeout check
      in prcm code can print a false failure (failed to hardreset)
      that occurs because the clocks aren't powered ON and the status
      bit checked can't transition without them.
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e8e96dff
    • O
      ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled · eb05f691
      Omar Ramirez Luna 提交于
      Some IP blocks might not be using/controlling more than one
      reset line, this check loosens the restriction to fully use
      hwmod framework for those drivers.
      
      E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
      - As of now cpu1 is not used and hence (with previous check) the
        IP block isn't fully enabled by hwmod code.
      - Usually ipu and dsp processors configure their mmu module first
        and then enable the processors, this involves:
          * Deasserting mmu reset line, and enabling the module.
          * Deasserting cpu0 reset line, and enabling the processor.
        The ones portrayed in this example are controlled through
        rproc_fw_boot in drivers/remoteproc/remoteproc_core.c
      
      While at it, prevent _omap4_module_disable if all the hardreset
      lines on an IP block are not under reset.
      
      This will allow the driver to:
        a. Deassert the reset line.
        b. Enable the hwmod through runtime PM default callbacks.
        c. Do its usecase.
        d. Disable hwmod through runtime PM.
        e. Assert the reset line.
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      eb05f691
    • P
      ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages · 3bb05dbf
      Paul Walmsley 提交于
      The decision was made a few months ago to allow struct omap_hwmod
      records and struct clk records to omit clockdomain information if the
      clockdomain is not software-controllable.  See for example commit
      868c157d ("ARM: OMAP2+: hwmod: remove
      prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain").
      
      So convert an existing pr_warning() to a pr_debug() (regarding missing
      clockdomains in clocks), and add a pr_debug() for missing hwmod
      clockdomains.  It's still useful to enable these messages for
      debugging, since missing clockdomains can cause hard-to-debug problems
      with power management; see for example commit
      6c4a057b ("ARM: OMAP4: clock data:
      Force a DPLL clkdm/pwrdm ON before a relock").
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      3bb05dbf
    • P
      ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*() · 2b026d13
      Paul Walmsley 提交于
      We're no longer requiring struct omap_hwmod records to contain a
      clockdomain.  So we shouldn't return -EINVAL any more from
      _omap4_wait_target_disable() or _omap4_wait_target_ready() if there's
      no clockdomain defined, since that just gets passed back to the
      caller.  This can result in pointless warnings under the relaxed data
      format.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      2b026d13
  25. 23 9月, 2012 2 次提交
    • R
      ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk · 5dcc3b97
      Rajendra Nayak 提交于
      While we move to Common Clk Framework (CCF), direct deferencing of struct
      clk wouldn't be possible anymore. Hence get rid of all such instances
      in the current clock code and use macros/helpers similar to the ones that
      are provided by CCF.
      
      While here also concatenate some strings split across multiple lines
      which seem to be needed anyway.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: simplified some compound expressions; reformatted some
       messages]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      5dcc3b97
    • R
      ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage · 6ea74cb9
      Rajendra Nayak 提交于
      Moving to Common clk framework for OMAP would mean we no longer use
      internal lookup mechanism like omap_clk_get_by_name().
      get rid of all its usage mostly from hwmod and omap_device
      code.
      
      Moving to clk_get() also means the respective platforms
      need the clkdev tables updated with an entry for all clocks
      used by hwmod to have clock name same as the alias.
      
      Based on original changes from Mike Turquette.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      [paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment);
       restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx
       clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added
       aliases rng_ick and several emulation clocks]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6ea74cb9