On 07/16/2014 11:14 AM, Viresh Kumar wrote:
> On 15 July 2014 12:28, Srivatsa S. Bhat wrote:
>> Wait, allowing an offline CPU to be the policy->cpu (i.e., the CPU which is
>> considered as the master of the policy/group) is just absurd.
>
> Yeah, that was as Absurd as I am :)
>
I have had my ow
On 07/15/2014 11:05 PM, skan...@codeaurora.org wrote:
>
> Srivatsa S. Bhat wrote:
>> On 07/15/2014 11:06 AM, Saravana Kannan wrote:
>>> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan wrote:
> Yeah, it definitely crashes if policy->cpu if an offline cpu
On 15 July 2014 12:28, Srivatsa S. Bhat wrote:
> Wait, allowing an offline CPU to be the policy->cpu (i.e., the CPU which is
> considered as the master of the policy/group) is just absurd.
Yeah, that was as Absurd as I am :)
> The goal of this patchset should be to just de-couple the sysfs
> fi
Srivatsa S. Bhat wrote:
> On 07/15/2014 11:06 AM, Saravana Kannan wrote:
>> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
>>> On 15 July 2014 00:38, Saravana Kannan wrote:
Yeah, it definitely crashes if policy->cpu if an offline cpu. Because
the
mutex would be uninitialized if it's s
On 07/15/2014 11:06 AM, Saravana Kannan wrote:
> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
>> On 15 July 2014 00:38, Saravana Kannan wrote:
>>> Yeah, it definitely crashes if policy->cpu if an offline cpu. Because
>>> the
>>> mutex would be uninitialized if it's stopped after boot or it would
>>
On 15 July 2014 11:06, Saravana Kannan wrote:
> Btw, I tried to take a stab at removing any assumption in cpufreq code about
> policy->cpu being ONLINE. There are 160 instances of those of with 23 are in
> cpufreq.c
>
> So, even if we are sure cpufreq.c is fine, it's 137 other uses spread across
>
On 07/14/2014 09:35 PM, Viresh Kumar wrote:
On 15 July 2014 00:38, Saravana Kannan wrote:
Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the
mutex would be uninitialized if it's stopped after boot or it would never
have been initialized (depending on how you fix policy->c
On 15 July 2014 00:38, Saravana Kannan wrote:
> Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the
> mutex would be uninitialized if it's stopped after boot or it would never
> have been initialized (depending on how you fix policy->cpu at boot).
>
> Look at this snippet on
On 07/13/2014 11:13 PM, Viresh Kumar wrote:
On 12 July 2014 08:36, Saravana Kannan wrote:
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code. Does cpufreq_unregiste
On 07/13/2014 11:09 PM, Viresh Kumar wrote:
On 12 July 2014 08:14, Saravana Kannan wrote:
I'm just always adding the real nodes to the first CPU in a cluster
independent of which CPU gets added first. Makes it easier to know which
ones to symlink. See comment next to policy->cpu for full conte
On 12 July 2014 08:36, Saravana Kannan wrote:
> On 07/10/2014 11:19 PM, Viresh Kumar wrote:
>
>>
>> Please make sure you take care of these issues:
>> - suspend/resume
>> - hotplug
>> - module insert/remove
>
> Ok, I was just at the current code. Does cpufreq_unregister_driver() even
> really work
On 12 July 2014 08:14, Saravana Kannan wrote:
>>> I'm just always adding the real nodes to the first CPU in a cluster
>>> independent of which CPU gets added first. Makes it easier to know which
>>> ones to symlink. See comment next to policy->cpu for full context.
>>
>>
>> Yeah, and that is the
On 07/10/2014 11:19 PM, Viresh Kumar wrote:
Please make sure you take care of these issues:
- suspend/resume
- hotplug
- module insert/remove
Ok, I was just at the current code. Does cpufreq_unregister_driver()
even really work correctly as it stands?
It doesn't even seem to stop any of the
On 07/11/2014 03:52 AM, Viresh Kumar wrote:
Just responding to one comment. The one about policy->cpu.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
{
- unsigned int j;
+ unsigned int j,
On 11 July 2014 15:29, wrote:
> Viresh Kumar wrote:
>> On 11 July 2014 09:48, Saravana Kannan wrote:
>>> * Policy settings and governor tunables maintained across suspend/resume
>>> and hotplug.
>>
>> Its already maintained during suspend/resume.
>
> But not across hotplug. Which is also very
skan...@codeaurora.org wrote:
>
> Viresh Kumar wrote:
>> Hi Saravana,
>>
>> Thanks for trying this..
>>
>> On 11 July 2014 09:48, Saravana Kannan wrote:
>>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
>>
>> s/driver/core
>
> Will do
>
S many typos. This is what
Srivatsa S. Bhat wrote:
> On 07/11/2014 09:48 AM, Saravana Kannan wrote:
>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
>> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
>> moving policy ownership between CPUs, it also moves the cpufreq sysfs
>
Viresh Kumar wrote:
> Hi Saravana,
>
> Thanks for trying this..
>
> On 11 July 2014 09:48, Saravana Kannan wrote:
>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
>
> s/driver/core
Will do
>
>> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
>>
On 07/11/2014 09:48 AM, Saravana Kannan wrote:
> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
> moving policy ownership between CPUs, it also moves the cpufreq sysfs
> directory between CPUs and al
Hi Saravana,
Thanks for trying this..
On 11 July 2014 09:48, Saravana Kannan wrote:
> The CPUfreq driver moves the cpufreq policy ownership between CPUs when
s/driver/core
> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
> moving policy ownership between CPUs, it also
The CPUfreq driver moves the cpufreq policy ownership between CPUs when
CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When
moving policy ownership between CPUs, it also moves the cpufreq sysfs
directory between CPUs and also fixes up the symlinks of the other CPUs in
the clust
21 matches
Mail list logo
