All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Tero Kristo <tero.kristo@nokia.com>
Cc: linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Vishwanath Sripathy <vishwanath.bs@ti.com>
Subject: Re: [PATCHv2] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
Date: Mon, 07 Mar 2011 13:51:04 -0800	[thread overview]
Message-ID: <87sjuy1tx3.fsf@ti.com> (raw)
In-Reply-To: <1295606225-11834-1-git-send-email-tero.kristo@nokia.com> (Tero Kristo's message of "Fri, 21 Jan 2011 12:37:05 +0200")

Hi Tero,

Tero Kristo <tero.kristo@nokia.com> writes:

> On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
> parts of the chip will be reset.  If those parts of the chip are busy,
> the reset will disrupt them, causing unpredictable and generally
> undesirable results. This reset is caused by the core domain wakeup
> (COREDOMAINWKUP_RST), and it can occur for example in a case where
> some peripheral domain is in retention or inactive state and core
> enters off. This will result in the peripheral domain being reset.
>
> Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Vishwanath Sripathy <vishwanath.bs@ti.com>
> ---

Turns out this one suffers from same problem as the the other DSS one
because of sleepdeps.  

In today's linux-omap because of sleepdeps, at least DSS will always
report ON during this check, and I think USB does as well.  The result
is that core powerdomain will never hit off-mode.

I'm going to drop this one from my 2.6.39 queue for now as well until
we have a cleaner way to check powerdomain idle status.

Kevin

>  arch/arm/mach-omap2/cpuidle34xx.c |   40 +++++++++++++++++++++++++++++++++++-
>  1 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index f3e043f..d31b858 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -61,7 +61,7 @@ struct omap3_processor_cx {
>  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 *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
>  
>  /*
>   * The latencies/thresholds for various C states have
> @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>  {
>  	struct cpuidle_state *new_state = next_valid_state(dev, state);
>  	u32 core_next_state, per_next_state = 0, per_saved_state = 0;
> -	u32 cam_state;
> +	u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
>  	struct omap3_processor_cx *cx;
>  	int ret;
>  
> @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>  	 *        its own code.
>  	 */
>  
> +	/* XXX Add CORE-active check here */
> +
>  	/*
>  	 * Prevent idle completely if CAM is active.
>  	 * CAM does not have wakeup capability in OMAP3.
> @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>  	    (core_next_state > PWRDM_POWER_RET))
>  		per_next_state = PWRDM_POWER_RET;
>  
> +	/* XXX Add prevent-PER-off check here */
> +
> +	/*
> +	 * If we are attempting CORE off, check if any other powerdomains
> +	 * are at retention or higher. CORE off causes chipwide reset which
> +	 * would reset these domains also.
> +	 */
> +	if (core_next_state == PWRDM_POWER_OFF) {
> +		iva2_state = pwrdm_read_pwrst(iva2_pd);
> +		sgx_state = pwrdm_read_pwrst(sgx_pd);
> +		usb_state = pwrdm_read_pwrst(usb_pd);
> +		dss_state = pwrdm_read_pwrst(dss_pd);

Because of existing sleepdeps, some of these may be still on during the
idle path  (especially DSS and USB in mainline kernels.)

> +		if (cam_state > PWRDM_POWER_OFF ||
> +		    dss_state > PWRDM_POWER_OFF ||
> +		    iva2_state > PWRDM_POWER_OFF ||
> +		    per_next_state > PWRDM_POWER_OFF ||
> +		    sgx_state > PWRDM_POWER_OFF ||
> +		    usb_state > PWRDM_POWER_OFF)
> +			core_next_state = PWRDM_POWER_RET;
> +	}
> +
> +	/* Fallback to new target core/mpu state */
> +	while (cx->core_state < core_next_state) {
> +		state--;
> +		cx = cpuidle_get_statedata(state);
> +	}
> +
> +	new_state = state;
> +
>  	/* Are we changing PER target state? */
>  	if (per_next_state != per_saved_state)
>  		pwrdm_set_next_pwrst(per_pd, per_next_state);
> @@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
>  	core_pd = pwrdm_lookup("core_pwrdm");
>  	per_pd = pwrdm_lookup("per_pwrdm");
>  	cam_pd = pwrdm_lookup("cam_pwrdm");
> +	dss_pd = pwrdm_lookup("dss_pwrdm");
> +	iva2_pd = pwrdm_lookup("iva2_pwrdm");
> +	sgx_pd = pwrdm_lookup("sgx_pwrdm");
> +	usb_pd = pwrdm_lookup("usbhost_pwrdm");
>  
>  	omap_init_power_states();
>  	cpuidle_register_driver(&omap3_idle_driver);

      parent reply	other threads:[~2011-03-07 21:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21 10:37 [PATCHv2] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain Tero Kristo
2011-01-21 10:04 ` Santosh Shilimkar
2011-01-22  0:57 ` Kevin Hilman
2011-03-03 23:48 ` Kevin Hilman
2011-03-07 21:51 ` Kevin Hilman [this message]

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=87sjuy1tx3.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=tero.kristo@nokia.com \
    --cc=vishwanath.bs@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.