Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/09/2016 04:10 PM, Chanwoo Choi wrote: Hi, On 2016년 11월 10일 05:34, Saravana Kannan wrote: On 11/08/2016 06:38 PM, Chanwoo Choi wrote: On 2016년 11월 09일 11:36, Chanwoo Choi wrote: Hi, On 2016년 11월 09일 10:33, Chanwoo Choi wrote: On 2016년 11월 09일 05:52, Saravana Kannan wrote: On 11/08

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/09/2016 04:10 PM, Chanwoo Choi wrote: Hi, On 2016년 11월 10일 05:34, Saravana Kannan wrote: On 11/08/2016 06:38 PM, Chanwoo Choi wrote: On 2016년 11월 09일 11:36, Chanwoo Choi wrote: Hi, On 2016년 11월 09일 10:33, Chanwoo Choi wrote: On 2016년 11월 09일 05:52, Saravana Kannan wrote: On 11/08

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/08/2016 06:38 PM, Chanwoo Choi wrote: On 2016년 11월 09일 11:36, Chanwoo Choi wrote: Hi, On 2016년 11월 09일 10:33, Chanwoo Choi wrote: On 2016년 11월 09일 05:52, Saravana Kannan wrote: On 11/08/2016 01:02 AM, Chanwoo Choi wrote: Hi, On 2016년 11월 08일 03:57, Saravana Kannan wrote: On 10/26

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/08/2016 06:38 PM, Chanwoo Choi wrote: On 2016년 11월 09일 11:36, Chanwoo Choi wrote: Hi, On 2016년 11월 09일 10:33, Chanwoo Choi wrote: On 2016년 11월 09일 05:52, Saravana Kannan wrote: On 11/08/2016 01:02 AM, Chanwoo Choi wrote: Hi, On 2016년 11월 08일 03:57, Saravana Kannan wrote: On 10/26

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/08/2016 01:02 AM, Chanwoo Choi wrote: Hi, On 2016년 11월 08일 03:57, Saravana Kannan wrote: On 10/26/2016 05:06 PM, Chanwoo Choi wrote: Hi, On 2016년 10월 27일 04:17, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/08/2016 01:02 AM, Chanwoo Choi wrote: Hi, On 2016년 11월 08일 03:57, Saravana Kannan wrote: On 10/26/2016 05:06 PM, Chanwoo Choi wrote: Hi, On 2016년 10월 27일 04:17, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 10/26/2016 05:06 PM, Chanwoo Choi wrote: Hi, On 2016년 10월 27일 04:17, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- * Fi

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 10/26/2016 05:06 PM, Chanwoo Choi wrote: Hi, On 2016년 10월 27일 04:17, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan --- * Fix NULL deref for real this time

Re: [PATCH v2] PM / devfreq: Restart previous governor if new governor fails to start

On 10/26/2016 12:22 AM, Chanwoo Choi wrote: Hi, On 2016년 10월 26일 10:25, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- * Fixe

Re: [PATCH v2] PM / devfreq: Restart previous governor if new governor fails to start

On 10/26/2016 12:22 AM, Chanwoo Choi wrote: Hi, On 2016년 10월 26일 10:25, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan --- * Fixed typo in commit text * Fixed

[PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- * Fix NULL deref for real this time. * Addressed some style preferences. drivers/devfreq/devfreq.

[PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan --- * Fix NULL deref for real this time. * Addressed some style preferences. drivers/devfreq/devfreq.c | 13 +++-- 1 file changed

[PATCH v2] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- * Fixed typo in commit text * Fixed potential NULL deref drivers/devfreq/devfreq.c | 9 +++-- 1 file c

[PATCH v2] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left in some weird limbo. Signed-off-by: Saravana Kannan --- * Fixed typo in commit text * Fixed potential NULL deref drivers/devfreq/devfreq.c | 9 +++-- 1 file changed, 7 insertions(+), 2

[PATCH] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left if some weird limbo. Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- drivers/devfreq/devfreq.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/d

[PATCH] PM / devfreq: Restart previous governor if new governor fails to start

If the new governor fails to start, switch back to old governor so that the devfreq state is not left if some weird limbo. Signed-off-by: Saravana Kannan --- drivers/devfreq/devfreq.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/devfreq/devfreq.c b

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

On 04/06/2016 02:45 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 11:29 PM, Saravana Kannan <skan...@codeaurora.org> wrote: On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan <skan...@codeaurora.org> wrote: On 09/09/2015 05:5

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

On 04/06/2016 02:45 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 11:29 PM, Saravana Kannan wrote: On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan wrote: On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote: [cut] Well, nobody

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan <skan...@codeaurora.org> wrote: On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote: Hi, On Thu, Sep 10, 2015 at 2:39 AM, Viresh Kumar <viresh.ku...@linaro.org> wrote: On 10-09-15, 01:

Re: [PATCH 1/7] cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event

On 04/06/2016 02:21 PM, Rafael J. Wysocki wrote: On Wed, Apr 6, 2016 at 10:30 PM, Saravana Kannan wrote: On 09/09/2015 05:53 PM, Rafael J. Wysocki wrote: Hi, On Thu, Sep 10, 2015 at 2:39 AM, Viresh Kumar wrote: On 10-09-15, 01:26, Rafael J. Wysocki wrote: On Monday, August 03, 2015 08

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/07/2016 06:28 PM, Rafael J. Wysocki wrote: On Friday, February 05, 2016 06:22:35 PM Saravana Kannan wrote: On 02/04/2016 07:54 PM, Rafael J. Wysocki wrote: On Thursday, February 04, 2016 07:18:32 PM Rafael J. Wysocki wrote: On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan wrote: On 02

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/07/2016 06:28 PM, Rafael J. Wysocki wrote: On Friday, February 05, 2016 06:22:35 PM Saravana Kannan wrote: On 02/04/2016 07:54 PM, Rafael J. Wysocki wrote: On Thursday, February 04, 2016 07:18:32 PM Rafael J. Wysocki wrote: On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan <s

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/04/2016 07:54 PM, Rafael J. Wysocki wrote: On Thursday, February 04, 2016 07:18:32 PM Rafael J. Wysocki wrote: On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan wrote: On 02/04/2016 09:43 AM, Saravana Kannan wrote: On 02/04/2016 03:09 AM, Viresh Kumar wrote: On 04-02-16, 00:50, Rafael

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/04/2016 07:54 PM, Rafael J. Wysocki wrote: On Thursday, February 04, 2016 07:18:32 PM Rafael J. Wysocki wrote: On Thu, Feb 4, 2016 at 6:44 PM, Saravana Kannan <skan...@codeaurora.org> wrote: On 02/04/2016 09:43 AM, Saravana Kannan wrote: On 02/04/2016 03:09 AM, Viresh Kumar

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/04/2016 09:43 AM, Saravana Kannan wrote: On 02/04/2016 03:09 AM, Viresh Kumar wrote: On 04-02-16, 00:50, Rafael J. Wysocki wrote: This is exactly right. We've avoided one deadlock only to trip into another one. This happens because update_sampling_rate() acquires od_dbs_cdata.mutex

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/04/2016 03:09 AM, Viresh Kumar wrote: On 04-02-16, 00:50, Rafael J. Wysocki wrote: This is exactly right. We've avoided one deadlock only to trip into another one. This happens because update_sampling_rate() acquires od_dbs_cdata.mutex which is held around cpufreq_governor_exit() by

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/04/2016 09:43 AM, Saravana Kannan wrote: On 02/04/2016 03:09 AM, Viresh Kumar wrote: On 04-02-16, 00:50, Rafael J. Wysocki wrote: This is exactly right. We've avoided one deadlock only to trip into another one. This happens because update_sampling_rate() acquires od_dbs_cdata.mutex

Re: [PATCH V2 0/7] cpufreq: governors: Fix ABBA lockups

On 02/04/2016 03:09 AM, Viresh Kumar wrote: On 04-02-16, 00:50, Rafael J. Wysocki wrote: This is exactly right. We've avoided one deadlock only to trip into another one. This happens because update_sampling_rate() acquires od_dbs_cdata.mutex which is held around cpufreq_governor_exit() by

Re: [PATCH 7/11] cpufreq: governor: Rework cpufreq_governor_dbs()

*policy; -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Nice! Acked-by: Saravana Kannan -Saravana -- Qualcomm Innovation Center

Re: [PATCH 5/11] cpufreq: governor: Put governor structure into common_dbs_data

ATIVE); } MODULE_AUTHOR("Alexander Clouter "); @@ -395,7 +399,7 @@ MODULE_LICENSE("GPL"); #ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE struct cpufreq_governor *cpufreq_default_governor(void) { - return _gov_conservative; + return CPU_FREQ_GOV_CONSERV

Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

