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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
*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
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
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
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
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
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
.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
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
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
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
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
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
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
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
-
-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
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
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
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 +++
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
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
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
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().
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
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
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
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>
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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);
[
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]
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
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
901 - 1000 of 1232 matches
Mail list logo