On Thursday, September 04, 2014 04:07:28 PM Viresh Kumar wrote:
> On 4 September 2014 15:33, Preeti U Murthy wrote:
> > I think Rafael's point was that since no driver that had implemented the
> > target_index callback was using it at the time that this patch was
> > proposed, it was be best to
On 4 September 2014 15:33, Preeti U Murthy wrote:
> I think Rafael's point was that since no driver that had implemented the
> target_index callback was using it at the time that this patch was
> proposed, it was be best to couple the check on existence of stop_cpu
> callback with the the check
On 09/04/2014 02:46 PM, Viresh Kumar wrote:
> On 4 September 2014 14:40, Preeti U Murthy wrote:
>> cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
>>
>> Commit 367dc4aa introduced the stop CPU callback for intel_pstate
>> drivers. During the CPU_DOWN_PREPARE stage, this
On 4 September 2014 14:40, Preeti U Murthy wrote:
> cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
>
> Commit 367dc4aa introduced the stop CPU callback for intel_pstate
> drivers. During the CPU_DOWN_PREPARE stage, this callback is invoked
> so that drivers can take some
Hi,
I went through the cpufreq code and the previous discussion in the
context of this patch and I propose the below patch. Please let me know
if it misses something that you all had discussed.
On 09/04/2014 11:38 AM, Viresh Kumar wrote:
> On 19 March 2014 19:49, Rafael J. Wysocki wrote:
>
>>
On 19 March 2014 19:49, Rafael J. Wysocki wrote:
> That said, for the intel_pstate case ->stop() as proposed by Dirk is
> demonstrably
> sufficient and there are no other ->setpolicy drivers in sight wanting or
> needing
> anything else.
>
> So to me, (1) the new ->stop() should *only* be
On Thursday, September 04, 2014 04:07:28 PM Viresh Kumar wrote:
On 4 September 2014 15:33, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
I think Rafael's point was that since no driver that had implemented the
target_index callback was using it at the time that this patch was
proposed,
On 19 March 2014 19:49, Rafael J. Wysocki r...@rjwysocki.net wrote:
That said, for the intel_pstate case -stop() as proposed by Dirk is
demonstrably
sufficient and there are no other -setpolicy drivers in sight wanting or
needing
anything else.
So to me, (1) the new -stop() should *only*
Hi,
I went through the cpufreq code and the previous discussion in the
context of this patch and I propose the below patch. Please let me know
if it misses something that you all had discussed.
On 09/04/2014 11:38 AM, Viresh Kumar wrote:
On 19 March 2014 19:49, Rafael J. Wysocki
On 4 September 2014 14:40, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
Commit 367dc4aa introduced the stop CPU callback for intel_pstate
drivers. During the CPU_DOWN_PREPARE stage, this callback is invoked
so that drivers
On 09/04/2014 02:46 PM, Viresh Kumar wrote:
On 4 September 2014 14:40, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
Commit 367dc4aa introduced the stop CPU callback for intel_pstate
drivers. During the CPU_DOWN_PREPARE
On 4 September 2014 15:33, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
I think Rafael's point was that since no driver that had implemented the
target_index callback was using it at the time that this patch was
proposed, it was be best to couple the check on existence of stop_cpu
callback
On Wednesday, March 19, 2014 03:30:48 PM Srivatsa S. Bhat wrote:
> On 03/19/2014 10:33 AM, Viresh Kumar wrote:
> > On 18 March 2014 17:46, Srivatsa S. Bhat
> > wrote:
> >> Agreed. As far as I understand, for ->target drivers, today we use GOV_STOP
> >> to stop managing the CPU going offline. And
On 03/19/2014 10:33 AM, Viresh Kumar wrote:
> On 18 March 2014 17:46, Srivatsa S. Bhat
> wrote:
>> Agreed. As far as I understand, for ->target drivers, today we use GOV_STOP
>> to stop managing the CPU going offline. And for ->setpolicy drivers, we will
>> use this new callback to achieve the
On 03/19/2014 10:33 AM, Viresh Kumar wrote:
On 18 March 2014 17:46, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Agreed. As far as I understand, for -target drivers, today we use GOV_STOP
to stop managing the CPU going offline. And for -setpolicy drivers, we will
use this new
On Wednesday, March 19, 2014 03:30:48 PM Srivatsa S. Bhat wrote:
On 03/19/2014 10:33 AM, Viresh Kumar wrote:
On 18 March 2014 17:46, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Agreed. As far as I understand, for -target drivers, today we use GOV_STOP
to stop managing the CPU
On 18 March 2014 17:46, Srivatsa S. Bhat
wrote:
> Agreed. As far as I understand, for ->target drivers, today we use GOV_STOP
> to stop managing the CPU going offline. And for ->setpolicy drivers, we will
> use this new callback to achieve the same goal.
So a better question would be: What's the
On 03/15/2014 07:29 AM, Rafael J. Wysocki wrote:
> On Friday, March 14, 2014 11:29:04 AM Dirk Brandewie wrote:
>> On 03/14/2014 10:07 AM, Viresh Kumar wrote:
>>> On 14 March 2014 20:40, Dirk Brandewie wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can not
find
On 03/15/2014 07:29 AM, Rafael J. Wysocki wrote:
On Friday, March 14, 2014 11:29:04 AM Dirk Brandewie wrote:
On 03/14/2014 10:07 AM, Viresh Kumar wrote:
On 14 March 2014 20:40, Dirk Brandewie dirk.brande...@gmail.com wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can
On 18 March 2014 17:46, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Agreed. As far as I understand, for -target drivers, today we use GOV_STOP
to stop managing the CPU going offline. And for -setpolicy drivers, we will
use this new callback to achieve the same goal.
So a better
On Sat, Mar 15, 2014 at 7:29 AM, Rafael J. Wysocki wrote:
> I honestly don't think that ->target drivers will ever do anything like it,
> because they need the governor to "exit" before. So we are talking about the
> only two ->setpolicy drivers in the tree here.
I don't have a example platform
Hi,
It was a long weekend in India due to some holidays and so couldn't reply.
On Fri, Mar 14, 2014 at 11:59 PM, Dirk Brandewie
wrote:
> On 03/14/2014 10:07 AM, Viresh Kumar wrote:
> Suspend and hotplug are two very different things and if we start
> crossing those wires bad things are going to
Hi,
It was a long weekend in India due to some holidays and so couldn't reply.
On Fri, Mar 14, 2014 at 11:59 PM, Dirk Brandewie
dirk.brande...@gmail.com wrote:
On 03/14/2014 10:07 AM, Viresh Kumar wrote:
Suspend and hotplug are two very different things and if we start
crossing those wires
On Sat, Mar 15, 2014 at 7:29 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
I honestly don't think that -target drivers will ever do anything like it,
because they need the governor to exit before. So we are talking about the
only two -setpolicy drivers in the tree here.
I don't have a
On Friday, March 14, 2014 11:29:04 AM Dirk Brandewie wrote:
> On 03/14/2014 10:07 AM, Viresh Kumar wrote:
> > On 14 March 2014 20:40, Dirk Brandewie wrote:
> >> Are you proposing adding cpufreq_generic_suspend() to the core I can not
> >> find
> >> it in the mainline code.
> >
> > Its already
On 03/14/2014 10:07 AM, Viresh Kumar wrote:
On 14 March 2014 20:40, Dirk Brandewie wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can not
find
it in the mainline code.
Its already there in linux-next. I am suggesting to reuse that
infrastructure with
some necessary
On 14 March 2014 20:40, Dirk Brandewie wrote:
> Are you proposing adding cpufreq_generic_suspend() to the core I can not
> find
> it in the mainline code.
Its already there in linux-next. I am suggesting to reuse that
infrastructure with
some necessary modification to support both suspend and
On 03/13/2014 09:59 PM, Viresh Kumar wrote:
On Thu, Mar 13, 2014 at 11:06 PM, wrote:
From: Dirk Brandewie
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The ->exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline process
On 03/13/2014 09:59 PM, Viresh Kumar wrote:
On Thu, Mar 13, 2014 at 11:06 PM, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.j.brande...@intel.com
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The -exit() callback is executed during
On 14 March 2014 20:40, Dirk Brandewie dirk.brande...@gmail.com wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can not
find
it in the mainline code.
Its already there in linux-next. I am suggesting to reuse that
infrastructure with
some necessary modification to
On 03/14/2014 10:07 AM, Viresh Kumar wrote:
On 14 March 2014 20:40, Dirk Brandewie dirk.brande...@gmail.com wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can not
find
it in the mainline code.
Its already there in linux-next. I am suggesting to reuse that
On Friday, March 14, 2014 11:29:04 AM Dirk Brandewie wrote:
On 03/14/2014 10:07 AM, Viresh Kumar wrote:
On 14 March 2014 20:40, Dirk Brandewie dirk.brande...@gmail.com wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can not
find
it in the mainline code.
Its
On Thu, Mar 13, 2014 at 11:06 PM, wrote:
> From: Dirk Brandewie
>
> Some drivers (intel_pstate) need to modify state on a core before it
> is completely offline. The ->exit() callback is executed during the
> CPU_POST_DEAD phase of the cpu offline process which is too late to
> change the
From: Dirk Brandewie
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The ->exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline process which is too late to
change the state of the core.
Patch 1 adds an optional callback
From: Dirk Brandewie dirk.j.brande...@intel.com
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The -exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline process which is too late to
change the state of the core.
Patch 1 adds
On Thu, Mar 13, 2014 at 11:06 PM, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie dirk.j.brande...@intel.com
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The -exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline
36 matches
Mail list logo
