summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/cminst44xx.c
AgeCommit message (Collapse)AuthorFilesLines
2013-01-30ARM: OMAP2+: clockdomain: convert existing atomic usecounts into ↵Paul Walmsley1-1/+1
spinlock-protected shorts/ints The atomic usecounts seem to be confusing, and are no longer needed since the operations that they are attached to really should take place under lock. Replace the atomic counters with simple integers, protected by the enclosing powerdomain spinlock. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2012-10-21ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions ↵Paul Walmsley1-1/+141
into PRM/CM Move the low-level SoC-specific clockdomain control functions into cm*.c and prm*.c. For example, OMAP2xxx low-level clockdomain functions go into cm2xxx.c. Then remove the unnecessary clockdomain*xxx*.c files. The objective is to centralize low-level CM and PRM register accesses into the cm*.[ch] and prm*.[ch] files, and then to export an OMAP SoC-independent API to higher-level OMAP power management code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-07-04ARM: OMAP4: clockdomain/CM code: Update supported transition modesJon Hunter1-14/+0
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: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-06-22ARM: OMAP2+: CM: increase the module disable timeoutPaul Walmsley1-2/+2
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: Paul Walmsley <paul@pwsan.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Cc: Tero Kristo <t-kristo@ti.com>
2012-05-08ARM: OMAP4+: Add prm and cm base init function.R Sricharan1-10/+18
Instead of statically defining seperate arrays for every OMAP4+ archs, have a generic init function to populate the arrays. This avoids the need for creating new array for every arch added in the future that reuses the prm and cm registers read/write code. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-02-24ARM: OMAP2+: Move most of plat/io.h into local iomap.hTony Lindgren1-1/+1
There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-17ARM: 7159/1: OMAP: Introduce local common.h filesTony Lindgren1-1/+1
As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-10OMAP4: cm: Add two new APIs for modulemode controlBenoit Cousson1-0/+40
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP: hwmod: Wait the idle status to be disabledBenoit Cousson1-0/+25
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: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Rajendra 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: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP4: hwmod: Replace CLKCTRL absolute address with offset macrosBenoit Cousson1-18/+69
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: Benoit 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: Paul Walmsley <paul@pwsan.com>
2011-02-26OMAP4: CM: Add CM accesor api for bitwise controlRajendra Nayak1-0/+21
Add new OMAP4 CM accesor apis to set/clear and read bitfields (based on mask) from CM registers. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 supportPaul Walmsley1-0/+105
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: Paul 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: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-12-22OMAP4: PRCM: add OMAP4-specific accessor/mutator functionsPaul Walmsley1-0/+109
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: Paul 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>