summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/prm44xx.c
AgeCommit message (Collapse)Author
2012-02-13ARM: omap: fix prm44xx.c OMAP44XX_IRQ_PRCM build errorRussell King
When CONFIG_OF is disabled, the compile fails with: arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function) Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-12-16Merge branch 'tk_prm_chain_handler_devel_3.3' of ↵Tony Lindgren
git://git.pwsan.com/linux-2.6 into prcm Conflicts: arch/arm/mach-omap2/Makefile
2011-12-16ARM: OMAP4: PRM: use PRCM interrupt handlerTero Kristo
Use the new PRCM interrupt handler code on OMAP4 systems. The OMAP code will need to be converted to use sparse IRQs for this to work. Until that time, the following message will appear on boot: PRCM: failed to allocate irq descs: -12 Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: split this from a previous patch to this patch; call omap4xxx_prcm_init() during init; write trivial commit log] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP: PRCM: add suspend prepare / finish supportTero Kristo
PRCM chain handler needs to disable forwarding of interrupts during suspend, because runtime PM is disabled and most of the drivers are potentially not able to handle interrupts coming at this time. This patch masks all the PRCM interrupt events if a PRCM interrupt occurs during suspend, but does not ack them. Once suspend finish is called, all the masked events will be re-enabled, which causes immediate PRCM interrupt and handles the postponed event. The suspend prepare and complete callbacks will be called from pm34xx.c / pm44xx.c files in the following patches. The functions defined in this patch should eventually be moved to suspend->prepare and suspend->finish driver hooks, once the PRCM chain handler will be made as its own driver. Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: add kerneldoc, add omap_prcm_irq_setup.saved_mask, add fn ptrs for save_and_clear_irqen() and restore_irqen()] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-12-16ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrierPaul Walmsley
Add PRM functions to test for pending PRM IRQs. This will be used in a subsequent patch to implement the PRM interrupt handler on the MPU. Add PRM functions to ensure that all outstanding writes from the MPU to the PRM IP block have completed before continuing execution. This will be used in a subsequent patch to ensure that all PRM interrupt status bits are cleared in the hardware before exiting the ISR. Normally we would not expose such a low-level function to other code. But the current implementation of the PRM interrupt code, which uses the generic IRQ chip code, doesn't give us a choice. The pending PRM IRQ functions are based on code originally written by Tero Kristo <t-kristo@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com>
2011-11-17ARM: 7159/1: OMAP: Introduce local common.h filesTony Lindgren
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-09-15OMAP2+: PRM: add register access functions for VC/VPKevin Hilman
On OMAP3+, the voltage controller (VC) and voltage processor (VP) are inside the PRM. Add some PRM helper functions for register access to these module registers. Thanks to Nishanth Menon for finding/fixing a sparse problem. Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP2+: add PRM VP functions for checking/clearing VP TX done statusKevin Hilman
Add SoC specific PRM VP helper functions for checking and clearing the VP transaction done status. Longer term, these events should be handled by the forthcoming PRCM interrupt handler. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-07-10OMAP4: prm: Remove deprecated functionsBenoit Cousson
The new prminst_xxx accessors based on partition and offset is now used, so removed all the previous prcm_xxx accessors. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: remove fn prototypes also] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP4: prm: Replace warm reset API with the offset based versionBenoit Cousson
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>
2011-07-10OMAP4: hwmod: Replace RSTCTRL absolute address with offset macrosBenoit Cousson
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>
2010-12-21OMAP4: 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-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: 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-21OMAP4: PRM: add module hard reset supportBenoît Cousson
Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset under the control of the PRM. This patch adds an API for this purpose for OMAP4 devices: int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift); int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift); int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift); This API is intended to be used only by the hwmod code - a subsequent patch will add that support to hwmod. This patch is a collaboration between Benoît Cousson <b-cousson@ti.com> and Paul Walmsley <paul@pwsan.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>