linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] OMAP3: cpuidle: re-organize the C-states data
Date: Fri, 29 Apr 2011 16:54:16 +0530	[thread overview]
Message-ID: <4DBA9FE0.2030802@ti.com> (raw)
In-Reply-To: <1304069186-3086-4-git-send-email-j-pihet@ti.com>

Jean,

On 4/29/2011 2:56 PM, jean.pihet at newoldbits.com wrote:
> From: Jean Pihet<j-pihet@ti.com>
>
> The current implementation defines an internal structure and a
> C-states array. Using those structures is redundant to the
> structs used by the cpuidle framework.
>
> This patch provides a clean-up of the internal struct, removes the
> internal C-states array, stores the data using the existing cpuidle
> per C-state struct and registers the mach specific data to cpuidle
> C-state driver_data (accessed using cpuidle_[gs]et_statedata).
> Also removes unused macros, fields and code and compacts the repeating
> code using common macros.
>
> The result is more compact and more readable code as well as
> reduced data RAM usage.
>
> Signed-off-by: Jean Pihet<j-pihet@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle34xx.c |  286 +++++++++++++------------------------
>   1 files changed, 97 insertions(+), 189 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index d7bc31a..f84315c 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -36,34 +36,25 @@
>
>   #ifdef CONFIG_CPU_IDLE
>
> -#define OMAP3_MAX_STATES 7
> -#define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */
> -#define OMAP3_STATE_C2 1 /* C2 - MPU WFI + Core inactive */
> -#define OMAP3_STATE_C3 2 /* C3 - MPU CSWR + Core inactive */
> -#define OMAP3_STATE_C4 3 /* C4 - MPU OFF + Core iactive */
> -#define OMAP3_STATE_C5 4 /* C5 - MPU RET + Core RET */
> -#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core RET */
> -#define OMAP3_STATE_C7 6 /* C7 - MPU OFF + Core OFF */
> -
> -#define OMAP3_STATE_MAX OMAP3_STATE_C7
> -
> -#define CPUIDLE_FLAG_CHECK_BM	0x10000	/* use omap3_enter_idle_bm() */
> -
> -struct omap3_processor_cx {
> -	u8 valid;
> -	u8 type;
> -	u32 exit_latency;
> +#define OMAP3_STATE_C1		0 /* C1 - MPU WFI + Core active */
> +#define OMAP3_STATE_C2		1 /* C2 - MPU WFI + Core inactive */
> +#define OMAP3_STATE_C3		2 /* C3 - MPU CSWR + Core inactive */
> +#define OMAP3_STATE_C4		3 /* C4 - MPU OFF + Core inactive */
> +#define OMAP3_STATE_C5		4 /* C5 - MPU RET + Core RET */
> +#define OMAP3_STATE_C6		5 /* C6 - MPU OFF + Core RET */
> +#define OMAP3_STATE_C7		6 /* C7 - MPU OFF + Core OFF */
> +#define OMAP3_STATE_MAX		OMAP3_STATE_C7
> +#define OMAP3_MAX_STATES	7
> +
> +/* Mach specific information to be recorded in the C-state driver_data */
> +struct omap3_idle_statedata {
>   	u32 mpu_state;
>   	u32 core_state;
> -	u32 target_residency;
> -	u32 flags;
> -	const char *desc;
> +	u8 valid;
>   };
> +struct omap3_idle_statedata omap3_idle_data[OMAP3_MAX_STATES];
>
> -struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
> -struct omap3_processor_cx current_cx_state;
> -struct powerdomain *mpu_pd, *core_pd, *per_pd;
> -struct powerdomain *cam_pd;
> +struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
>
>   /*
>    * The latencies/thresholds for various C states have
> @@ -72,7 +63,7 @@ struct powerdomain *cam_pd;
>    * the best power savings) used on boards which do not
>    * pass these details from the board file.
>    */
> -static struct cpuidle_params cpuidle_params_table[] = {
> +static struct cpuidle_params cpuidle_params_table[OMAP3_MAX_STATES] = {

Nice cleanup. Using idle per device C-state struct is much cleaner
than the those static arrays.

[...]

>
> +/* Fill in the state data from the mach tables and register the driver_data */
> +#define FILL_IN_STATE(idx, descr)					\
> +do {									\
> +	state				=&dev->states[count];		\
> +	params				=&cpuidle_params_table[idx];	\
> +	data				=&omap3_idle_data[idx];	\
> +	state->exit_latency		= params->exit_latency;		\
> +	state->target_residency		= params->target_residency;	\
> +	state->flags			= CPUIDLE_FLAG_TIME_VALID;	\
> +	state->enter			= omap3_enter_idle_bm;		\
> +	sprintf(state->name, "C%d", count + 1);				\
> +	strncpy(state->desc, descr, CPUIDLE_DESC_LEN);			\
> +	data->valid			= params->valid;		\
> +	cpuidle_set_statedata(state, data);				\
> +	count++;							\
> +} while (0);
> +
I like this macro as well. It avoids un-necessary lines on the C-state
initialization code.

Good work.

Regards
Santosh

  reply	other threads:[~2011-04-29 11:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-29  9:26 [PATCH 0/5] OMAP: cpuidle code clean-up jean.pihet at newoldbits.com
2011-04-29  9:26 ` [PATCH 1/5] OMAP3 cpuidle: remove useless SDP specific timings jean.pihet at newoldbits.com
2011-04-29 11:14   ` Santosh Shilimkar
2011-05-04 14:40   ` Kevin Hilman
2011-04-29  9:26 ` [PATCH 2/5] OMAP3: clean-up mach specific cpuidle data structures jean.pihet at newoldbits.com
2011-05-04 20:09   ` Kevin Hilman
2011-04-29  9:26 ` [PATCH 3/5] OMAP3: cpuidle: re-organize the C-states data jean.pihet at newoldbits.com
2011-04-29 11:24   ` Santosh Shilimkar [this message]
2011-05-04 14:59   ` Kevin Hilman
2011-04-29  9:26 ` [PATCH 4/5] OMAP3: cpuidle: code rework for improved readability jean.pihet at newoldbits.com
2011-05-04 15:32   ` Kevin Hilman
2011-04-29  9:26 ` [PATCH 5/5] OMAP3: cpuidle: change the power domains modes determination logic jean.pihet at newoldbits.com
2011-04-29 11:29   ` Santosh Shilimkar
2011-04-29 14:00     ` Jean Pihet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DBA9FE0.2030802@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).