summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/prm44xx.h
AgeCommit message (Collapse)Author
2010-12-22OMAP4: 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-22OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific filePaul Walmsley
Move the OMAP4 global software reset function to the OMAP4-specific prm44xx.c file, where it belongs. Part of the long-term process of moving all of the direct PRCM register writes into lower-layer code. Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU will continue executing while the system is supposed to be resetting itself. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP4: 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-22OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific filesPaul Walmsley
In preparation for adding OMAP4-specific PRCM accessor/mutator functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was OMAP2xxx/3xxx-specific. This process also requires the #includes in each of these files to be changed to reference the new file name. As part of doing so, add some comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use "sideways includes", to indicate that these users of the PRM/CM includes should not be doing so. Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.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>
2010-12-22OMAP4: 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-22OMAP4: 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>
2010-09-27OMAP4: PM: Define additional registers for ES2Rajendra Nayak
4430 ES2 has a few new registers added and a few modified from ES1. This patch adds all the register changes in PRM and CM for OMAP4430 ES2. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-05-20OMAP4: PRCM: Add offset defines for all PRM registersRajendra Nayak
The prm44xx.h files only had absolute register address defines for all PRM registers. This patch adds additional register offset defines for all the registers, so they can be used with apis like prm_read_mod_* Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-05-20OMAP4: PRM: Remove MPU internal code name and apply PRCM naming conventionBenoit Cousson
The MPU subsystem was named based on internal code name (CHIRON). This patch will remove all the occurences of the chiron name are replace it with PRCM_MPU in order to differentiate the MPU local PRCM to the global one. Remove PDA_ from PRCM_MPU registers names to stick to the global PRM naming convention. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-01-20OMAP4: PRCM: Fix the base address for CHIRONSS reg definesRajendra Nayak
The CHIRONSS has its own local PRCM module and the register defines need to use the CHIRONSS base and not the PRM base. The changes are generated by updating the script which autogenerates the file modifed in the patch. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-12-12ARM: OMAP4: PM: Adds PRM register defs for OMAP4Rajendra Nayak
This patch adds OMAP4 specific PRM register defs. Auto generated using a python script (gen_prm_4430_h.py) developed by Paul Walmsley and Benoit Cousson. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com>