| Message ID | 1347290626-21164-9-git-send-email-jon-hunter@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi On Mon, 10 Sep 2012, Jon Hunter wrote: > When CPU-idle is enabled, the MPU sub-system will transition to low power > states during idle periods. If the PMU is active and the MPU sub-system > transitions to a low power state, such as retention, then the PMU context > will be lost and PMU events will stop. To prevent this from happening add a > QoS constraint whenever PMU is active to prevent the MPU sub-system from > transitioning to a low power state. > > By default the PMU QoS constraint is set to -1 so it will not prevent any low > power states and when the PMU is enabled, it is set to 0, so that only C-state > C0 is allowed. I plan to re-visit this and relax the constraint to allow some > low power states, but for now I just wish to ensure PMU is working. > > Cc: Ming Lei <ming.lei@canonical.com> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Benoit Cousson <b-cousson@ti.com> > Cc: Paul Walmsley <paul@pwsan.com> > Cc: Kevin Hilman <khilman@ti.com> > > Signed-off-by: Jon Hunter <jon-hunter@ti.com> This one looks like 3.7-rc material, due to the dependency on Will's PMU runtime PM adaptation series, which is unfortunately not yet in the stable merge base that I need to use to send these upstream. Jon, care to update and re-send this one after Linus merges the other PMU patches? - Paul
Hi Paul, On 09/20/2012 12:14 PM, Paul Walmsley wrote: > Hi > > On Mon, 10 Sep 2012, Jon Hunter wrote: > >> When CPU-idle is enabled, the MPU sub-system will transition to low power >> states during idle periods. If the PMU is active and the MPU sub-system >> transitions to a low power state, such as retention, then the PMU context >> will be lost and PMU events will stop. To prevent this from happening add a >> QoS constraint whenever PMU is active to prevent the MPU sub-system from >> transitioning to a low power state. >> >> By default the PMU QoS constraint is set to -1 so it will not prevent any low >> power states and when the PMU is enabled, it is set to 0, so that only C-state >> C0 is allowed. I plan to re-visit this and relax the constraint to allow some >> low power states, but for now I just wish to ensure PMU is working. >> >> Cc: Ming Lei <ming.lei@canonical.com> >> Cc: Will Deacon <will.deacon@arm.com> >> Cc: Benoit Cousson <b-cousson@ti.com> >> Cc: Paul Walmsley <paul@pwsan.com> >> Cc: Kevin Hilman <khilman@ti.com> >> >> Signed-off-by: Jon Hunter <jon-hunter@ti.com> > > This one looks like 3.7-rc material, due to the dependency on Will's PMU > runtime PM adaptation series, which is unfortunately not yet in the > stable merge base that I need to use to send these upstream. Jon, care to > update and re-send this one after Linus merges the other PMU patches? Yes no problem. Will send out during the 3.7-rc. Cheers Jon
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c index 7fbaa3f..ca158f0 100644 --- a/arch/arm/mach-omap2/pmu.c +++ b/arch/arm/mach-omap2/pmu.c @@ -13,6 +13,7 @@ * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. */ +#include <linux/pm_qos.h> #include <linux/pm_runtime.h> #include <asm/pmu.h> @@ -24,11 +25,41 @@ static char *omap2_pmu_oh_names[] = {"mpu"}; static char *omap3_pmu_oh_names[] = {"mpu", "debugss"}; static char *omap4430_pmu_oh_names[] = {"l3_main_3", "l3_instr", "debugss"}; +static struct pm_qos_request pmu_pm_qos_request; static struct platform_device *omap_pmu_dev; -static struct arm_pmu_platdata omap_pmu_data; static struct cti omap4_cti[2]; /** + * omap_pmu_runtime_resume - PMU runtime resume callback + * @dev OMAP PMU device + * + * Platform specific PMU runtime resume callback for OMAP devices to + * configure the cross trigger interface for routing PMU interrupts. + * This is called by the PM runtime framework. + */ +static int omap_pmu_runtime_resume(struct device *dev) +{ + pm_qos_update_request(&pmu_pm_qos_request, 0); + + return 0; +} + +/** + * omap_pmu_runtime_suspend - PMU runtime suspend callback + * @dev OMAP PMU device + * + * Platform specific PMU runtime suspend callback for OMAP devices to + * disable the cross trigger interface interrupts. This is called by + * the PM runtime framework. + */ +static int omap_pmu_runtime_suspend(struct device *dev) +{ + pm_qos_update_request(&pmu_pm_qos_request, PM_QOS_DEFAULT_VALUE); + + return 0; +} + +/** * omap4_pmu_runtime_resume - PMU runtime resume callback * @dev OMAP PMU device * @@ -38,6 +69,8 @@ static struct cti omap4_cti[2]; */ static int omap4_pmu_runtime_resume(struct device *dev) { + pm_qos_update_request(&pmu_pm_qos_request, 0); + /* configure CTI0 for PMU IRQ routing */ cti_unlock(&omap4_cti[0]); cti_map_trigger(&omap4_cti[0], 1, 6, 2); @@ -64,6 +97,8 @@ static int omap4_pmu_runtime_suspend(struct device *dev) cti_disable(&omap4_cti[0]); cti_disable(&omap4_cti[1]); + pm_qos_update_request(&pmu_pm_qos_request, PM_QOS_DEFAULT_VALUE); + return 0; } @@ -111,6 +146,11 @@ static int __init omap4_init_cti(void) return 0; } +static struct arm_pmu_platdata omap_pmu_data = { + .runtime_resume = omap_pmu_runtime_resume, + .runtime_suspend = omap_pmu_runtime_suspend, +}; + /** * omap2_init_pmu - creates and registers PMU platform device * @oh_num: Number of OMAP HWMODs required to create PMU device @@ -183,6 +223,11 @@ static int __init omap_init_pmu(void) oh_names = omap2_pmu_oh_names; } - return omap2_init_pmu(oh_num, oh_names); + r = omap2_init_pmu(oh_num, oh_names); + if (!r) + pm_qos_add_request(&pmu_pm_qos_request, PM_QOS_CPU_DMA_LATENCY, + PM_QOS_DEFAULT_VALUE); + + return r; } subsys_initcall(omap_init_pmu);
When CPU-idle is enabled, the MPU sub-system will transition to low power states during idle periods. If the PMU is active and the MPU sub-system transitions to a low power state, such as retention, then the PMU context will be lost and PMU events will stop. To prevent this from happening add a QoS constraint whenever PMU is active to prevent the MPU sub-system from transitioning to a low power state. By default the PMU QoS constraint is set to -1 so it will not prevent any low power states and when the PMU is enabled, it is set to 0, so that only C-state C0 is allowed. I plan to re-visit this and relax the constraint to allow some low power states, but for now I just wish to ensure PMU is working. Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> --- arch/arm/mach-omap2/pmu.c | 49 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 47 insertions(+), 2 deletions(-)