On 02/03/2016 05:11 PM, Saravana Kannan wrote: On 02/03/2016 03:22 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki If the ondemand and conservative governors cannot use per-policy tunables (CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not set in the cpufreq driver), all policy objects point

Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

On 02/03/2016 05:25 PM, Rafael J. Wysocki wrote: On Thu, Feb 4, 2016 at 2:11 AM, Saravana Kannan wrote: On 02/03/2016 03:22 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki If the ondemand and conservative governors cannot use per-policy tunables (CPUFREQ_HAVE_GOVERNOR_PER_POLICY

Re: [PATCH 4/11] cpufreq: governor: Avoid passing dbs_data pointers around unnecessarily

ah-to. return ret; } EXPORT_SYMBOL_GPL(cpufreq_governor_dbs); Agree with the general idea of the patch though. Conditional on the comment above being resolve amongst the others: Acked-by: Saravana Kannan -Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

ord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html If the minor comment is addressed, this looks okay to me. Cautiously Acked-by: Saravana Kannan -Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 2/11] cpufreq: governor: Use common mutex for dbs_data protection

.mutex = __MUTEX_INITIALIZER(cs_dbs_cdata.mutex), }; static int cs_cpufreq_governor_dbs(struct cpufreq_policy *policy, -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordo

Re: [PATCH 1/11] cpufreq: Clean up default and fallback governor setup

RSPACE +struct cpufreq_governor *cpufreq_default_governor(void) +{ + return _gov_userspace; +} + fs_initcall(cpufreq_gov_userspace_init); #else module_init(cpufreq_gov_userspace_init); -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to

Re: [PATCH V2 5/7] cpufreq: Merge cpufreq_offline_prepare/finish routines

On 02/03/2016 06:02 AM, Viresh Kumar wrote: The offline routine was separated into two halves earlier by 'commit 1aee40ac9c86 ("cpufreq: Invoke __cpufreq_remove_dev_finish() after releasing cpu_hotplug.lock");. And the reasons cited were, race issues between accessing policy's sysfs files and

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 10:54 PM, Viresh Kumar wrote: On 02-02-16, 17:32, Saravana Kannan wrote: But if we are expecting sched dvfs to come in, why make it worse for it. It would be completely pointless to try and shoehorn sched dvfs to use cpufreq_governor.c We can move the common part to cpufreq core

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 10:57 PM, Viresh Kumar wrote: On 02-02-16, 20:03, Saravana Kannan wrote: This is the hotplug case I mentioned. The sysfs file removals will happen only for the last CPU in that policy (we thankfully optimized that part last year). We also know that multiple CPUs can't

Re: [PATCH V2 5/7] cpufreq: Merge cpufreq_offline_prepare/finish routines

On 02/03/2016 06:02 AM, Viresh Kumar wrote: The offline routine was separated into two halves earlier by 'commit 1aee40ac9c86 ("cpufreq: Invoke __cpufreq_remove_dev_finish() after releasing cpu_hotplug.lock");. And the reasons cited were, race issues between accessing policy's sysfs files and

Re: [PATCH 1/11] cpufreq: Clean up default and fallback governor setup

cy gover MODULE_LICENSE("GPL"); #ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE +struct cpufreq_governor *cpufreq_default_governor(void) +{ + return _gov_userspace; +} + fs_initcall(cpufreq_gov_userspace_init); #else module_init(cpufreq_gov_userspace_init); -- To unsubscrib

Re: [PATCH 2/11] cpufreq: governor: Use common mutex for dbs_data protection

majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Acked-by: Saravana Kannan <skan...@codeaurora.org> -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 4/11] cpufreq: governor: Avoid passing dbs_data pointers around unnecessarily

