- 16 Dec, 2011 11 commits
-
-
-
Rajendra Nayak authored
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device being already in enabled state. Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to identify such devices/hwmods. When the device/hwmod is requested to be enabled (the first time) by its driver/user, nothing except the mux-enable is needed. The mux data is board specific and is unavailable during initial enable() of the device, done by the framework as part of setup(). A good example of a such a device is an UART used as debug console. The UART module needs to be kept enabled through the boot, until the UART driver takes control of it, for debug prints to appear on the console. Acked-by:
Kevin Hilman <khilman@ti.com> Acked-by:
Benoit Cousson <b-cousson@ti.com> Signed-off-by:
Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use a flag rather than a state; updated commit message; edited some documentation] Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tero Kristo authored
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:
-
Tero Kristo authored
PM interrupt handling is now done through the PRCM chain handler. The interrupt handling logic is also split in two parts, to serve IO and WKUP events separately. This allows us to handle IO chain events in a clean way. Core event code is also changed in accordance to this, as PRCM interrupt handling is done by independent handlers, and the core handler should not clear the IO events anymore. Signed-off-by:
-
Tero Kristo authored
By default all registered pads will trigger mpu_irqs[0]. Now there is an API for selecting used mpu_irq on pad basis, which can be used to trigger different irq handlers for different pads in the same hwmod. Each pad that requires its interrupt to be re-routed this way must have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq). Signed-off-by:
-
Tero Kristo authored
OMAP mux now parses active wakeup events from pad registers and calls corresponding hwmod ISRs once a wakeup is detected. This is accomplished by registering an interrupt handler for PRCM IO event, which is raised every time the HW detects wakeups. [paul@pwsan.com: This patch is a merge of Govindraj R's "ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status" patch, Tero Kristo's "ARM: OMAP2+: mux: add support for PAD wakeup interrupts" patch, and part of Tero's "ARM: OMAP: mux: add support for selecting mpu_irq for each wakeup pad" patch.] Signed-off-by:
-
Tero Kristo authored
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 authored
Introduce a chained interrupt handler mechanism for the PRCM interrupt, so that individual PRCM event can cleanly be handled by handlers in separate drivers. We do this by introducing PRCM event names, which are then matched to the particular PRCM interrupt bit depending on the specific OMAP SoC being used. PRCM interrupts have two priority levels, high or normal. High priority is needed for IO event handling, so that we can be sure that IO events are processed before other events. This reduces latency for IO event customers and also prevents incorrect ack sequence on OMAP3. Signed-off-by:
-
Paul Walmsley authored
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: -
Govindraj R authored
Add API to enable IO pad wakeup capability based on mux pad and wake_up enable flag available from hwmod_mux initialization. Use the wakeup_enable flag and enable wakeup capability for the given pads. Wakeup capability will be enabled/disabled during hwmod idle transition based on whether wakeup_flag is set or cleared. If the hwmod is currently idled, and any mux values were changed by _set_idle_ioring_wakeup(), the SCM PADCTRL registers will be updated. Signed-off-by:
Govindraj.R <govindraj.raja@ti.com> Signed-off-by:
-
Paul Walmsley authored
omap_hwmod_mux() currently only iterates through the dynamic pad list. This list currently only consists of pads with the OMAP_DEVICE_MUX_REMUX flag set. Subsequent patches in this series will cause hwmod mux entries with the OMAP_DEVICE_MUX_WAKEUP flag set to be changed dynamically, to control hwmod I/O ring wakeup. For this to work correctly, hwmod mux entries with the OMAP_DEVICE_MUX_WAKEUP flag set must also be added to the dynamic pad list. So this patch modifies omap_hwmod_mux_init() to do so. Signed-off-by:
-
- 08 Dec, 2011 25 commits
-
-
Tony Lindgren authored
Merge branch 'for_3.3/pm/omap4-mpuss' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap4
-
Santosh Shilimkar authored
Save VFP CPU context using CPU PM notifier chain. VFP context is lost when CPU hits OFF state. Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by:
Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by:
-
Santosh Shilimkar authored
CPU local timer(TWD) stops when the CPU is transitioning into deeper C-States. Since these timers are not wakeup capable, we need the wakeup capable global timer to program the wakeup time depending on the next timer expiry. It can be handled by registering a global wakeup capable timer along with local timers marked with (mis)feature flag CLOCK_EVT_FEAT_C3STOP. Then notify the clock events layer from idle code using CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT). ARM local timers are already marked with C3STOP feature. Add the notifiers to OMAP4 CPU idle code for the broadcast entry and exit. Signed-off-by:
Jean Pihet <j-pihet@ti.com> Acked-by:
-
Santosh Shilimkar authored
Add OMAP4 CPUIDLE support. CPU1 is left with defualt idle and the low power state for it is managed via cpu-hotplug. This patch adds MPUSS low power states in cpuidle. C1 - CPU0 ON + CPU1 ON + MPU ON C2 - CPU0 OFF + CPU1 OFF + MPU CSWR C3 - CPU0 OFF + CPU1 OFF + MPU OSWR OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more anymore just like CORE power domain. The deepest state supported is OSWr. Ofcourse when MPUSS and CORE PD transitions to OSWR along with device off mode, even the memory contemts are lost which is as good as the PD off state. On OMAP4 because of hardware constraints, no low power states are targeted when both CPUs are online and in SMP mode. The low power states are attempted only when secondary CPU gets offline to OFF through hotplug infrastructure. Thanks to Nicole Chalhoub <n-chalhoub@ti.com> for doing exhaustive C-state latency profiling. Signed-off-by:
-
Santosh Shilimkar authored
On OMAP4 SOC, intecronnects has many write buffers in the async bridges and they need to be drained before CPU enters into standby state. Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support but OMAP errata i688 (Async Bridge Corruption) needs to be taken care to avoid issues like system freeze, CPU deadlocks, random crashes with register accesses, synchronisation loss on initiators operating on both interconnect port simultaneously. As per the errata, if a data is stalled inside asynchronous bridge because of back pressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF and MPU to L3 interconnect. This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software when executing WFI on CPU). The work-around for this errata needs all the initiators connected through async bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure that there is no synchronisation loss on initiators operating on both interconnect port simultaneously. Thanks to Russell for a tip to conver assembly function to C fuction there by reducing 40 odd lines of code from the patch. Signed-off-by:
Richard Woodruff <r-woodruff2@ti.com> Acked-by:
-
Santosh Shilimkar authored
Signed-off-by:
-
Santosh Shilimkar authored
This patch adds the MPUSS OSWR (Open Switch Retention) support. The MPUSS OSWR configuration is as below. - CPUx L1 and logic lost, MPUSS logic lost, L2 memory is retained OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more anymore just like CORE power domain. The deepest state supported is OSWR. On OMAP4430 secure devices too, MPUSS off mode can't be used because of a bug which alters Ducati and Tesla states. Hence MPUSS off mode as an independent state isn't supported on OMAP44XX devices. Ofcourse when MPUSS power domain transitions to OSWR along with device off mode, it eventually hits off state since memory contents are lost. Hence the MPUSS off mode independent state is not attempted without device off mode. All the necessary infrastructure code for MPUSS off mode is in place as part of this series. Signed-off-by:
-
Santosh Shilimkar authored
When MPUSS hits off-mode, L2 cache is lost. This patch adds L2X0 necessary maintenance operations and context restoration in the low power code. Signed-off-by:
-
Santosh Shilimkar authored
Add WakeupGen and secure GIC low power support to save and restore it's registers. WakeupGen Registers are saved to pre-defined SAR RAM layout and the restore is automatically done by hardware(ROM code) while coming out of MPUSS OSWR or Device off state. Secure GIC is saved using secure API and restored by hardware like WakeupGen. Signed-off-by:
-
Santosh Shilimkar authored
With OMAP4 suspend, idle and hotplug series, we no longer need do_wfi() macro. Remove the same. Signed-off-by:
-
Santosh Shilimkar authored
This patch adds MPUSS(MPU Sub System) power domain CSWR(Close Switch Retention) support to system wide suspend. For MPUSS power domain to hit retention(CSWR or OSWR), both CPU0 and CPU1 power domains need to be in OFF or DORMANT state, since CPU power domain CSWR is not supported by hardware Signed-off-by:
-
Santosh Shilimkar authored
Default arch_idle() isn't good enough for OMAP4 because of aync bridge errata and necessity of NOPs post WFI to avoid speculative prefetch aborts. Hence Use OMAP4 custom omap_do_wfi() hook for default idle. Later in the series, async bridge errata work-around patch updates the omap_do_wfi() with necessary interconnects barriers. Signed-off-by:
-
Santosh Shilimkar authored
The SGI(Software Generated Interrupts) are not wakeup capable from low power states. This is known limitation on OMAP4 and needs to be worked around by using software forced clockdomain wake-up. CPU0 forces the CPU1 clockdomain to software force wakeup. More details can be found in OMAP4430 TRM - Version J Section : 4.3.4.2 Power States of CPU0 and CPU1 Signed-off-by:
-
Santosh Shilimkar authored
Program non-boot CPUs to hit lowest supported power state when it is off-lined using cpu hotplug framework. Signed-off-by:
-
Santosh Shilimkar authored
Remove the __INIT from omap_secondary_startup() so that it can be re-used for CPU hotplug. While at this, remove the un-used AUXBOOT register reference. Signed-off-by:
-
Santosh Shilimkar authored
This patch adds the CPU0 and CPU1 off mode support. CPUX close switch retention (CSWR) is not supported by hardware design. The CPUx OFF mode isn't supported on OMAP4430 ES1.0 CPUx sleep code is common for hotplug, suspend and CPUilde. Signed-off-by:
-
Santosh Shilimkar authored
OMAP WakeupGen is the interrupt controller extension used along with ARM GIC to wake the CPU out from low power states on external interrupts. The WakeupGen unit is responsible for generating the wakeup event from the incoming interrupts and enable bits. It is implemented in the MPU always ON power domain. During normal operation, WakeupGen delivers the external interrupts directly to the GIC. WakeupGen specification has one restriction as per Veyron version 1.6. It is SW responsibility to program interrupt enabling/disabling coherently in the GIC and in the WakeupGen enable registers. That is, a given interrupt for a given CPU is either enable at both GIC and WakeupGen, or disable at both, but no mix. That's the reason the WakeupGen is implemented as an extension of GIC. Signed-off-by:
-
Santosh Shilimkar authored
Allocate the memory to save secure ram context which needs to be done when MPU is hitting OFF mode. The ROM code expects a physical address to this memory and hence use memblock APIs to reserve this memory as part of .reserve() callback. Maximum size as per secure RAM requirements is allocated. To keep omap1 build working, omap-secure.h file is created under plat-omap directory. Signed-off-by:
-
Santosh Shilimkar authored
On OMAP secure/emulation devices, certain APIs are exported by secure code. Add an infrastructure so that relevant operations on secure devices can be implemented using it. While at this, rename omap44xx-smc.S to omap-smc.S since the common APIs can be used on other OMAP's too. Signed-off-by:
-
Santosh Shilimkar authored
Initialise hardware supervised mode for all clockdomains if it's supported. Initiate sleep transition for other clockdomains, if they are not being used. Signed-off-by:
-
Santosh Shilimkar authored
On OMAP4430 ES1.0, Power Management features are not supported. Avoid omap4_pm_init() on ES1.0 silicon so that we can continue to use same kernel binary to boot on all OMAP4 silicons. The ES1.0 boot failure with OMAP4 PM series was because of the clockdomain initialisation code. Hardware supervised clockdomain mode isn't functional for all clockdomains on OMAP4430 ES1.0 silicon so avoid the same. Signed-off-by:
-
Santosh Shilimkar authored
As per OMAP4430 TRM, the dynamic dependency between MPUSS -> EMIF and MPUSS -> L4PER/L3_* and DUCATI -> L3_* clockdomains is enable by default. Refer register CM_MPU_DYNAMICDEP description for details. But these dynamic dependencies doesn't work as expected. The hardware recommendation is to enable static dependencies for above clockdomains. Without this, system locks up or randomly crashes. Signed-off-by:
-
Santosh Shilimkar authored
This patch adds SAR RAM support on OMAP4430. SAR RAM used to save and restore the HW context in low power modes. Signed-off-by:
-
Santosh Shilimkar authored
This patch exports APIs to get base address for GIC distributor, CPU interface, SCU and PL310 L2 Cache which are used in OMAP4 PM code. This was suggested by Kevin Hilman <khilman@ti.com> during OMAP4 PM code review. Signed-off-by:
-
Santosh Shilimkar authored
OMAP4 L2X0 initialisation code uses BUG_ON() for the ioremap() failure scenarios. Use WARN_ON() instead and allow graceful function exits. This was suggsted by Kevin Hilman <khilman@ti.com> during OMAP4 PM code review. Signed-off-by:
-
- 06 Dec, 2011 2 commits
-
-
Tony Lindgren authored
ARM restart changes needed changes to common.h to make it local. This conflicted with v3.2-rc4 DSS related hwmod changes that git mergetool was not able to handle. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Tony Lindgren authored
Otherwise we get the following error: In function 'omap_init_consistent_dma_size': error: implicit declaration of function 'init_consistent_dma_size' Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
-
- 05 Dec, 2011 2 commits
-
-
-
Russell King authored
Merge branch 'for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into devel-stable Conflicts: arch/arm/common/gic.c arch/arm/plat-omap/include/plat/common.h
-
