On 03/03/15 15:29, Viresh Kumar wrote:
> On 3 March 2015 at 20:39, Kapileshwar Singh wrote:
>
>> I did test this but we were working with the assumption that OPPs should be
>> populated for all the CPUs and also that OPPs are lost for a hotplugged CPU
>> which I see is not the case.
>
>
On 03/03/15 15:30, Viresh Kumar wrote:
On 3 March 2015 at 20:56, Sudeep Holla wrote:
You can use any_online_cpu(..) instead of cpumask_any IMO
What about policy->cpu ? :)
We can, was not sure if they have access to policy in their thermal
driver. Just the first thought seeing one line
On 3 March 2015 at 20:56, Sudeep Holla wrote:
> You can use any_online_cpu(..) instead of cpumask_any IMO
What about policy->cpu ? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Mar 3, 2015 at 3:09 PM, Kapileshwar Singh
wrote:
> On 03/03/15 13:07, Viresh Kumar wrote:
[...]
>> Please goto the depth of this thing, as I don't think it should happen.
>>
>> Over that I was asking you if you have tested the solution Javi gave,
>> because OPPs
>> wouldn't have been
On 3 March 2015 at 20:39, Kapileshwar Singh wrote:
> I did test this but we were working with the assumption that OPPs should be
> populated for all the CPUs and also that OPPs are lost for a hotplugged CPU
> which I see is not the case.
Then what did you test? My point here is, even with the
On 03/03/15 13:07, Viresh Kumar wrote:
> On 3 March 2015 at 17:11, Kapileshwar Singh wrote:
>> Yes I indeed tested the case where we cache the device pointer of the CPU
>> for which the OPP's are populated.
>> When this CPU is hotplugged out, it invalidates the device pointer itself.
>> Here
On 3 March 2015 at 17:11, Kapileshwar Singh wrote:
> Yes I indeed tested the case where we cache the device pointer of the CPU for
> which the OPP's are populated.
> When this CPU is hotplugged out, it invalidates the device pointer itself.
> Here are the error we get in dmesg:
What do you
On 03/03/15 11:19, Viresh Kumar wrote:
> On 3 March 2015 at 16:29, Kapileshwar Singh wrote:
>> We store the device pointer of the lead CPU (policy CPU) in a cpufreq domain
>> as a part of the
>> cpufreq_cooling_device data structure. There is one cpufreq_cooling_device
>> per
>> cpufreq
On 3 March 2015 at 16:29, Kapileshwar Singh wrote:
> We store the device pointer of the lead CPU (policy CPU) in a cpufreq domain
> as a part of the
> cpufreq_cooling_device data structure. There is one cpufreq_cooling_device per
> cpufreq domain.
>
> We need the device to find out the current
Hi Viresh!
On 03/03/15 04:03, Viresh Kumar wrote:
> On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino wrote:
>> From: Kapileshwar Singh
>>
>> When cpufreq changes the policy cpu, we need to update our cached cpu
>> device accordingly.
>>
>> Cc: Zhang Rui
>> Cc: Eduardo Valentin
>> Signed-off-by:
On 03/03/15 13:07, Viresh Kumar wrote:
On 3 March 2015 at 17:11, Kapileshwar Singh kapileshwar.si...@arm.com wrote:
Yes I indeed tested the case where we cache the device pointer of the CPU
for which the OPP's are populated.
When this CPU is hotplugged out, it invalidates the device pointer
On 03/03/15 15:30, Viresh Kumar wrote:
On 3 March 2015 at 20:56, Sudeep Holla sudeep.ho...@arm.com wrote:
You can use any_online_cpu(..) instead of cpumask_any IMO
What about policy-cpu ? :)
We can, was not sure if they have access to policy in their thermal
driver. Just the first
On 03/03/15 15:29, Viresh Kumar wrote:
On 3 March 2015 at 20:39, Kapileshwar Singh kapileshwar.si...@arm.com wrote:
I did test this but we were working with the assumption that OPPs should be
populated for all the CPUs and also that OPPs are lost for a hotplugged CPU
which I see is not
On 3 March 2015 at 20:56, Sudeep Holla sudeep.ho...@arm.com wrote:
You can use any_online_cpu(..) instead of cpumask_any IMO
What about policy-cpu ? :)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On 3 March 2015 at 20:39, Kapileshwar Singh kapileshwar.si...@arm.com wrote:
I did test this but we were working with the assumption that OPPs should be
populated for all the CPUs and also that OPPs are lost for a hotplugged CPU
which I see is not the case.
Then what did you test? My point
On Tue, Mar 3, 2015 at 3:09 PM, Kapileshwar Singh
kapileshwar.si...@arm.com wrote:
On 03/03/15 13:07, Viresh Kumar wrote:
[...]
Please goto the depth of this thing, as I don't think it should happen.
Over that I was asking you if you have tested the solution Javi gave,
because OPPs
Hi Viresh!
On 03/03/15 04:03, Viresh Kumar wrote:
On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino javi.mer...@arm.com wrote:
From: Kapileshwar Singh kapileshwar.si...@arm.com
When cpufreq changes the policy cpu, we need to update our cached cpu
device accordingly.
Cc: Zhang Rui
On 3 March 2015 at 17:11, Kapileshwar Singh kapileshwar.si...@arm.com wrote:
Yes I indeed tested the case where we cache the device pointer of the CPU for
which the OPP's are populated.
When this CPU is hotplugged out, it invalidates the device pointer itself.
Here are the error we get in
On 3 March 2015 at 16:29, Kapileshwar Singh kapileshwar.si...@arm.com wrote:
We store the device pointer of the lead CPU (policy CPU) in a cpufreq domain
as a part of the
cpufreq_cooling_device data structure. There is one cpufreq_cooling_device per
cpufreq domain.
We need the device to
On 03/03/15 11:19, Viresh Kumar wrote:
On 3 March 2015 at 16:29, Kapileshwar Singh kapileshwar.si...@arm.com wrote:
We store the device pointer of the lead CPU (policy CPU) in a cpufreq domain
as a part of the
cpufreq_cooling_device data structure. There is one cpufreq_cooling_device
per
On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino wrote:
> From: Kapileshwar Singh
>
> When cpufreq changes the policy cpu, we need to update our cached cpu
> device accordingly.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Kapileshwar Singh
> ---
> drivers/thermal/cpu_cooling.c | 3
From: Kapileshwar Singh
When cpufreq changes the policy cpu, we need to update our cached cpu
device accordingly.
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Kapileshwar Singh
---
drivers/thermal/cpu_cooling.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino javi.mer...@arm.com wrote:
From: Kapileshwar Singh kapileshwar.si...@arm.com
When cpufreq changes the policy cpu, we need to update our cached cpu
device accordingly.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
From: Kapileshwar Singh kapileshwar.si...@arm.com
When cpufreq changes the policy cpu, we need to update our cached cpu
device accordingly.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Kapileshwar Singh kapileshwar.si...@arm.com
---
24 matches
Mail list logo
