public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: benh@kernel.crashing.org, daniel.lezcano@linaro.org,
	mark.rutland@arm.com, lorenzo.pieralisi@arm.com,
	linux-pm@vger.kernel.org, mpe@ellerman.id.au,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	shreyas@linux.vnet.ibm.com, svaidy@linux.vnet.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode
Date: Wed, 24 Jun 2015 15:50:40 +0200	[thread overview]
Message-ID: <1700583.a34yOllUuC@vostro.rjw.lan> (raw)
In-Reply-To: <20150624064801.30680.3246.stgit@perfhull-ltc.austin.ibm.com>

On Wednesday, June 24, 2015 01:48:01 AM Preeti U Murthy wrote:
> On some archs, the local clockevent device stops in deep cpuidle states.
> The broadcast framework is used to wakeup cpus in these idle states, in
> which either an external clockevent device is used to send wakeup ipis
> or the hrtimer broadcast framework kicks in in the absence of such a
> device. One cpu is nominated as the broadcast cpu and this cpu sends
> wakeup ipis to sleeping cpus at the appropriate time. This is the
> implementation in the oneshot mode of broadcast.
> 
> In periodic mode of broadcast however, the presence of such cpuidle
> states results in the cpuidle driver calling tick_broadcast_enable()
> which shuts down the local clockevent devices of all the cpus and
> appoints the tick broadcast device as the clockevent device for each of
> them. This works on those archs where the tick broadcast device is a
> real clockevent device.  But on archs which depend on the hrtimer mode
> of broadcast, the tick broadcast device hapens to be a pseudo device.
> The consequence is that the local clockevent devices of all cpus are
> shutdown and the kernel hangs at boot time in periodic mode.
> 
> Let us thus not register the cpuidle states which have
> CPUIDLE_FLAG_TIMER_STOP flag set, on archs which depend on the hrtimer
> mode of broadcast in periodic mode. This patch takes care of doing this
> on powerpc. The cpus would not have entered into such deep cpuidle
> states in periodic mode on powerpc anyway. So there is no loss here.
> 
> Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>

4.2 material I suppose?

> ---
>  drivers/cpuidle/cpuidle-powernv.c |   15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
> index 5937207..3442764 100644
> --- a/drivers/cpuidle/cpuidle-powernv.c
> +++ b/drivers/cpuidle/cpuidle-powernv.c
> @@ -60,6 +60,8 @@ static int nap_loop(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> +/* Register for fastsleep only in oneshot mode of broadcast */
> +#ifdef CONFIG_TICK_ONESHOT
>  static int fastsleep_loop(struct cpuidle_device *dev,
>  				struct cpuidle_driver *drv,
>  				int index)
> @@ -83,7 +85,7 @@ static int fastsleep_loop(struct cpuidle_device *dev,
>  
>  	return index;
>  }
> -
> +#endif
>  /*
>   * States for dedicated partition case.
>   */
> @@ -209,7 +211,14 @@ static int powernv_add_idle_states(void)
>  			powernv_states[nr_idle_states].flags = 0;
>  			powernv_states[nr_idle_states].target_residency = 100;
>  			powernv_states[nr_idle_states].enter = &nap_loop;
> -		} else if (flags[i] & OPAL_PM_SLEEP_ENABLED ||
> +		}
> +
> +		/*
> +		 * All cpuidle states with CPUIDLE_FLAG_TIMER_STOP set must come
> +		 * within this config dependency check.
> +		 */
> +#ifdef CONFIG_TICK_ONESHOT
> +		if (flags[i] & OPAL_PM_SLEEP_ENABLED ||
>  			flags[i] & OPAL_PM_SLEEP_ENABLED_ER1) {
>  			/* Add FASTSLEEP state */
>  			strcpy(powernv_states[nr_idle_states].name, "FastSleep");
> @@ -218,7 +227,7 @@ static int powernv_add_idle_states(void)
>  			powernv_states[nr_idle_states].target_residency = 300000;
>  			powernv_states[nr_idle_states].enter = &fastsleep_loop;
>  		}
> -
> +#endif
>  		powernv_states[nr_idle_states].exit_latency =
>  				((unsigned int)latency_ns[i]) / 1000;
>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  reply	other threads:[~2015-06-24 13:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24  6:48 [PATCH] tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode Preeti U Murthy
2015-06-24 13:50 ` Rafael J. Wysocki [this message]
2015-06-24 22:06   ` Benjamin Herrenschmidt
2015-06-25  0:06     ` Rafael J. Wysocki
2015-06-25  3:35       ` Preeti U Murthy
2015-06-26 14:23         ` Rafael J. Wysocki
2015-06-24 22:10   ` Michael Ellerman
2015-06-24 22:28     ` Rafael J. Wysocki

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=1700583.a34yOllUuC@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=benh@kernel.crashing.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mpe@ellerman.id.au \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=shreyas@linux.vnet.ibm.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox