All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Russell King <linux@arm.linux.org.uk>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze()
Date: Wed, 8 Apr 2015 12:55:46 +0100	[thread overview]
Message-ID: <20150408115546.GA24271@red-moon> (raw)
In-Reply-To: <1428490480-10144-1-git-send-email-tomeu.vizoso@collabora.com>

On Wed, Apr 08, 2015 at 11:54:38AM +0100, Tomeu Vizoso wrote:
> This callback is expected to do the same as enter() only that all
> non-wakeup IRQs are expected to be disabled.

This is not true or at least it is misworded. The enter_freeze() function
is expected to return from the state with IRQs disabled at CPU level, or
put it differently it must not re-enable IRQs while executing since the
tick is frozen.

> It will be called when the system goes to suspend-to-idle and will
> reduce power usage because CPUs won't be awaken for unnecessary IRQs.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  arch/arm/mach-tegra/cpuidle-tegra114.c | 31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index f2b586d..ef06001 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -39,28 +39,44 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>  				    struct cpuidle_driver *drv,
>  				    int index)
>  {
> -	local_fiq_disable();
> -
>  	tegra_set_cpu_in_lp2();
>  	cpu_pm_enter();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> -
>  	call_firmware_op(prepare_idle);
>  
>  	/* Do suspend by ourselves if the firmware does not implement it */
>  	if (call_firmware_op(do_idle, 0) == -ENOSYS)
>  		cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> -
>  	cpu_pm_exit();
>  	tegra_clear_cpu_in_lp2();
>  
> +	return index;
> +}
> +
> +static int tegra114_idle_enter(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	local_fiq_disable();
> +
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +
> +	index = tegra114_idle_power_down(dev, drv, index);
> +
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +
>  	local_fiq_enable();
>  
>  	return index;
>  }
> +
> +static void tegra114_idle_enter_freeze(struct cpuidle_device *dev,
> +				       struct cpuidle_driver *drv,
> +				       int index)
> +{
> +	tegra114_idle_power_down(dev, drv, index);

Cool. So if the problem is FIQs, you don't disabled them on entry
which means you enter the "frozen" state with FIQs enabled and tick frozen,
unless I am missing something.

The question here is: are we allowed to enable FIQs before returning
from an enter_freeze() call (and to enter it with FIQs enabled) ?

If we are not your code here certainly does not solve the issue, since
it does _not_ disable FIQs upon enter_freeze call anyway.

Lorenzo

> +}
>  #endif
>  
>  static struct cpuidle_driver tegra_idle_driver = {
> @@ -71,7 +87,8 @@ static struct cpuidle_driver tegra_idle_driver = {
>  		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
>  #ifdef CONFIG_PM_SLEEP
>  		[1] = {
> -			.enter			= tegra114_idle_power_down,
> +			.enter			= tegra114_idle_enter,
> +			.enter_freeze		= tegra114_idle_enter_freeze,
>  			.exit_latency		= 500,
>  			.target_residency	= 1000,
>  			.power_usage		= 0,
> -- 
> 2.3.4
> 
> --
> 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/
> 

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze()
Date: Wed, 8 Apr 2015 12:55:46 +0100	[thread overview]
Message-ID: <20150408115546.GA24271@red-moon> (raw)
In-Reply-To: <1428490480-10144-1-git-send-email-tomeu.vizoso@collabora.com>

On Wed, Apr 08, 2015 at 11:54:38AM +0100, Tomeu Vizoso wrote:
> This callback is expected to do the same as enter() only that all
> non-wakeup IRQs are expected to be disabled.

This is not true or at least it is misworded. The enter_freeze() function
is expected to return from the state with IRQs disabled at CPU level, or
put it differently it must not re-enable IRQs while executing since the
tick is frozen.

> It will be called when the system goes to suspend-to-idle and will
> reduce power usage because CPUs won't be awaken for unnecessary IRQs.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  arch/arm/mach-tegra/cpuidle-tegra114.c | 31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
> index f2b586d..ef06001 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra114.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
> @@ -39,28 +39,44 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>  				    struct cpuidle_driver *drv,
>  				    int index)
>  {
> -	local_fiq_disable();
> -
>  	tegra_set_cpu_in_lp2();
>  	cpu_pm_enter();
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> -
>  	call_firmware_op(prepare_idle);
>  
>  	/* Do suspend by ourselves if the firmware does not implement it */
>  	if (call_firmware_op(do_idle, 0) == -ENOSYS)
>  		cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>  
> -	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> -
>  	cpu_pm_exit();
>  	tegra_clear_cpu_in_lp2();
>  
> +	return index;
> +}
> +
> +static int tegra114_idle_enter(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	local_fiq_disable();
> +
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
> +
> +	index = tegra114_idle_power_down(dev, drv, index);
> +
> +	clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
> +
>  	local_fiq_enable();
>  
>  	return index;
>  }
> +
> +static void tegra114_idle_enter_freeze(struct cpuidle_device *dev,
> +				       struct cpuidle_driver *drv,
> +				       int index)
> +{
> +	tegra114_idle_power_down(dev, drv, index);

Cool. So if the problem is FIQs, you don't disabled them on entry
which means you enter the "frozen" state with FIQs enabled and tick frozen,
unless I am missing something.

The question here is: are we allowed to enable FIQs before returning
from an enter_freeze() call (and to enter it with FIQs enabled) ?

If we are not your code here certainly does not solve the issue, since
it does _not_ disable FIQs upon enter_freeze call anyway.

Lorenzo

> +}
>  #endif
>  
>  static struct cpuidle_driver tegra_idle_driver = {
> @@ -71,7 +87,8 @@ static struct cpuidle_driver tegra_idle_driver = {
>  		[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
>  #ifdef CONFIG_PM_SLEEP
>  		[1] = {
> -			.enter			= tegra114_idle_power_down,
> +			.enter			= tegra114_idle_enter,
> +			.enter_freeze		= tegra114_idle_enter_freeze,
>  			.exit_latency		= 500,
>  			.target_residency	= 1000,
>  			.power_usage		= 0,
> -- 
> 2.3.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

  reply	other threads:[~2015-04-08 11:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 10:54 [PATCH] ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze() Tomeu Vizoso
2015-04-08 10:54 ` Tomeu Vizoso
2015-04-08 11:55 ` Lorenzo Pieralisi [this message]
2015-04-08 11:55   ` Lorenzo Pieralisi
2015-04-09  9:18   ` Tomeu Vizoso
2015-04-09  9:18     ` Tomeu Vizoso
2015-04-09  9:18     ` Tomeu Vizoso
     [not found]     ` <552643E1.3060200-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2015-04-09 21:19       ` Rafael J. Wysocki
2015-04-09 21:19         ` Rafael J. Wysocki
2015-04-09 21:19         ` Rafael J. Wysocki
2015-04-10 10:08         ` Lorenzo Pieralisi
2015-04-10 10:08           ` Lorenzo Pieralisi
2015-04-16 14:37           ` Tomeu Vizoso
2015-04-16 14:37             ` Tomeu Vizoso
2015-04-17 14:08             ` Lorenzo Pieralisi
2015-04-17 14:08               ` Lorenzo Pieralisi
2015-04-17 15:02               ` Tomeu Vizoso
2015-04-17 15:02                 ` Tomeu Vizoso
     [not found]                 ` <CAAObsKATZy9+Tn0pJcDCaNzpxLX6GqX0TO_t7w8tgirWQgJF9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-28 15:07                   ` Tomeu Vizoso
2015-04-28 15:07                     ` Tomeu Vizoso
2015-04-28 15:07                     ` Tomeu Vizoso
2015-05-15  9:03               ` Tomeu Vizoso
2015-05-15  9:03                 ` Tomeu Vizoso
2015-05-15  9:03                 ` Tomeu Vizoso
2015-05-15 23:30                 ` Russell King - ARM Linux
2015-05-15 23:30                   ` Russell King - ARM Linux

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=20150408115546.GA24271@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=gnurou@gmail.com \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=rafael.j.wysocki@intel.com \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    --cc=tomeu.vizoso@collabora.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.