- 01 2月, 2014 1 次提交
-
-
由 Strashko, Grygorii 提交于
The same workaround as ff999b8a "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." need to be applied not only when system is booting, but when MPUSS hits OSWR state through CPUIdle too. Without this WA the same issue is reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 when CONFIG_CPU_IDLE is enabled. After MPUSS has enterred OSWR and waken up: - GIC distributor became disabled forever - scheduling is not performed any more Cc: Kevin Hilman <khilman@linaro.org> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reported-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 15 7月, 2013 1 次提交
-
-
由 Paul Gortmaker 提交于
The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. Note that some harmless section mismatch warnings may result, since notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c) and are flagged as __cpuinit -- so if we remove the __cpuinit from the arch specific callers, we will also get section mismatch warnings. As an intermediate step, we intend to turn the linux/init.h cpuinit related content into no-ops as early as possible, since that will get rid of these warnings. In any case, they are temporary and harmless. This removes all the ARM uses of the __cpuinit macros from C code, and all __CPUINIT from assembly code. It also had two ".previous" section statements that were paired off against __CPUINIT (aka .section ".cpuinit.text") that also get removed here. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Russell King <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 10 4月, 2013 4 次提交
-
-
由 Santosh Shilimkar 提交于
Current code has rather inconsistent function names for 'secondary_startup' routines. Update it to make it more consistent. Suggested by Kevin Hilman as part of OMAP5 PM patch review. Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKevin Hilman <khilman@linaro.org>
-
由 Santosh Shilimkar 提交于
OMAP5 and future OMAP based SOCs has backward compatible MPUSS IP block with OMAP4. It's programming model is mostly similar. Hence consolidate the OMAP MPUSS code so that it can be re-used on OMAP5 and future SOCs. No functional change. Acked-by: NNishanth Menon <nm@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKevin Hilman <khilman@linaro.org>
-
由 Santosh Shilimkar 提交于
Current CPU PM code code make use of common cpu_suspend() path for all the CPU power states which is not optimal. In fact cpu_suspend() path is needed only when we put CPU power domain to off state where the CPU context is lost. Update the code accordingly so that the expensive cpu_suspend() path can be avoided for the shallow CPU power states like CPU PD INA/CSWR. The patch has been tested on OMAP4430 and OMAP5430(with few out of tree patches) devices for suspend and CPUidle. Cc: Kevin Hilman <khilman@deeprootsystems.com> Reported-by: NRichard Woodruff <r-woodruff2@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKevin Hilman <khilman@linaro.org>
-
由 Santosh Shilimkar 提交于
Current OMAP4 CPUIdle driver is using omap4_mpuss_read_prev_context_state() to check whether the MPU cluster lost context or not before calling cpu_cluster_pm_exit(). This was initially done an optimization for corner cases, where if the cluster low power entry fails for some reason, the cluster context restore gets skipped. However, since reading the previous context is expensive (involving slow accesses to the PRCM), it's better to avoid it and simply check the target cluster state instead. Moving forward, OMAP CPUidle drivers needs to be moved to drivers/idle/* once the PRM/CM code gets moved to drivers. This patch also reduces one dependency with platform code for idle driver movement. Acked-by: NNishanth Menon <nm@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> [khilman@linaro.org: minor changelog edits] Signed-off-by: NKevin Hilman <khilman@linaro.org>
-
- 30 1月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
The OMAP4 MPU subsystem power management code contains several unnecessary shim functions for powerdomain control; remove them. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 06 11月, 2012 1 次提交
-
-
由 Santosh Shilimkar 提交于
On OMAP4+ devices, GIC register context is lost when MPUSS hits the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code gets executed and one of the steps in it is to restore the saved context of the GIC. The ROM Code GIC distributor restoration is split in two parts: CPU specific register done by each CPU and common register done by only one CPU. Below is the abstract flow. ............................................................... - MPUSS in OSWR state. - CPU0 wakes up on the event(interrupt) and start executing ROM code. [..] - CPU0 executes "GIC Restoration:" [...] - CPU0 swicthes to non-secure mode and jumps to OS resume code. [...] - CPU0 is online in OS - CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1 - CPU0 wakes up CPU1 with clock-domain force wakeup method. - CPU0 continues it's execution. [..] - CPU1 wakes up and start executing ROM code. [..] - CPU1 executes "GIC Restoration:" [..] - CPU1 swicthes to non-secure mode and jumps to OS resume code. [...] - CPU1 is online in OS and start executing. [...] - GIC Restoration: /* Common routine for HS and GP devices */ { if (GICD != 1) { /* This will be true in OSWR state */ if (GIC_SAR_BACKUP_STATE == SAVED) - CPU restores GIC distributor else - reconfigure GIC distributor to boot values. GICD.Enable secure = 1 } if (GIC_SAR_BACKUP_STATE == SAVED) - CPU restore its GIC CPU interface registers if saved. else - reconfigure its GIC CPU interface registers to boot values. } ............................................................... So as mentioned in the flow, GICD != 1 condition decides how the GIC registers are handled in ROM code wakeup path from OSWR. As evident from the flow, ROM code relies on the entire GICD register value and not specific register bits. The assumption was valid till CortexA9 r1pX version since there was only one banked bit to control secure and non-secure GICD. Secure view which ROM code sees: bit 0 == Enable Non-secure Non-secure view which HLOS sees: bit 0 == Enable secure But GICD register has changed between CortexA9 r1pX and r2pX. On r2pX GICD register is composed of 2 bits. Secure view which ROM code sees: bit 1 == Enable Non-secure bit 0 == Enable secure Non-secure view which HLOS sees: bit 0 == Enable Non-secure Hence on OMAP4460(r2pX) devices, if you go through the above flow again during CPU1 wakeup, GICD == 3 and hence ROM code fails to understand the real wakeup power state and reconfigures GIC distributor to boot values. This is nasty since you loose the entire interrupt controller context in a live system. The ROM code fix done on next OMAP4 device (OMAP4470 - r2px) is to check "GICD.Enable secure != 1" for GIC restoration in OSWR wakeup path. Since ROM code can't be fixed on OMAP4460 devices, a work around needs to be implemented. As evident from the flow, as long as CPU1 sees GICD == 1 in it's wakeup path from OSWR, the issue won't happen. Below is the flow with the work-around. ............................................................... - MPUSS in OSWR state. - CPU0 wakes up on the event(interrupt) and start executing ROM code. [..] - CPU0 executes "GIC Restoration:" [..] - CPU0 swicthes to non-secure mode and jumps to OS resume code. [..] - CPU0 is online in OS. - CPU0 does GICD.Enable Non-secure = 0 - CPU0 wakes up CPU1 with clock domain force wakeup method. - CPU0 waits for GICD.Enable Non-secure = 1 - CPU0 coninues it's execution. [..] - CPU1 wakes up and start executing ROM code. [..] - CPU1 executes "GIC Restoration:" [..] - CPU1 swicthes to non-secure mode and jumps to OS resume code. [..] - CPU1 is online in OS - CPU1 does GICD.Enable Non-secure = 1 - CPU1 start executing [...] ............................................................... With this procedure, the GIC configuration done between the CPU0 wakeup and CPU1 wakeup will not be lost but during this short windows, the CPU0 will not receive interrupts. The BUG is applicable to only OMAP4460(r2pX) devices. OMAP4470 (also r2pX) is not affected by this bug because ROM code has been fixed. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 19 10月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
We want to remove plat/cpu.h. To do this, let's first split it to private soc.h to mach-omap1 and mach-omap2. We have to keep plat/cpu.h around until the remaining drivers are fixed, so let's include the local soc.h in plat/cpu.h and for drivers still including plat/cpu.h. Once the drivers are fixed not to include plat/cpu.h, we can remove the file. This is needed for the ARM common zImage support. [tony@atomide.com: updated to not print a warning] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 13 9月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
These can now be moved to be local headers in mach-omap2. Note that this patch removes arch/arm/plat-omap/devices.c as it will get removed anyways with Paul Walmsley's patch "ARM: OMAP: split OMAP1, OMAP2+ RNG device registration". Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 20 7月, 2012 1 次提交
-
-
由 Masanari Iida 提交于
Correcting spelling typo in mach-omap2 Signed-off-by: NMasanari Iida <standby24x7@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 26 6月, 2012 1 次提交
-
-
由 Kevin Hilman 提交于
Iteration over all power domains in the idle path is unnecessary since only power domains that are transitioning need to be accounted for. Also PRCM register accesses are known to be expensive, so the additional latency added to the idle path is signficiant. In order allow the pre/post transitions to be isolated and called per-pwrdm, change the API so passing in a specific power domain will trigger the pre/post transtion accounting for only that specific power domain. Passing NULL means iterating over all power domains as is current behavior. Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NGrazvydas Ignotas <notasas@gmail.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 29 3月, 2012 1 次提交
-
-
由 David Howells 提交于
Disintegrate asm/system.h for ARM. Signed-off-by: NDavid Howells <dhowells@redhat.com> cc: Russell King <linux@arm.linux.org.uk> cc: linux-arm-kernel@lists.infradead.org
-
- 06 3月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst(). pwrdm_pre_transition(), which appears a few lines after these calls, invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no need to do it twice. N.B.: some of us have observed that accesses to the previous powerstate registers seem to be quite slow. Although the writes removed by this patch should be buffered by the write buffer, there is a read to a PRM register immediately afterwards. That will block the OMAP3 MPU until all of those writes complete. So this patch should result in a minor performance improvement during idle entry. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NTero Kristo <t-kristo@ti.com> [khilman@ti.com: removed a couple more for OMAP4] Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 29 2月, 2012 1 次提交
-
-
由 Santosh Shilimkar 提交于
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x8b80): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup() The function omap4_hotplug_cpu() references the function __cpuinit omap_secondary_startup(). This is often because omap4_hotplug_cpu lacks a __cpuinit annotation or the annotation of omap_secondary_startup is wrong. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 09 12月, 2011 6 次提交
-
-
由 Santosh Shilimkar 提交于
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Santosh Shilimkar 提交于
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: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Santosh Shilimkar 提交于
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: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Santosh Shilimkar 提交于
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: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Santosh Shilimkar 提交于
Program non-boot CPUs to hit lowest supported power state when it is off-lined using cpu hotplug framework. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Santosh Shilimkar 提交于
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: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-