linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] cpufreq: tegra: don't error target() when suspended
@ 2013-11-20 21:06 Stephen Warren
  2013-11-21  0:33 ` Rafael J. Wysocki
  2013-11-21  3:44 ` Viresh Kumar
  0 siblings, 2 replies; 5+ messages in thread
From: Stephen Warren @ 2013-11-20 21:06 UTC (permalink / raw)
  To: Rafael J. Wysocki, Viresh Kumar
  Cc: cpufreq-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, Stephen Warren

From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core"
added code to the cpufreq core to print an error if a cpufreq driver's
.target() function returned an error. This exposed the fact that Tegra's
cpufreq driver returns an error when it is ignoring requests due to the
system being suspended.

Modify Tegra's .target() function not to return an error in this case;
this prevents the error prints. The argument is that since the suspend
hook can't and doesn't inform the cpufreq core when its requests will
be ignored, there's no way for the cpufreq core to squelch them, so it's
not an error for the requests to keep coming. This change make the Tegra
driver consistent with how the Exynos handles the same situation. Note
that s5pv210-cpufreq.c probably suffers from this same issue though.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
This is a fix for 3.13.

Commit d4019f0a92ab also failed to update the Tegra pm_notifier hook to
emit cpufreq notifications. That hook calls the target() implementation
directly, which used to emit the notifications. However, now that the
notifications are made outside of target(), they no longer occur when
target() is called directly. I'm not sure if this is an issue or not?
---
 drivers/cpufreq/tegra-cpufreq.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index f42df7ec03c5..b7309c37033d 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -142,10 +142,8 @@ static int tegra_target(struct cpufreq_policy *policy, unsigned int index)
 
 	mutex_lock(&tegra_cpu_lock);
 
-	if (is_suspended) {
-		ret = -EBUSY;
+	if (is_suspended)
 		goto out;
-	}
 
 	freq = freq_table[index].frequency;
 
-- 
1.8.1.5

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] cpufreq: tegra: don't error target() when suspended
  2013-11-20 21:06 [PATCH] cpufreq: tegra: don't error target() when suspended Stephen Warren
@ 2013-11-21  0:33 ` Rafael J. Wysocki
  2013-11-21  3:44 ` Viresh Kumar
  1 sibling, 0 replies; 5+ messages in thread
From: Rafael J. Wysocki @ 2013-11-21  0:33 UTC (permalink / raw)
  To: Stephen Warren
  Cc: Viresh Kumar, cpufreq, linux-pm, linux-tegra, Stephen Warren

On Wednesday, November 20, 2013 02:06:22 PM Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core"
> added code to the cpufreq core to print an error if a cpufreq driver's
> .target() function returned an error. This exposed the fact that Tegra's
> cpufreq driver returns an error when it is ignoring requests due to the
> system being suspended.
> 
> Modify Tegra's .target() function not to return an error in this case;
> this prevents the error prints. The argument is that since the suspend
> hook can't and doesn't inform the cpufreq core when its requests will
> be ignored, there's no way for the cpufreq core to squelch them, so it's
> not an error for the requests to keep coming. This change make the Tegra
> driver consistent with how the Exynos handles the same situation. Note
> that s5pv210-cpufreq.c probably suffers from this same issue though.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Queued up for the next PM pull request, thanks!

