From: Radivoje Jovanovic <radivoje.jovanovic@linux.intel.com>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Zhang Rui <rui.zhang@intel.com>,
Eduardo Valentin <edubezval@gmail.com>,
Radivoje Jovanovic <radivoje.jovanovic@intel.com>
Subject: Re: [PATCH] thermal/cpu_cooling: remove local cooling state variable
Date: Fri, 24 Jul 2015 10:09:05 -0700 [thread overview]
Message-ID: <20150724100905.7e2e53f4@radivoje-desk2> (raw)
In-Reply-To: <9hhegjxbmqz.fsf@e105922-lin.cambridge.arm.com>
Hi Agarwal,
On Fri, 24 Jul 2015 16:26:12 +0100
Punit Agrawal <punit.agrawal@arm.com> wrote:
> Radivoje Jovanovic <radivoje.jovanovic@linux.intel.com> writes:
>
> > From: Radivoje Jovanovic <radivoje.jovanovic@intel.com>
> >
> > there is no need to keep local state variable. if another driver
> > changes the policy under our feet the cpu_cooling driver will
> > have the wrong state. Get current state from the policy directly
> > instead
> >
>
> Although the patch below looks good, it does add additional
> processing. I was wondering in what situation do you observe the
> problem $SUBJECT solves?
>
> Presumably, the policy caps are tighter than those imposed by the cpu
> cooling device (cpufreq_thermal_notifier should take care of this).
we are using this solution on the platfrom which has user space
component control cpufreq throttling. However, user space
component has its limitations so we are using cpu_cooling as a
critical backup. Due to this cpu_cooling does not have correct state
as a current state so when the change is needed cpu_cooling does
not make the change since it believes it is in the "correct" state.
I agree that there is slight increase in processing, but in the case
when user space is changing the policy the notifier will not have
access to the current state of the cpu_cooling to change it
appropriately.
>
> > Signed-off-by: Radivoje Jovanovic <radivoje.jovanovic@intel.com>
> > ---
> > drivers/thermal/cpu_cooling.c | 27 ++++++++++++++++++---------
> > 1 file changed, 18 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/thermal/cpu_cooling.c
> > b/drivers/thermal/cpu_cooling.c index 6509c61..94ba2da 100644
> > --- a/drivers/thermal/cpu_cooling.c
> > +++ b/drivers/thermal/cpu_cooling.c
> > @@ -66,8 +66,6 @@ struct power_table {
> > * registered.
> > * @cool_dev: thermal_cooling_device pointer to keep track of the
> > * registered cooling device.
> > - * @cpufreq_state: integer value representing the current state of
> > cpufreq
> > - * cooling devices.
> > * @cpufreq_val: integer value representing the absolute value of
> > the clipped
> > * frequency.
> > * @max_level: maximum cooling level. One less than total number
> > of valid @@ -90,7 +88,6 @@ struct power_table {
> > struct cpufreq_cooling_device {
> > int id;
> > struct thermal_cooling_device *cool_dev;
> > - unsigned int cpufreq_state;
> > unsigned int cpufreq_val;
> > unsigned int max_level;
> > unsigned int *freq_table; /* In descending order */
> > @@ -486,10 +483,19 @@ static int cpufreq_get_cur_state(struct
> > thermal_cooling_device *cdev, unsigned long *state)
> > {
> > struct cpufreq_cooling_device *cpufreq_device =
> > cdev->devdata; -
> > - *state = cpufreq_device->cpufreq_state;
> > -
> > - return 0;
> > + struct cpufreq_policy policy;
> > + struct cpumask *mask = &cpufreq_device->allowed_cpus;
> > + unsigned int cpu = cpumask_any(mask);
> > + unsigned int cur_state;
> > +
> > + if (!cpufreq_get_policy(&policy, cpu)) {
> > + cur_state = get_level(cpufreq_device,
> > policy.max);
> > + if (cur_state != THERMAL_CSTATE_INVALID) {
> > + *state = cur_state;
> > + return 0;
> > + }
> > + }
> > + return -EINVAL;
> > }
> >
> > /**
> > @@ -508,17 +514,20 @@ static int cpufreq_set_cur_state(struct
> > thermal_cooling_device *cdev, struct cpufreq_cooling_device
> > *cpufreq_device = cdev->devdata; unsigned int cpu =
> > cpumask_any(&cpufreq_device->allowed_cpus); unsigned int clip_freq;
> > + unsigned long cur_state;
> >
> > /* Request state should be less than max_level */
> > if (WARN_ON(state > cpufreq_device->max_level))
> > return -EINVAL;
> >
> > + if (cpufreq_get_cur_state(cpufreq_device->cool_dev,
> > &cur_state))
> > + return -EINVAL;
> > +
> > /* Check if the old cooling action is same as new cooling
> > action */
> > - if (cpufreq_device->cpufreq_state == state)
> > + if (cur_state == state)
> > return 0;
> >
> > clip_freq = cpufreq_device->freq_table[state];
> > - cpufreq_device->cpufreq_state = state;
> > cpufreq_device->cpufreq_val = clip_freq;
> >
> > cpufreq_update_policy(cpu);
Thanks
Ogi
next prev parent reply other threads:[~2015-07-24 17:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 22:13 [PATCH] thermal/cpu_cooling: remove local cooling state variable Radivoje Jovanovic
2015-07-24 15:26 ` Punit Agrawal
2015-07-24 17:09 ` Radivoje Jovanovic [this message]
2015-07-29 16:46 ` Punit Agrawal
2015-07-29 17:00 ` Radivoje Jovanovic
2015-07-30 8:05 ` Viresh Kumar
2015-07-30 20:21 ` Radivoje Jovanovic
2015-07-31 3:18 ` Viresh Kumar
2015-07-31 15:30 ` Radivoje Jovanovic
2015-08-01 11:34 ` Viresh Kumar
2015-08-03 3:13 ` Viresh Kumar
2015-08-03 19:28 ` Radivoje Jovanovic
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=20150724100905.7e2e53f4@radivoje-desk2 \
--to=radivoje.jovanovic@linux.intel.com \
--cc=edubezval@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=punit.agrawal@arm.com \
--cc=radivoje.jovanovic@intel.com \
--cc=rui.zhang@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