1. 27 10月, 2014 6 次提交
  2. 16 5月, 2014 2 次提交
  3. 08 5月, 2014 1 次提交
  4. 01 3月, 2014 1 次提交
    • D
      ARM: OMAP2+: clockdomain: Reintroduce SW_SLEEP Support · f67f04ba
      Dave Gerlach 提交于
      Since commit 65aa94b2 (ARM: OMAP4: clockdomain/CM code: Update supported
      transition modes), on OMAP4, all CLKDMs support HW_AUTO so this is used
      instead of SW_SLEEP for the idling of clockdomains. However, additional
      SoCs now leverage the OMAP4 clockdomain code so update it to use SW_SLEEP
      if the clockdomain data specifies that the CLKDM has the
      CLKDM_CAN_FORCE_SLEEP flag set rather than using HW_AUTO for both cases.
      
      Without this patch, clockdomain handling is broken on AM43xx and no
      clockdomains are actually being put into idle on this platform. Any
      attempt to idle them results in the HW_AUTO value (0x3) being written
      to them with no apparent effect.
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      [paul@pwsan.com: added extra explanatory text from patch set intro]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f67f04ba
  5. 14 10月, 2013 2 次提交
  6. 30 1月, 2013 1 次提交
  7. 21 10月, 2012 1 次提交
  8. 04 7月, 2012 1 次提交
    • J
      ARM: OMAP4: clockdomain/CM code: Update supported transition modes · 65aa94b2
      Jon Hunter 提交于
      For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
      following transition modes ...
      
      NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
      		 irrespective of the hardware conditions.
      SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated
      		 when the associated hardware conditions are satisfied
      SW_WKUP  (0x2) - A software-forced clock domain wake-up transition is initiated,
      		 irrespective of the hardware conditions.
      HW_AUTO  (0x3) - Hardware-controlled automatic sleep and wake-up transition is
      		 initiated by the PRCM module when the associated hardware
      		 conditions are satisfied.
      
      For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent
      to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP for OMAP4 devices
      is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of
      SW_SLEEP transition, and not set in case of HW_AUTO transition.
      
      For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the
      CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not
      need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is
      preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
      instead of NO_SLEEP where possible.
      
      For a software perspective the above 4 modes are represented by the following
      flags to indicate what modes are supported by each of the CLKDMs.
      
      CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
      CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
      CLKDM_CAN_FORCE_SLEEP	--> SW_SLEEP
      CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP
      
      By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices
      can becomes ...
      
      CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
      CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
      CLKDM_CAN_FORCE_SLEEP	--> HW_AUTO
      CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP
      
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Reviewed-by: NBenoit Cousson <b-cousson@ti.com>
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      65aa94b2
  9. 22 6月, 2012 1 次提交
    • P
      ARM: OMAP2+: CM: increase the module disable timeout · b8f15b7e
      Paul Walmsley 提交于
      Increase the timeout for disabling an IP block to five milliseconds.
      This is to handle the usb_host_fs idle latency, which takes almost
      four milliseconds after a host controller reset.
      
      This is the second of two patches needed to resolve the following
      boot warning:
      
      omap_hwmod: usb_host_fs: _wait_target_disable failed
      
      Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
      an unrelated hunk in a previous version of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      b8f15b7e
  10. 08 5月, 2012 1 次提交
  11. 25 2月, 2012 1 次提交
  12. 18 11月, 2011 1 次提交
  13. 10 7月, 2011 3 次提交
    • B
      OMAP4: cm: Add two new APIs for modulemode control · 288d6a16
      Benoit Cousson 提交于
      In OMAP4, a new programming model based on module control instead
      of clock control was introduced.
      Expose two APIs to allow the upper layer (omap_hwmod) to control
      the module mode independently of the parent clocks management.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; cleaned up
       kerneldoc]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      288d6a16
    • B
      OMAP: hwmod: Wait the idle status to be disabled · 11b10341
      Benoit Cousson 提交于
      It is mandatory to wait for a module to be in disabled state before
      potentially disabling source clock or re-asserting a reset.
      
      omap_hwmod_idle and omap_hwmod_shutdown does not wait for
      the module to be fully idle.
      
      Add a cm_xxx accessor to wait the clkctrl idle status to be disabled.
      Fix hwmod_[idle|shutdown] to use this API.
      
      Based on Rajendra's initial patch.
      
      Please note that most interconnects hwmod will return one timeout because
      it is impossible for them to be in idle since the processor is accessing
      the registers though the interconnect.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Todd Poynor <toddpoynor@google.com>
      [paul@pwsan.com: move cpu_is_*() tests to the top of _wait_target_disable();
       incorporate some feedback from Todd]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      11b10341
    • B
      OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros · d0f0631d
      Benoit Cousson 提交于
      The CLKCTRL register was accessed using an absolute address.
      The usage of hardcoded macros to calculate virtual address from physical
      one should be avoided as much as possible.
      The usage of a offset will allow future improvement like migration from
      the current architecture code toward a module driver.
      
      Update cm_xxx accessor, move definition to the proper header file and
      update copyrights.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Todd Poynor <toddpoynor@google.com>
      [paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; removed empty
       fn prototype section from cm44xx.h; incorporated comments from Todd;
       documented some functions]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d0f0631d
  14. 26 2月, 2011 1 次提交
  15. 22 12月, 2010 2 次提交
    • P
      OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support · bd2122ca
      Paul Walmsley 提交于
      Add PRCM partition, CM instance register address offset, and clockdomain
      register address offset to each OMAP4 struct clockdomain record.  Add OMAP4
      clockdomain code to use this new data to access registers properly.
      
      While here, clean up some nearby clockdomain code to allocate auto variables
      in my recollection of Linus's preferred style.
      
      The autogeneration scripts have been updated.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      bd2122ca
    • P
      OMAP4: PRCM: add OMAP4-specific accessor/mutator functions · 2ace831f
      Paul Walmsley 提交于
      In some ways, the OMAP4 PRCM register layout is quite different than
      the OMAP2/3 PRCM register layout.  For example, on OMAP2/3, from a
      register layout point of view, all CM instances were located in the CM
      subsystem, and all PRM instances were located in the PRM subsystem.
      OMAP4 changes this.  Now, for example, some CM instances, such as
      WKUP_CM and EMU_CM, are located in the system PRM subsystem.  And a
      "local PRCM" exists for the MPU - this PRCM combines registers that
      would normally appear in both CM and PRM instances, but uses its own
      register layout which matches neither the OMAP2/3 PRCM layout nor the
      OMAP4 PRCM layout.
      
      To try to deal with this, introduce some new functions, omap4_cminst*
      and omap4_prminst*.  The former is to be used when writing to a CM
      instance register (no matter what subsystem or hardware module it
      exists in), and the latter, similarly, with PRM instance registers.
      To determine which "PRCM partition" to write to, the functions take a
      PRCM instance ID argument.  Subsequent patches add these partition IDs
      to the OMAP4 powerdomain and clockdomain definitions.
      
      As far as I can see, there's really no good way to handle these types
      of register access inconsistencies.  This patch seemed like the least
      bad approach.
      
      Moving forward, the long-term goal is to remove all direct PRCM
      register access from the PM code.  PRCM register access should go
      through layers such as the powerdomain and clockdomain code that can
      hide the details of how to interact with the specific hardware
      variant.
      
      While here, rename cm4xxx.c to cm44xx.c to match the naming convention
      of the other OMAP4 PRCM files.
      
      Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
      <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      2ace831f