On 27 November 2013 12:38, Lan Tianyu wrote:
> Hi Viresh:
Hey Lan,
> First, I agree the new solution you are working on. :)
Thanks :)
> But actually I don't totally agree my origin patch have design issue.
> Because I think governor should have the ability to check whether it has
>
On 2013年11月27日 11:07, Viresh Kumar wrote:
> On 27 November 2013 07:12, Rafael J. Wysocki wrote:
>> Anyway, if you did what I asked you to do and put the cpufreq suspend/resume
>> into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However,
>> since you've decided to put those
On 27 November 2013 01:53, Rafael J. Wysocki wrote:
> On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
>> On 26 November 2013 04:59, Rafael J. Wysocki wrote:
>> > This appears to be racy. Is it really racy, or just seemingly?
>>
>> Why does it look racy to you? Userspace should be
On 27 November 2013 07:12, Rafael J. Wysocki wrote:
> Anyway, if you did what I asked you to do and put the cpufreq suspend/resume
> into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However,
> since you've decided to put those things somewhere else thus making the
> change much
On Tuesday, November 26, 2013 09:23:15 PM Rafael J. Wysocki wrote:
> On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
> > On 26 November 2013 04:59, Rafael J. Wysocki wrote:
> > >> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> > >>
> > >> might_sleep();
> > >>
> >
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
> On 26 November 2013 04:59, Rafael J. Wysocki wrote:
> >> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> >>
> >> might_sleep();
> >>
> >> + cpufreq_suspend();
> >> +
> >>
> >> mutex_lock(_list_mtx);
> >>
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
@@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
might_sleep();
+ cpufreq_suspend();
+
mutex_lock(dpm_list_mtx);
On Tuesday, November 26, 2013 09:23:15 PM Rafael J. Wysocki wrote:
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
@@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
might_sleep();
+
On 27 November 2013 07:12, Rafael J. Wysocki r...@rjwysocki.net wrote:
Anyway, if you did what I asked you to do and put the cpufreq suspend/resume
into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However,
since you've decided to put those things somewhere else thus making the
On 27 November 2013 01:53, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
This appears to be racy. Is it really racy, or just seemingly?
Why does it look racy
On 2013年11月27日 11:07, Viresh Kumar wrote:
On 27 November 2013 07:12, Rafael J. Wysocki r...@rjwysocki.net wrote:
Anyway, if you did what I asked you to do and put the cpufreq suspend/resume
into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However,
since you've decided to put
On 27 November 2013 12:38, Lan Tianyu tianyu@intel.com wrote:
Hi Viresh:
Hey Lan,
First, I agree the new solution you are working on. :)
Thanks :)
But actually I don't totally agree my origin patch have design issue.
Because I think governor should have the ability to check
On Monday 25 November 2013 07:41 PM, Viresh Kumar wrote:
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index dc196bb..6d93f91 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -255,6 +255,9 @@ struct cpufreq_driver {
> int
On 26 November 2013 04:59, Rafael J. Wysocki wrote:
>> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
>>
>> might_sleep();
>>
>> + cpufreq_suspend();
>> +
>>
>> mutex_lock(_list_mtx);
>> pm_transition = state;
>> async_error = 0;
>
> Shouldn't it do
On Monday, November 25, 2013 07:41:41 PM Viresh Kumar wrote:
>
> This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
> suspend/resume of cpufreq governors. This is required for early suspend and
> late resume of governors and cpufreq core.
>
> There are multiple problems
This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors. This is required for early suspend and late
resume of governors and cpufreq core.
There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting
This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors. This is required for early suspend and late
resume of governors and cpufreq core.
There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting
On Monday, November 25, 2013 07:41:41 PM Viresh Kumar wrote:
This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors. This is required for early suspend and
late resume of governors and cpufreq core.
There are multiple problems that are
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net wrote:
@@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
might_sleep();
+ cpufreq_suspend();
+
mutex_lock(dpm_list_mtx);
pm_transition = state;
async_error = 0;
Shouldn't it do
On Monday 25 November 2013 07:41 PM, Viresh Kumar wrote:
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index dc196bb..6d93f91 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -255,6 +255,9 @@ struct cpufreq_driver {
int cpufreq_register_driver(struct
20 matches
Mail list logo