- -unlock: mutex_unlock(_data_mutex); - Po-tay-to, Po-tah-to. return ret; } EXPORT_SYMBOL_GPL(cpufreq_governor_dbs); Agree with the general idea of the patch though. Conditional on the comment above being resolve amongst the others: Acked-by: Saravana Kannan <skan...@codea

Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

On 02/03/2016 05:11 PM, Saravana Kannan wrote: On 02/03/2016 03:22 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> If the ondemand and conservative governors cannot use per-policy tunables (CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not set in the cpufreq

Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

e "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html If the minor comment is addressed, this looks okay to me. Cautiously Acked-by: Saravana Kannan <skan...@codeaurora.org> -Saravana --

Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer

On 02/03/2016 05:25 PM, Rafael J. Wysocki wrote: On Thu, Feb 4, 2016 at 2:11 AM, Saravana Kannan <skan...@codeaurora.org> wrote: On 02/03/2016 03:22 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> If the ondemand and conservative governors ca

Re: [PATCH 7/11] cpufreq: governor: Rework cpufreq_governor_dbs()

t_powersave_bias(unsigned int powersave_bias) { struct cpufreq_policy *policy; -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Nice! Acked-b

Re: [PATCH 5/11] cpufreq: governor: Put governor structure into common_dbs_data

t cpufreq_governor *cpufreq_default_governor(void) { - return _gov_conservative; + return CPU_FREQ_GOV_CONSERVATIVE; } fs_initcall(cpufreq_gov_dbs_init); I'm not sold on the macros/#defines for the , but not a strong opinion. Acked-by: Saravana Kannan <skan...@codeaurora.org> -Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 10:57 PM, Viresh Kumar wrote: On 02-02-16, 20:03, Saravana Kannan wrote: This is the hotplug case I mentioned. The sysfs file removals will happen only for the last CPU in that policy (we thankfully optimized that part last year). We also know that multiple CPUs can't

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 10:54 PM, Viresh Kumar wrote: On 02-02-16, 17:32, Saravana Kannan wrote: But if we are expecting sched dvfs to come in, why make it worse for it. It would be completely pointless to try and shoehorn sched dvfs to use cpufreq_governor.c We can move the common part to cpufreq core

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/02/2016 09:02 PM, Viresh Kumar wrote: On 02-02-16, 20:04, Saravana Kannan wrote: What's the s_active lock in CPU1 coming from? That's taken by sysfs core while removing the files. The only reason it's there today is because of the sysfs dir remove. If you move it before the policy

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/02/2016 06:13 PM, Viresh Kumar wrote: On 02-02-16, 13:37, Saravana Kannan wrote: On 02/01/2016 10:34 PM, Viresh Kumar wrote: What will that solve? It will stay exactly same then as well, as we would be adding/removing these attributes from within the same policy->rwsem .. The prob

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 05:52 PM, Rafael J. Wysocki wrote: On Wed, Feb 3, 2016 at 2:32 AM, Saravana Kannan wrote: On 02/02/2016 05:07 PM, Rafael J. Wysocki wrote: On Wed, Feb 3, 2016 at 12:42 AM, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 11:21 PM, Saravana Kannan wrote: On 02/02/2016 11:40

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 05:07 PM, Rafael J. Wysocki wrote: On Wed, Feb 3, 2016 at 12:42 AM, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 11:21 PM, Saravana Kannan wrote: On 02/02/2016 11:40 AM, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 6:01 PM, Juri Lelli wrote: [cut] I also don't

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 11:40 AM, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 6:01 PM, Juri Lelli wrote: Hi Rafael, On 02/02/16 17:35, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 4:47 PM, Juri Lelli wrote: Hi Viresh, On 02/02/16 16:27, Viresh Kumar wrote: Until now, governors

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/01/2016 10:36 PM, Viresh Kumar wrote: On 01-02-16, 22:00, Rafael J. Wysocki wrote: I'm not sure what you mean by "the sysfs lock" here? The policy rwsem or something else? He perhaps referred to the s_active.lock that we see in traces. Yeah, that's what I mean. I generally don't use

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/01/2016 10:34 PM, Viresh Kumar wrote: On 01-02-16, 12:24, Saravana Kannan wrote: On 02/01/2016 02:22 AM, Rafael J. Wysocki wrote: I'm not sure whose idea you are referring to. Viresh's (I don't think I saw his proposal) or mine. http://git.linaro.org/people/viresh.kumar/linux.git/commit

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/01/2016 10:36 PM, Viresh Kumar wrote: On 01-02-16, 22:00, Rafael J. Wysocki wrote: I'm not sure what you mean by "the sysfs lock" here? The policy rwsem or something else? He perhaps referred to the s_active.lock that we see in traces. Yeah, that's what I mean. I generally don't use

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/01/2016 10:34 PM, Viresh Kumar wrote: On 01-02-16, 12:24, Saravana Kannan wrote: On 02/01/2016 02:22 AM, Rafael J. Wysocki wrote: I'm not sure whose idea you are referring to. Viresh's (I don't think I saw his proposal) or mine. http://git.linaro.org/people/viresh.kumar/linux.git/commit

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 11:40 AM, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 6:01 PM, Juri Lelli wrote: Hi Rafael, On 02/02/16 17:35, Rafael J. Wysocki wrote: On Tue, Feb 2, 2016 at 4:47 PM, Juri Lelli wrote: Hi Viresh, On 02/02/16 16:27, Viresh Kumar

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 05:07 PM, Rafael J. Wysocki wrote: On Wed, Feb 3, 2016 at 12:42 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: On Tue, Feb 2, 2016 at 11:21 PM, Saravana Kannan <skan...@codeaurora.org> wrote: On 02/02/2016 11:40 AM, Rafael J. Wysocki wrote: On Tue, Feb 2, 201

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/02/2016 09:02 PM, Viresh Kumar wrote: On 02-02-16, 20:04, Saravana Kannan wrote: What's the s_active lock in CPU1 coming from? That's taken by sysfs core while removing the files. The only reason it's there today is because of the sysfs dir remove. If you move it before the policy

Re: [PATCH 2/5] cpufreq: governor: Create separate sysfs-ops

On 02/02/2016 05:52 PM, Rafael J. Wysocki wrote: On Wed, Feb 3, 2016 at 2:32 AM, Saravana Kannan <skan...@codeaurora.org> wrote: On 02/02/2016 05:07 PM, Rafael J. Wysocki wrote: On Wed, Feb 3, 2016 at 12:42 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: On Tue, Feb 2, 2016

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/02/2016 06:13 PM, Viresh Kumar wrote: On 02-02-16, 13:37, Saravana Kannan wrote: On 02/01/2016 10:34 PM, Viresh Kumar wrote: What will that solve? It will stay exactly same then as well, as we would be adding/removing these attributes from within the same policy->rwsem .. The prob

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/01/2016 02:22 AM, Rafael J. Wysocki wrote: On Mon, Feb 1, 2016 at 7:09 AM, Viresh Kumar wrote: On 30-01-16, 12:49, Rafael J. Wysocki wrote: On Friday, January 29, 2016 04:33:39 PM Saravana Kannan wrote: AFAIR, the ABBA issue was between the sysfs lock and the policy lock. Yeah

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/01/2016 02:22 AM, Rafael J. Wysocki wrote: On Mon, Feb 1, 2016 at 7:09 AM, Viresh Kumar <viresh.ku...@linaro.org> wrote: On 30-01-16, 12:49, Rafael J. Wysocki wrote: On Friday, January 29, 2016 04:33:39 PM Saravana Kannan wrote: AFAIR, the ABBA issue was between the sysf

Re: [RFC PATCH 00/19] cpufreq locking cleanups and documentation

On 01/11/2016 09:35 AM, Juri Lelli wrote: Hi all, In the context of the ongoing discussion about introducing a simple platform energy model to guide scheduling decisions (Energy Aware Scheduling [1]) concerns have been expressed by Peter about the component in charge of driving clock frequency

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 01/12/2016 02:20 AM, Viresh Kumar wrote: On 11-01-16, 17:35, Juri Lelli wrote: __cpufreq_governor works on policy, so policy->rwsem has to be held. Add assertion for such condition. Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Signed-off-by: Juri Lelli --- drivers/cpufreq/cpufreq.c | 3 +++

Re: [RFC PATCH 00/19] cpufreq locking cleanups and documentation

On 01/11/2016 09:35 AM, Juri Lelli wrote: Hi all, In the context of the ongoing discussion about introducing a simple platform energy model to guide scheduling decisions (Energy Aware Scheduling [1]) concerns have been expressed by Peter about the component in charge of driving clock frequency

Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 01/12/2016 02:20 AM, Viresh Kumar wrote: On 11-01-16, 17:35, Juri Lelli wrote: __cpufreq_governor works on policy, so policy->rwsem has to be held. Add assertion for such condition. Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Signed-off-by: Juri

Re: [PATCH V3 5/5] cpufreq: postfix policy directory with the first CPU in related_cpus

in related-cpus mask. Suggested-by: Saravana Kannan Signed-off-by: Viresh Kumar --- V2->V3: - Fix error path where we may try to put an uninitialized kobject. - Break kobject_init_and_add() to kobject_init() and kobject_add(). drivers/cpufreq/cpufreq.c | 21 +++-- 1 f

Re: [PATCH V3 5/5] cpufreq: postfix policy directory with the first CPU in related_cpus

in related-cpus mask. Suggested-by: Saravana Kannan <skan...@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> --- V2->V3: - Fix error path where we may try to put an uninitialized kobject. - Break kobject_init_and_add() to kobject_init() and kobject_add().

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/14/2015 11:55 PM, Viresh Kumar wrote: On 13-10-15, 12:29, Saravana Kannan wrote: But we don't need to track track of "present-cpus" separately though. We could do the for_each_cpu_and() when we create the symlinks for the first time. And after that, we can just use the subsystem

Re: [PATCH V2 4/5] cpufreq: create cpu/cpufreq/policyX directories

kobj_cpu and we can remove it now. Suggested-by: Saravana Kannan Signed-off-by: Viresh Kumar Since you've added a separate patch for making policyX more consistent: Reviewed-by: Saravana Kannan Btw, does a Review-by have an implicit Acked-by? --- drivers/cpufreq/cpufreq.c | 34

Re: [PATCH V2 5/5] cpufreq: postfix policy directory with the first CPU in related_cpus

in related-cpus mask. Suggested-by: Saravana Kannan Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 4fa2215cc6ec..3fe13875565d 100644

Re: [PATCH V2 4/5] cpufreq: create cpu/cpufreq/policyX directories

kobj_cpu and we can remove it now. Suggested-by: Saravana Kannan <skan...@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> Since you've added a separate patch for making policyX more consistent: Reviewed-by: Saravana Kannan <skan...@codeaurora.org>

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/14/2015 11:55 PM, Viresh Kumar wrote: On 13-10-15, 12:29, Saravana Kannan wrote: But we don't need to track track of "present-cpus" separately though. We could do the for_each_cpu_and() when we create the symlinks for the first time. And after that, we can just use the subsystem

Re: [PATCH V2 5/5] cpufreq: postfix policy directory with the first CPU in related_cpus

in related-cpus mask. Suggested-by: Saravana Kannan <skan...@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> --- drivers/cpufreq/cpufreq.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/dri

Re: [PATCH Resend] cpufreq: Drop redundant check for inactive policies

On 10/14/2015 05:35 PM, Rafael J. Wysocki wrote: On Tuesday, October 13, 2015 10:57:13 AM Viresh Kumar wrote: We just made sure policy->cpu is online and this check will always fail as the policy is active. Drop it. Signed-off-by: Viresh Kumar Acked-by: Saravana Kannan Applied, tha

Re: [PATCH Resend] cpufreq: Drop redundant check for inactive policies

Saravana Kannan <skan...@codeaurora.org> Applied, thanks! Rafael I didn't give a clear ack/review for the series. So, to clarify my ack/review For all patches except 4/5, I'm okay with either/all of this: Reviewed-by: Saravana Kannan <skan...@codeaurora.org> Acked-by:

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/12/2015 08:39 PM, Viresh Kumar wrote: On 12-10-15, 12:31, Saravana Kannan wrote: Can we use the first CPU in the related CPUs mask? Instead of the first CPU that the policy got created on? The policyX numbering would be a bit more consistent that way. Okay.. Suggested-by: ? Will add

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/12/2015 11:15 PM, Viresh Kumar wrote: On 12-10-15, 12:31, Saravana Kannan wrote: Can we use the first CPU in the related CPUs mask? Instead of the first CPU that the policy got created on? The policyX numbering would be a bit more consistent that way. Okay, checked this again

Re: [PATCH 1/5] cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask

On 10/12/2015 08:23 PM, Viresh Kumar wrote: On 12-10-15, 12:12, Saravana Kannan wrote: if (new_policy) { /* related_cpus should at least include policy->cpus. */ - cpumask_or(policy->related_cpus, policy->related_cpus, pol

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/12/2015 08:39 PM, Viresh Kumar wrote: On 12-10-15, 12:31, Saravana Kannan wrote: Can we use the first CPU in the related CPUs mask? Instead of the first CPU that the policy got created on? The policyX numbering would be a bit more consistent that way. Okay.. Suggested-by: ? Will add

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/12/2015 11:15 PM, Viresh Kumar wrote: On 12-10-15, 12:31, Saravana Kannan wrote: Can we use the first CPU in the related CPUs mask? Instead of the first CPU that the policy got created on? The policyX numbering would be a bit more consistent that way. Okay, checked this again

Re: [PATCH 1/5] cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask

On 10/12/2015 08:23 PM, Viresh Kumar wrote: On 12-10-15, 12:12, Saravana Kannan wrote: if (new_policy) { /* related_cpus should at least include policy->cpus. */ - cpumask_or(policy->related_cpus, policy->related_cpus, pol

Re: [PATCH 5/5] cpufreq: Drop redundant check for inactive policies

ret = -EIO; -unlock_policy_rwsem: up_write(>rwsem); unlock: put_online_cpus(); Doesn't really seem related to the sysfs reorg/clean up. Should it be a separate patch outside of this series? Acked-by: Saravana Kannan -Saravana -- Qualcomm Innovation Center, Inc. The Qualcomm Innovat

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/11/2015 10:21 AM, Viresh Kumar wrote: The cpufreq sysfs interface had been a bit inconsistent as one of the CPUs for a policy had a real directory within its sysfs 'cpuX' directory and all other CPUs had links to it. That also made the code a bit complex as we need to take care of moving

Re: [PATCH 1/5] cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask

On 10/11/2015 10:21 AM, Viresh Kumar wrote: Signed-off-by: Viresh Kumar The commit text should explain the why you are doing this. --- drivers/cpufreq/cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index

Re: [PATCH 1/5] cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask

On 10/11/2015 10:21 AM, Viresh Kumar wrote: Signed-off-by: Viresh Kumar The commit text should explain the why you are doing this. --- drivers/cpufreq/cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/cpufreq.c

Re: [PATCH 5/5] cpufreq: Drop redundant check for inactive policies

unt); else ret = -EIO; -unlock_policy_rwsem: up_write(>rwsem); unlock: put_online_cpus(); Doesn't really seem related to the sysfs reorg/clean up. Should it be a separate patch outside of this series? Acked-by: Saravana Kannan <skan...@codeaurora.org> -Sarav

Re: [PATCH 4/5] cpufreq: create cpu/cpufreq/policyX directories

On 10/11/2015 10:21 AM, Viresh Kumar wrote: The cpufreq sysfs interface had been a bit inconsistent as one of the CPUs for a policy had a real directory within its sysfs 'cpuX' directory and all other CPUs had links to it. That also made the code a bit complex as we need to take care of moving

Re: [PATCH v2 RESEND/RFC] timer: make deferrable cpu unbound timers really not bound to a cpu

On 03/19/2015 05:10 PM, Saravana Kannan wrote: On 09/23/2014 11:33 AM, Thomas Gleixner wrote: On Mon, 15 Sep 2014, Joonwoo Park wrote: +#ifdef CONFIG_SMP +static struct tvec_base *tvec_base_deferral = _tvec_bases; +#endif In principle I like the idea of a deferrable wheel

Re: [PATCH v2 RESEND/RFC] timer: make deferrable cpu unbound timers really not bound to a cpu

On 03/19/2015 05:10 PM, Saravana Kannan wrote: On 09/23/2014 11:33 AM, Thomas Gleixner wrote: On Mon, 15 Sep 2014, Joonwoo Park wrote: +#ifdef CONFIG_SMP +static struct tvec_base *tvec_base_deferral = boot_tvec_bases; +#endif In principle I like the idea of a deferrable wheel

Re: Re: [PATCH v2 RESEND/RFC] timer: make deferrable cpu unbound timers really not bound to a cpu

On 09/23/2014 11:33 AM, Thomas Gleixner wrote: On Mon, 15 Sep 2014, Joonwoo Park wrote: +#ifdef CONFIG_SMP +static struct tvec_base *tvec_base_deferral = _tvec_bases; +#endif In principle I like the idea of a deferrable wheel, but this implementation is going to go nowhere. Hi Thomas, To

Re: Re: [PATCH v2 RESEND/RFC] timer: make deferrable cpu unbound timers really not bound to a cpu

On 09/23/2014 11:33 AM, Thomas Gleixner wrote: On Mon, 15 Sep 2014, Joonwoo Park wrote: +#ifdef CONFIG_SMP +static struct tvec_base *tvec_base_deferral = boot_tvec_bases; +#endif In principle I like the idea of a deferrable wheel, but this implementation is going to go nowhere. Hi Thomas,

Re: [PATCH 2/5] cpufreq, fix locking around CPUFREQ_GOV_POLICY_EXIT calls

On 11/11/2014 05:07 AM, Viresh Kumar wrote: On 11 November 2014 17:45, Prarit Bhargava wrote: the deadlock in commit 955ef4833574636819cd269cfbae12f79cbde63a [ 75.471265]CPU0CPU1 [ 75.476327] [ 75.481385] lock(>rwsem); [

Re: [PATCH 2/5] cpufreq, fix locking around CPUFREQ_GOV_POLICY_EXIT calls

On 11/11/2014 05:07 AM, Viresh Kumar wrote: On 11 November 2014 17:45, Prarit Bhargava pra...@redhat.com wrote: the deadlock in commit 955ef4833574636819cd269cfbae12f79cbde63a [ 75.471265]CPU0CPU1 [ 75.476327] [ 75.481385]

Re: [PATCH v4 0/5] Simplify hotplug/suspend handling

On 10/16/2014 01:53 AM, Viresh Kumar wrote: On 25 July 2014 06:37, Saravana Kannan wrote: Series of patchs to simplify policy/sysfs/kobj/locking handling across suspend/resume The following have been tested so far on a 2x2 cluster environment: - Boot with 2 cpus and no cpufreq driver. - mod

Re: [PATCH v4 0/5] Simplify hotplug/suspend handling

On 10/16/2014 01:53 AM, Viresh Kumar wrote: On 25 July 2014 06:37, Saravana Kannan skan...@codeaurora.org wrote: Series of patchs to simplify policy/sysfs/kobj/locking handling across suspend/resume The following have been tested so far on a 2x2 cluster environment: - Boot with 2 cpus

<    5   6   7   8   9   10   11   12   13   >