From: Kapileshwar Singh <kapileshwar.singh@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Javi Merino <Javi.Merino@arm.com>
Cc: Eduardo Valentin <edubezval@gmail.com>,
Zhang Rui <rui.zhang@intel.com>,
Linux PM list <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Punit Agrawal <Punit.Agrawal@arm.com>,
Lina Iyer <lina.iyer@linaro.org>, Mark Brown <broonie@kernel.org>,
Jon Medhurst <tixy@linaro.org>
Subject: Re: [PATCH v3 5/5] thermal: cpu_cooling: update the cpu device when cpufreq updates the policy cpu
Date: Tue, 03 Mar 2015 10:59:43 +0000 [thread overview]
Message-ID: <54F5941F.6030402@arm.com> (raw)
In-Reply-To: <CAOh2x=m9c-gOYcesgh+4oc9NucFdD1y0Mcit5gPwLxGFt__Lng@mail.gmail.com>
Hi Viresh!
On 03/03/15 04:03, Viresh Kumar wrote:
> On Mon, Mar 2, 2015 at 10:47 PM, Javi Merino <javi.merino@arm.com> wrote:
>> From: Kapileshwar Singh <kapileshwar.singh@arm.com>
>>
>> When cpufreq changes the policy cpu, we need to update our cached cpu
>> device accordingly.
>>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: Eduardo Valentin <edubezval@gmail.com>
>> Signed-off-by: Kapileshwar Singh <kapileshwar.singh@arm.com>
>> ---
>> drivers/thermal/cpu_cooling.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index c4974144c787..e306d6bc3cf1 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -269,6 +269,9 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb,
>> mutex_unlock(&cooling_cpufreq_lock);
>> break;
>>
>> + case CPUFREQ_UPDATE_POLICY_CPU:
>> + update_cpu_device(policy->cpu);
>> + break;
>> case CPUFREQ_CREATE_POLICY:
>> update_cpu_device(policy->cpu);
>> break;
>
> First of all, I wasn't able to find 3/5 on LKML and I looked at 3/7
> from an earlier
> version to look at how update_cpu_device() looks like.
>
> What I couldn't understand is why do you need to update things if policy->cpu
> is changing ?
>
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 OPP for the cpufreq_cooling_device for our static power calculation.
opp = opp_find_freq_exact(cpu_dev, freq_hz, true);
voltage = dev_pm_opp_get_voltage(opp);
The problem we are trying to solve here is:
When this lead CPU gets hotplugged out, the device pointer becomes stale and the policy
cpu for the cpufreq domain changes. We then store the new policy CPU's device pointer for the
in cpufreq_cooling_device on the reception of a notification from cpufreq. Being open to your
suggestions for any other possible ways to solve the problem..
Regards,
KP
> I am expecting a detailed answer here according to your design, and we may
> be able to work out without such updates. Lets see..
>
next prev parent reply other threads:[~2015-03-03 10:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 17:17 [PATCH v3 0/5] Subject: The power allocator thermal governor Javi Merino
2015-03-02 17:17 ` [PATCH v3 1/5] thermal: introduce the Power Allocator governor Javi Merino
2015-03-02 17:17 ` [PATCH v3 2/5] thermal: add trace events to the power allocator governor Javi Merino
2017-03-15 4:26 ` Viresh Kumar
2015-03-02 17:17 ` [PATCH v3 3/5] thermal: export thermal_zone_parameters to sysfs Javi Merino
2015-03-02 17:17 ` [PATCH v3 4/5] Revert "cpufreq: remove CPUFREQ_UPDATE_POLICY_CPU notifications" Javi Merino
2015-03-02 17:17 ` [PATCH v3 5/5] thermal: cpu_cooling: update the cpu device when cpufreq updates the policy cpu Javi Merino
2015-03-03 4:03 ` Viresh Kumar
2015-03-03 10:59 ` Kapileshwar Singh [this message]
2015-03-03 11:19 ` Viresh Kumar
2015-03-03 11:41 ` Kapileshwar Singh
2015-03-03 13:07 ` Viresh Kumar
2015-03-03 15:09 ` Kapileshwar Singh
2015-03-03 15:26 ` Sudeep Holla
2015-03-03 15:30 ` Viresh Kumar
2015-03-03 15:33 ` Sudeep Holla
2015-03-03 15:29 ` Viresh Kumar
2015-03-03 15:34 ` Kapileshwar Singh
2015-03-02 17:28 ` [PATCH v3 0/5] Subject: The power allocator thermal governor Eduardo Valentin
2015-03-02 17:40 ` Javi Merino
2015-03-02 18:47 ` Eduardo Valentin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F5941F.6030402@arm.com \
--to=kapileshwar.singh@arm.com \
--cc=Javi.Merino@arm.com \
--cc=Punit.Agrawal@arm.com \
--cc=broonie@kernel.org \
--cc=edubezval@gmail.com \
--cc=lina.iyer@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=tixy@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox