| Message ID | 87k4eo6d5m.fsf@ti.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
On 04/20/2011 11:03 PM, Kevin Hilman wrote: > Trinabh Gupta<trinabh@linux.vnet.ibm.com> writes: > >> With this patch there is single copy of cpuidle_states structure >> instead of per-cpu. The statistics needed on per-cpu basis >> by the governor are kept per-cpu. This simplifies the cpuidle >> subsystem as state registration is done by single cpu only. >> Having single copy of cpuidle_states saves memory. Rare case >> of asymmetric C-states can be handled within the cpuidle driverand >> architectures such as POWER do not have asymmetric C-states. > > I haven't actually tested this series on OMAP yet, but it currently > doesn't compile. Hi Kevin, Yes, I tested it only for x86 (as I had mentioned in the description of the patch series). I just wanted to get comments on the design and understand how it affects various architectures in question. It looks to me as if the design should be okay and infact better for architectures like ARM since they do not have different idle states for different cpus and thus do not require per-cpu registration. Global registration would work and be simpler; please correct me if I am wrong. > > The patch below (on top of your series) is required to compile on OMAP, > I think it's doing what you intended, but please confirm. Thanks for helping with this. -Trinabh -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Trinabh, Trinabh Gupta <trinabh@linux.vnet.ibm.com> writes: [...] > I just wanted to get comments on the design and understand how it > affects various architectures in question. It looks to me as if the > design should be okay and infact better for architectures like ARM > since they do not have different idle states for different cpus and > thus do not require per-cpu registration. Global registration would > work and be simpler; please correct me if I am wrong. Yes, I agree that the new design is better, I especially like that it's more clear (and expected) that final state decision making is to be done directly in the driver without the back-and-forth in the current setup. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 6641574..ab77ba3 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -512,6 +512,7 @@ static int omap3_cpuidle_driver_init(void) int i, retval, count = 0; struct omap3_processor_cx *cx; struct cpuidle_state *state; + struct cpuidle_driver *drv = &omap3_idle_driver; mpu_pd = pwrdm_lookup("mpu_pwrdm"); core_pd = pwrdm_lookup("core_pwrdm"); @@ -532,7 +533,7 @@ static int omap3_cpuidle_driver_init(void) state->enter = (state->flags & CPUIDLE_FLAG_CHECK_BM) ? omap3_enter_idle_bm : omap3_enter_idle; if (cx->type == OMAP3_STATE_C1) - dev->safe_state_index = count; + drv->safe_state_index = count; sprintf(state->name, "C%d", count+1); strncpy(state->desc, cx->desc, CPUIDLE_DESC_LEN); count++;