summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/prcm_mpu44xx.h
AgeCommit message (Collapse)Author
2014-05-15ARM: OMAP2+: PRCM: cleanup some header includesTero Kristo
Some of the includes are totally unnecessary, remove some others in preparation to make the PRCM its own driver. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: updated to apply; fixed build error on OMAP2xxx-only configs] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2013-06-08ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for re-useSantosh Shilimkar
OMAP5 reuses OMAP4 MPU PRCM IP block which lets us re-use functions. So move the function prototypes from prcm_mpu44xx.h to prcm_mpu_44xx_54xx.h header. The suggestion came from Paul Walmsley as part of the OMAP5 data file review. This is preparatory patch to add OMAP5 MPU PRCM data file. Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-11-08ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setupPaul Walmsley
Split omap2_set_globals_prcm() into PRM, CM, and PRCM_MPU variants, since these are all separate IP blocks. This should make it easier to move the PRM, CM, PRCM_MPU code into drivers/ in future patchsets. At this point arch/arm/plat-omap/include/plat/prcm.h is empty; a subsequent patch will remove it, and remove the #include from all the files that #include it. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2011-07-09OMAP4: prcm_mpu: Fix indent in few macrosBenoit Cousson
Some maros were not well aligned. Re-align them. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-01omap4: clockdomain: Fix the CPUx domain nameBenoit Cousson
The register naming convention for clock domain control inside power domain instance is: OMAPXXXX_<partition>_<power_domain>_<clock_domain>_CDOFFS Both CPU0 and CPU1 use MPU as clock domain name instead of CPU0 and CPU1. Change the name to stick to the convention. The autogen scripts are updated accordingly. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-02-25omap4: prcm: Fix the CPUx clockdomain offsetsSantosh Shilimkar
CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base. The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power domain control register Fix the same. The autogen scripts is fixed thanks to Benoit Cousson With the old value, the clockdomain code would access the *_PWRSTCTRL.POWERSTATE field when it thought it was accessing the *_CLKSTCTRL.CLKTRCTRL field. In the worst case, this could cause system power management to behave incorrectly. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: added second paragraph to commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: CM instances: add clockdomain register offsetsPaul Walmsley
In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP, CM_DYNAMICDEP, and the module-specific registers underneath) are organized by clockdomain. Add the clockdomain offset macros to the appropriate PRCM module header files. This data was almost completely autogenerated from the TI hardware database; the autogeneration scripts have been updated. Signed-off-by: Paul Walmsley <paul@pwsan.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-21OMAP4: PRCM: add OMAP4-specific accessor/mutator functionsPaul 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: 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>
2010-12-21OMAP4: PRCM: rename _MOD macros to _INSTPaul Walmsley
Back in the OMAP2/3 PRCM interface days, the macros that referred to the offsets of individual PRM/CM instances from the top of the PRM/CM hardware modules were incorrectly suffixed with "_MOD". (They should have been suffixed with something like "_INST" or "_INSTANCE".) These days, now that we have better contact with the OMAP hardware people, we know that this naming is wrong. And in fact in OMAP4, there are actual hardware module offsets inside the instances, so the incorrect naming gets confusing very quickly for anyone who knows the hardware. Fix this naming for OMAP4, before things get too far along, by changing "_MOD" to "_INST" on the end of these macros. So, for example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST. This unfortunately creates quite a large diff, but it is a straightforward rename. This patch should not result in any functional changes. The autogeneration scripts have been updated accordingly. 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> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-21OMAP4: PRCM: reorganize existing OMAP4 PRCM header filesPaul Walmsley
Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. Move the "_MOD" macros out of the prcm-common.h header file, into the header file of the hardware module that they belong to. For example, OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header. Adjust #includes of all files that used the old PRCM header file names to point to the new filenames. The autogeneration scripts have been updated accordingly. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>