diff mbox

[RFC,V3,4/4] cpuidle: Single/Global registration of idle states

Message ID 87k4eo6d5m.fsf@ti.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Kevin Hilman April 20, 2011, 5:33 p.m. UTC
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.

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.

Kevin

Comments

Trinabh Gupta April 21, 2011, 4:53 a.m. UTC | #1
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
Kevin Hilman April 22, 2011, 11:06 p.m. UTC | #2
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
diff mbox

Patch

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++;