> ---
> This is a fix for 3.13.
> 
> Commit d4019f0a92ab also failed to update the Tegra pm_notifier hook to
> emit cpufreq notifications. That hook calls the target() implementation
> directly, which used to emit the notifications. However, now that the
> notifications are made outside of target(), they no longer occur when
> target() is called directly. I'm not sure if this is an issue or not?
> ---
>  drivers/cpufreq/tegra-cpufreq.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
> index f42df7ec03c5..b7309c37033d 100644
> --- a/drivers/cpufreq/tegra-cpufreq.c
> +++ b/drivers/cpufreq/tegra-cpufreq.c
> @@ -142,10 +142,8 @@ static int tegra_target(struct cpufreq_policy *policy, unsigned int index)
>  
>  	mutex_lock(&tegra_cpu_lock);
>  
> -	if (is_suspended) {
> -		ret = -EBUSY;
> +	if (is_suspended)
>  		goto out;
> -	}
>  
>  	freq = freq_table[index].frequency;
>  
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] cpufreq: tegra: don't error target() when suspended
  2013-11-20 21:06 [PATCH] cpufreq: tegra: don't error target() when suspended Stephen Warren
  2013-11-21  0:33 ` Rafael J. Wysocki
@ 2013-11-21  3:44 ` Viresh Kumar
  2013-11-21 18:41   ` Stephen Warren
  1 sibling, 1 reply; 5+ messages in thread
From: Viresh Kumar @ 2013-11-21  3:44 UTC (permalink / raw)
  To: Stephen Warren
  Cc: Rafael J. Wysocki, cpufreq@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-tegra, Stephen Warren

On 21 November 2013 02:36, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core"
> added code to the cpufreq core to print an error if a cpufreq driver's
> .target() function returned an error. This exposed the fact that Tegra's
> cpufreq driver returns an error when it is ignoring requests due to the
> system being suspended.
>
> Modify Tegra's .target() function not to return an error in this case;
> this prevents the error prints. The argument is that since the suspend
> hook can't and doesn't inform the cpufreq core when its requests will
> be ignored, there's no way for the cpufreq core to squelch them, so it's
> not an error for the requests to keep coming. This change make the Tegra
> driver consistent with how the Exynos handles the same situation. Note
> that s5pv210-cpufreq.c probably suffers from this same issue though.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Thanks..

> ---
> This is a fix for 3.13.
>
> Commit d4019f0a92ab also failed to update the Tegra pm_notifier hook to
> emit cpufreq notifications. That hook calls the target() implementation
> directly, which used to emit the notifications. However, now that the
> notifications are made outside of target(), they no longer occur when
> target() is called directly. I'm not sure if this is an issue or not?

Hmm.. Yes and no.. Frequency after this point will not be in sync with
cpufreq core, but at the same time after resume cpufreq core will check
this out and get the correct frequency..

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] cpufreq: tegra: don't error target() when suspended
  2013-11-21  3:44 ` Viresh Kumar
@ 2013-11-21 18:41   ` Stephen Warren
       [not found]     ` <528E53C5.9040105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Warren @ 2013-11-21 18:41 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: Rafael J. Wysocki, cpufreq@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-tegra, Stephen Warren

On 11/20/2013 08:44 PM, Viresh Kumar wrote:
> On 21 November 2013 02:36, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> d4019f0a92ab "cpufreq: move freq change notifications to cpufreq core"
>> added code to the cpufreq core to print an error if a cpufreq driver's
>> .target() function returned an error. This exposed the fact that Tegra's
>> cpufreq driver returns an error when it is ignoring requests due to the
>> system being suspended.
>>
>> Modify Tegra's .target() function not to return an error in this case;
>> this prevents the error prints. The argument is that since the suspend
>> hook can't and doesn't inform the cpufreq core when its requests will
>> be ignored, there's no way for the cpufreq core to squelch them, so it's
>> not an error for the requests to keep coming. This change make the Tegra
>> driver consistent with how the Exynos handles the same situation. Note
>> that s5pv210-cpufreq.c probably suffers from this same issue though.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> 
> Thanks..
> 
>> ---
>> This is a fix for 3.13.
>>
>> Commit d4019f0a92ab also failed to update the Tegra pm_notifier hook to
>> emit cpufreq notifications. That hook calls the target() implementation
>> directly, which used to emit the notifications. However, now that the
>> notifications are made outside of target(), they no longer occur when
>> target() is called directly. I'm not sure if this is an issue or not?
> 
> Hmm.. Yes and no.. Frequency after this point will not be in sync with
> cpufreq core, but at the same time after resume cpufreq core will check
> this out and get the correct frequency..

OK, sounds like I should ignore this issue then?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] cpufreq: tegra: don't error target() when suspended
       [not found]     ` <528E53C5.9040105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
@ 2013-11-22  4:59       ` viresh kumar
  0 siblings, 0 replies; 5+ messages in thread
From: viresh kumar @ 2013-11-22  4:59 UTC (permalink / raw)
  To: Stephen Warren
  Cc: Rafael J. Wysocki,
	cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, Stephen Warren

On Friday 22 November 2013 12:11 AM, Stephen Warren wrote:
> OK, sounds like I should ignore this issue then?

Yeah. And actually we are looking for a more generic solution instead of these
per-driver PM notifiers. So, these should be removed soon..


https://lkml.org/lkml/2013/11/15/107^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-11-22  4:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-20 21:06 [PATCH] cpufreq: tegra: don't error target() when suspended Stephen Warren
2013-11-21  0:33 ` Rafael J. Wysocki
2013-11-21  3:44 ` Viresh Kumar
2013-11-21 18:41   ` Stephen Warren
     [not found]     ` <528E53C5.9040105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-22  4:59       ` viresh kumar

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).