summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/prminst44xx.h
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP4+: PRM: determine prm_device_inst based on DT compatibilityTero Kristo2015-03-311-0/+1
| | | | | | | | PRM device instance offset is now provided through the prm_init_data. This gets rid of some cpu_is_X / soc_is_X calls from PRM core code, preparing for PRM to be its own separate driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
* ARM: OMAP2+: PRM: add generic API for deasserting hardware resetTero Kristo2014-10-271-2/+3
| | | | | | | | | | PRM driver now has a generic API for deasserting hardware resets. SoC specific support functions are registered through the prm_ll_data. Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP4+: prminst: provide function to find prm_dev instance offsetNishanth Menon2014-09-081-0/+3
| | | | | | | | | | PRM device instance can vary depending on SoC. We already handle the same during reset of the device, However, this is also needed for other logic instances. So, first abstract this out to a generic function. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setupPaul Walmsley2012-11-081-0/+2
| | | | | | | | | | | | | 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>
* OMAP4: prm: Replace warm reset API with the offset based versionBenoit Cousson2011-07-101-4/+4
| | | | | | | | | | | | | | The warm reset function was still using the obsolete API. Replace it by the new one and move the file to the proper c file. Change the function names to stick to the file convention as suggested by Paul Walmsley <paul@pwsan.com>: prm_xxx -> prminst_xxx 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>
* OMAP4: hwmod: Replace RSTCTRL absolute address with offset macrosBenoit Cousson2011-07-101-1/+9
| | | | | | | | | | | | | | | | | | | The RSTCTRL 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 an offset will allow future improvement like migration from the current architecture code toward a module driver. Update prm_xxx accessors, move definition to the proper header file and update copyrights. Change the s16 register offset parameter to u16. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use '_prminst_' in function names that are part of the prminst44xx.c file] Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP4: PRCM: add OMAP4-specific accessor/mutator functionsPaul Walmsley2010-12-211-0/+25
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>