On 07/16/2013 03:05 PM, Viresh Kumar wrote:
> On 16 July 2013 14:59, Srivatsa S. Bhat
> wrote:
>> On 07/16/2013 02:40 PM, Viresh Kumar wrote:
>
>>> So, even if you don't keep the fallback storage, things should work
>>> without any issue (probably worth trying as this will get rid of a per
>>>
On 16 July 2013 14:59, Srivatsa S. Bhat
wrote:
> On 07/16/2013 02:40 PM, Viresh Kumar wrote:
>> So, even if you don't keep the fallback storage, things should work
>> without any issue (probably worth trying as this will get rid of a per
>> cpu variable :))
>>
>
> No, I already tried that and it
On 07/16/2013 02:40 PM, Viresh Kumar wrote:
> On 16 July 2013 14:26, Srivatsa S. Bhat
> wrote:
>> On 07/16/2013 11:45 AM, Viresh Kumar wrote:
>
>>> To understand it I actually applied your patches to get better view of the
>>> code.
>>> (Haven't tested it though).. And found that your code is
On 16 July 2013 14:26, Srivatsa S. Bhat
wrote:
> On 07/16/2013 11:45 AM, Viresh Kumar wrote:
>> To understand it I actually applied your patches to get better view of the
>> code.
>> (Haven't tested it though).. And found that your code is doing the right
>> thing
>> and we shouldn't get a
On 07/16/2013 11:45 AM, Viresh Kumar wrote:
> On 15 July 2013 15:35, Srivatsa S. Bhat
> wrote:
>> Actually even I was wondering about this while writing the patch and
>> I even tested shutdown after multiple suspend/resume cycles, to verify that
>> the refcount is messed up. But surprisingly,
On 15 July 2013 15:35, Srivatsa S. Bhat
wrote:
> Actually even I was wondering about this while writing the patch and
> I even tested shutdown after multiple suspend/resume cycles, to verify that
> the refcount is messed up. But surprisingly, things worked just fine.
>
> Logically there should've
On 15 July 2013 15:35, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Actually even I was wondering about this while writing the patch and
I even tested shutdown after multiple suspend/resume cycles, to verify that
the refcount is messed up. But surprisingly, things worked just fine.
On 07/16/2013 11:45 AM, Viresh Kumar wrote:
On 15 July 2013 15:35, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Actually even I was wondering about this while writing the patch and
I even tested shutdown after multiple suspend/resume cycles, to verify that
the refcount is messed
On 16 July 2013 14:26, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 07/16/2013 11:45 AM, Viresh Kumar wrote:
To understand it I actually applied your patches to get better view of the
code.
(Haven't tested it though).. And found that your code is doing the right
thing
and
On 07/16/2013 02:40 PM, Viresh Kumar wrote:
On 16 July 2013 14:26, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 07/16/2013 11:45 AM, Viresh Kumar wrote:
To understand it I actually applied your patches to get better view of the
code.
(Haven't tested it though).. And found
On 16 July 2013 14:59, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 07/16/2013 02:40 PM, Viresh Kumar wrote:
So, even if you don't keep the fallback storage, things should work
without any issue (probably worth trying as this will get rid of a per
cpu variable :))
No, I
On 07/16/2013 03:05 PM, Viresh Kumar wrote:
On 16 July 2013 14:59, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 07/16/2013 02:40 PM, Viresh Kumar wrote:
So, even if you don't keep the fallback storage, things should work
without any issue (probably worth trying as this will
On 07/15/2013 05:05 PM, Rafael J. Wysocki wrote:
> On Monday, July 15, 2013 03:35:04 PM Srivatsa S. Bhat wrote:
>> On 07/15/2013 03:25 PM, Viresh Kumar wrote:
>>> Hi Srivatsa,
>>>
>>> I may be wrong but it looks something is wrong in this patch.
>>>
>>> On 12 July 2013 03:47, Srivatsa S. Bhat
>>>
On 07/15/2013 03:51 PM, Viresh Kumar wrote:
> On 15 July 2013 15:35, Srivatsa S. Bhat
> wrote:
>> Actually even I was wondering about this while writing the patch and
>> I even tested shutdown after multiple suspend/resume cycles, to verify that
>> the refcount is messed up. But surprisingly,
On Monday, July 15, 2013 03:35:04 PM Srivatsa S. Bhat wrote:
> On 07/15/2013 03:25 PM, Viresh Kumar wrote:
> > Hi Srivatsa,
> >
> > I may be wrong but it looks something is wrong in this patch.
> >
> > On 12 July 2013 03:47, Srivatsa S. Bhat
> > wrote:
> >> diff --git
On 15 July 2013 15:35, Srivatsa S. Bhat
wrote:
> Actually even I was wondering about this while writing the patch and
> I even tested shutdown after multiple suspend/resume cycles, to verify that
> the refcount is messed up. But surprisingly, things worked just fine.
What kind of system have you
On 07/15/2013 03:25 PM, Viresh Kumar wrote:
> Hi Srivatsa,
>
> I may be wrong but it looks something is wrong in this patch.
>
> On 12 July 2013 03:47, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>
>> @@ -1239,29 +1263,40 @@ static int
Hi Srivatsa,
I may be wrong but it looks something is wrong in this patch.
On 12 July 2013 03:47, Srivatsa S. Bhat
wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> @@ -1239,29 +1263,40 @@ static int __cpufreq_remove_dev(struct device *dev,
> if ((cpus == 1)
Hi Srivatsa,
I may be wrong but it looks something is wrong in this patch.
On 12 July 2013 03:47, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
@@ -1239,29 +1263,40 @@ static int __cpufreq_remove_dev(struct device
On 07/15/2013 03:25 PM, Viresh Kumar wrote:
Hi Srivatsa,
I may be wrong but it looks something is wrong in this patch.
On 12 July 2013 03:47, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
@@ -1239,29 +1263,40
On 15 July 2013 15:35, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Actually even I was wondering about this while writing the patch and
I even tested shutdown after multiple suspend/resume cycles, to verify that
the refcount is messed up. But surprisingly, things worked just fine.
On Monday, July 15, 2013 03:35:04 PM Srivatsa S. Bhat wrote:
On 07/15/2013 03:25 PM, Viresh Kumar wrote:
Hi Srivatsa,
I may be wrong but it looks something is wrong in this patch.
On 12 July 2013 03:47, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
diff --git
On 07/15/2013 03:51 PM, Viresh Kumar wrote:
On 15 July 2013 15:35, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Actually even I was wondering about this while writing the patch and
I even tested shutdown after multiple suspend/resume cycles, to verify that
the refcount is messed
On 07/15/2013 05:05 PM, Rafael J. Wysocki wrote:
On Monday, July 15, 2013 03:35:04 PM Srivatsa S. Bhat wrote:
On 07/15/2013 03:25 PM, Viresh Kumar wrote:
Hi Srivatsa,
I may be wrong but it looks something is wrong in this patch.
On 12 July 2013 03:47, Srivatsa S. Bhat
To perform light-weight cpu-init and teardown in the cpufreq subsystem
during suspend/resume, we need to separate out the 2 main functionalities
of the cpufreq CPU hotplug callbacks, as outlined below:
1. Init/tear-down of core cpufreq and CPU-specific components, which are
critical to the
To perform light-weight cpu-init and teardown in the cpufreq subsystem
during suspend/resume, we need to separate out the 2 main functionalities
of the cpufreq CPU hotplug callbacks, as outlined below:
1. Init/tear-down of core cpufreq and CPU-specific components, which are
critical to the
26 matches
Mail list logo
