From: Pan Xinhui <xinhuix.pan@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-pm@vger.kernel.org, "mnipxh@163.com" <mnipxh@163.com>,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>
Subject: Re: [PATCH V2] acpi-cpufreq: replace per_cpu with driver_data of policy
Date: Thu, 09 Jul 2015 09:28:30 +0800 [thread overview]
Message-ID: <559DCE3E.8050105@intel.com> (raw)
In-Reply-To: <12074796.mAD950pclu@vostro.rjw.lan>
hi, Rafael
thanks for your kind reply. :)
On 2015年07月09日 08:20, Rafael J. Wysocki wrote:
> On Tuesday, July 07, 2015 08:04:43 PM Viresh Kumar wrote:
>> On 07-07-15, 20:43, Pan Xinhui wrote:
>>>
>>> Drivers can store their internal per-policy information in
>>> policy->driver_data, lets use it.
>>>
>>> we have benefits after this replacing.
>>> 1) memory saving.
>>> 2) policy is shared by several cpus, per_cpu seems not correct. using
>>> *driver_data* is more reasonable.
>>> 3) fix a memory leak in acpi_cpufreq_cpu_exit. as policy->cpu might
>>> change during cpu hotplug. So sometimes we cant't free *data*, use
>>> *driver_data* to fix it.
>>> 4) fix a zero return value of get_cur_freq_on_cpu. Only per_cpu of
>>> policy->cpu is set to *data*, if we try to get cpufreq on other cpus, we
>>> get zero instead of correct values. Use *driver_data* to fix it.
>>>
>>> Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
>>> ---
>>> Changes from V1:
>>> codes style fix, comments update
>>> move cpufreq_cpu_put(policy) after we get *driver_data*
>>> ---
>>> drivers/cpufreq/acpi-cpufreq.c | 40 ++++++++++++++++++++++------------------
>>> 1 file changed, 22 insertions(+), 18 deletions(-)
>>
>> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> OK
>
> Does it fix any recent regressions or is it just an old bug?
>
This patch achieve old bug fix and codes improvements. In past days, policy has no field *driver_data*, So
acpi-cpufreq driver has to use per_cpu to store some extra information. But it did not take good care of every scenarios.
Now cpufreq core makes awesome effort to store more per-policy information in policy. We can make use of this feature. So I
cook this patch. :)
I am preparing two patches for other two issues in acpi-cpufreq driver based on this patch.
I will fix them step by step. :)
thanks
xinhui
> Rafael
>
next prev parent reply other threads:[~2015-07-09 1:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 12:43 [PATCH V2] acpi-cpufreq: replace per_cpu with driver_data of policy Pan Xinhui
2015-07-07 12:49 ` Pan Xinhui
2015-07-07 14:34 ` Viresh Kumar
2015-07-09 0:20 ` Rafael J. Wysocki
2015-07-09 1:28 ` Pan Xinhui [this message]
2015-07-10 1:16 ` Rafael J. Wysocki
2015-07-07 17:11 ` Dmitry Torokhov
2015-07-08 4:51 ` Viresh Kumar
2015-07-08 12:28 ` Pan Xinhui
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=559DCE3E.8050105@intel.com \
--to=xinhuix.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mnipxh@163.com \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
--cc=yanmin_zhang@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).