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 co
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
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 callback
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 action
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:
>
>> T
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 calle
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 f
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 sam
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 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
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 ther
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 mo
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 hot
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 w
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 state
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 funct
18 matches
Mail list logo
