On 02/25/2014 10:02 PM, Viresh Kumar wrote:
On 26 February 2014 07:18, Saravana Kannan wrote:
On 02/25/2014 02:41 PM, Rafael J. Wysocki wrote:
And is "fully initialized" actually well defined?
The point in add dev/hot plug path after which we will no longer change
policy fields without sen
On 26 February 2014 07:18, Saravana Kannan wrote:
> On 02/25/2014 02:41 PM, Rafael J. Wysocki wrote:
>> And is "fully initialized" actually well defined?
>
> The point in add dev/hot plug path after which we will no longer change
> policy fields without sending further CPUFREQ_UPDATE_POLICY_CPU /
On 26 February 2014 02:41, Saravana Kannan wrote:
> On 02/25/2014 05:04 AM, Rafael J. Wysocki wrote:
>> On Tuesday, February 25, 2014 02:20:57 PM Viresh Kumar wrote:
> I think there's been a misunderstanding of what I'm proposing. The reference
> to policy->clk is only to get rid of the dependenc
On 02/25/2014 02:41 PM, Rafael J. Wysocki wrote:
On Tuesday, February 25, 2014 01:11:27 PM Saravana Kannan wrote:
On 02/25/2014 05:04 AM, Rafael J. Wysocki wrote:
On Tuesday, February 25, 2014 02:20:57 PM Viresh Kumar wrote:
On 25 February 2014 01:53, Saravana Kannan wrote:
I was simplifying
On Tuesday, February 25, 2014 01:11:27 PM Saravana Kannan wrote:
> On 02/25/2014 05:04 AM, Rafael J. Wysocki wrote:
> > On Tuesday, February 25, 2014 02:20:57 PM Viresh Kumar wrote:
> >> On 25 February 2014 01:53, Saravana Kannan wrote:
> >>> I was simplifying the scenario that causes it. We chang
On 02/25/2014 05:04 AM, Rafael J. Wysocki wrote:
On Tuesday, February 25, 2014 02:20:57 PM Viresh Kumar wrote:
On 25 February 2014 01:53, Saravana Kannan wrote:
I was simplifying the scenario that causes it. We change the min/max using
ADJUST notifiers for multiple reasons -- thermal being one
On 25 February 2014 18:34, Rafael J. Wysocki wrote:
> Well, that depends on what the current users expect it to look like initially.
> It should be initialized to the point in which all of them can handle it
> correctly.
Exactly.
> That's not going to work in at least some cases anyway, because
On Tuesday, February 25, 2014 02:20:57 PM Viresh Kumar wrote:
> On 25 February 2014 01:53, Saravana Kannan wrote:
> > I was simplifying the scenario that causes it. We change the min/max using
> > ADJUST notifiers for multiple reasons -- thermal being one of them.
> >
> > thermal/cpu_cooling is on
On 25 February 2014 01:53, Saravana Kannan wrote:
> I was simplifying the scenario that causes it. We change the min/max using
> ADJUST notifiers for multiple reasons -- thermal being one of them.
>
> thermal/cpu_cooling is one example of it.
Just to understand the clear picture, you are actually
On 02/24/2014 02:55 AM, Viresh Kumar wrote:
On 24 February 2014 14:09, wrote:
Srivatsa S. Bhat wrote:
On 02/24/2014 12:27 PM, Saravana Kannan wrote:
The existing code sets the per CPU policy to a non-NULL value before all
the steps performed during the hotplug online path is done.
Specifica
On 24 February 2014 14:09, wrote:
>
> Srivatsa S. Bhat wrote:
>> On 02/24/2014 12:27 PM, Saravana Kannan wrote:
>>> The existing code sets the per CPU policy to a non-NULL value before all
>>> the steps performed during the hotplug online path is done.
>>> Specifically,
>>> this is done before th
Viresh Kumar wrote:
> On 24 February 2014 14:17, wrote:
>> Sorry, not sure I understand what you mean.
>>
>> I agree, wording in my commit text might be unclear. I'll fix it after
>> we
>> agree on the code fix. In the MSM case, each CPU has it's own policy.
>>
>> I'm assuming your original comp
On 24 February 2014 14:17, wrote:
> Sorry, not sure I understand what you mean.
>
> I agree, wording in my commit text might be unclear. I'll fix it after we
> agree on the code fix. In the MSM case, each CPU has it's own policy.
>
> I'm assuming your original complaint was about my confusing wor
Viresh Kumar wrote:
> On 24 February 2014 14:11, wrote:
>> I just replied to the other email. I think I answered both your
>> questions
>> there. Sorry about mixing up CPU and policy. In my case, each CPU is
>> independently scalable -- so for now take CPU == policy. I'll fix it up
>> once we ag
On 24 February 2014 14:11, wrote:
> I just replied to the other email. I think I answered both your questions
> there. Sorry about mixing up CPU and policy. In my case, each CPU is
> independently scalable -- so for now take CPU == policy. I'll fix it up
> once we agree on the fix.
But why do yo
Viresh Kumar wrote:
> On 24 February 2014 13:12, Srivatsa S. Bhat
> wrote:
>> On 02/24/2014 12:27 PM, Saravana Kannan wrote:
>>> The existing code sets the per CPU policy to a non-NULL value before
>>> all
>>> the steps performed during the hotplug online path is done.
>>> Specifically,
>>> this
Srivatsa S. Bhat wrote:
> On 02/24/2014 12:27 PM, Saravana Kannan wrote:
>> The existing code sets the per CPU policy to a non-NULL value before all
>> the steps performed during the hotplug online path is done.
>> Specifically,
>> this is done before the policy min/max, governors, etc are initial
On 24 February 2014 13:12, Srivatsa S. Bhat
wrote:
> On 02/24/2014 12:27 PM, Saravana Kannan wrote:
>> The existing code sets the per CPU policy to a non-NULL value before all
>> the steps performed during the hotplug online path is done. Specifically,
>> this is done before the policy min/max, go
On 02/24/2014 12:27 PM, Saravana Kannan wrote:
> The existing code sets the per CPU policy to a non-NULL value before all
> the steps performed during the hotplug online path is done. Specifically,
> this is done before the policy min/max, governors, etc are initialized for
> the policy. This in t
The existing code sets the per CPU policy to a non-NULL value before all
the steps performed during the hotplug online path is done. Specifically,
this is done before the policy min/max, governors, etc are initialized for
the policy. This in turn means that calls to cpufreq_cpu_get() return a
non-
20 matches
Mail list logo
