From: Javi Merino <javi.merino@arm.com>
To: Eduardo Valentin <edubezval@gmail.com>
Cc: Punit Agrawal <Punit.Agrawal@arm.com>,
Zhang Rui <rui.zhang@intel.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 1/3] Thermal: initialize thermal zone device correctly
Date: Tue, 24 Mar 2015 17:20:47 +0000 [thread overview]
Message-ID: <20150324172047.GB1824@e104805> (raw)
In-Reply-To: <20150324150004.GB29155@developer.hsd1.ca.comcast.net>
On Tue, Mar 24, 2015 at 03:00:06PM +0000, Eduardo Valentin wrote:
> Rui,
>
> A couple of comments.
>
> On Tue, Mar 24, 2015 at 01:21:28PM +0800, Zhang Rui wrote:
> > After thermal zone device registered, as we have not read any
> > temperature before, thus tz->temperature should not be 0, which actually
> > means 0C, and thermal trend is not available.
> > In this case, we need specially handling for the first
> > thermal_zone_device_update().
> >
> > Both thermal core framework and step_wise governor is enhanced to handle this.
> >
> > CC: <stable@vger.kernel.org> #3.18+
> > Tested-by: Manuel Krause <manuelkrause@netscape.net>
> > Tested-by: szegad <szegadlo@poczta.onet.pl>
> > Tested-by: prash <prash.n.rao@gmail.com>
> > Tested-by: amish <ammdispose-arch@yahoo.com>
> > Tested-by: Matthias <morpheusxyz123@yahoo.de>
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> > ---
> > drivers/thermal/step_wise.c | 15 +++++++++++++--
> > drivers/thermal/thermal_core.c | 19 +++++++++++++++++--
> > drivers/thermal/thermal_core.h | 1 +
> > include/linux/thermal.h | 3 +++
> > 4 files changed, 34 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
>
> Should this patch also include changes in other governors ?
If I understand it correctly, instance->initialized actually means
"is the trend valid?". As step_wise is the only governor that uses
the trend, it's the only one that needs updating.
> > index 5a0f12d..c2bb37c 100644
> > --- a/drivers/thermal/step_wise.c
> > +++ b/drivers/thermal/step_wise.c
> > @@ -63,6 +63,16 @@ static unsigned long get_target_state(struct thermal_instance *instance,
> > next_target = instance->target;
> > dev_dbg(&cdev->device, "cur_state=%ld\n", cur_state);
> >
> > + if (!instance->initialized) {
> > + if (throttle) {
> > + next_target = (cur_state + 1) >= instance->upper ?
> > + instance->upper :
> > + ((cur_state + 1) < instance->lower ?
> > + instance->lower : (cur_state + 1));
>
> Why it makes sense to change the next state if a instance is
> uninitialized?
>
> > + } else
> > + next_target = THERMAL_NO_TARGET;
CodingStyle says that if one branch of an if statement needs braces,
all branches must have braces:
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
> > + }
> > +
Does this really work? The update of next_target will probably be
overwritten by the switch below, shouldn't you "return next_target;"
at the end of the "if (!instance->initialized)"?
> > switch (trend) {
> > case THERMAL_TREND_RAISING:
> > if (throttle) {
> > @@ -149,7 +159,8 @@ static void thermal_zone_trip_update(struct thermal_zone_device *tz, int trip)
> > dev_dbg(&instance->cdev->device, "old_target=%d, target=%d\n",
> > old_target, (int)instance->target);
> >
> > - if (old_target == instance->target)
> > + if (instance->initialized &&
> > + old_target == instance->target)
> > continue;
> >
> > /* Activate a passive thermal instance */
> > @@ -161,7 +172,7 @@ static void thermal_zone_trip_update(struct thermal_zone_device *tz, int trip)
> > instance->target == THERMAL_NO_TARGET)
> > update_passive_instance(tz, trip_type, -1);
> >
> > -
> > + instance->initialized = true;
> > instance->cdev->updated = false; /* cdev needs update */
> > }
> >
> > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> > index 174d3bc..9d6f71b 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -469,8 +469,22 @@ static void update_temperature(struct thermal_zone_device *tz)
> > mutex_unlock(&tz->lock);
> >
> > trace_thermal_temperature(tz);
> > - dev_dbg(&tz->device, "last_temperature=%d, current_temperature=%d\n",
> > - tz->last_temperature, tz->temperature);
> > + if (tz->last_temperature == THERMAL_TEMP_INVALID)
> > + dev_dbg(&tz->device, "last_temperature N/A, current_temperature=%d\n",
> > + tz->temperature);
> > + else
> > + dev_dbg(&tz->device, "last_temperature=%d, current_temperature=%d\n",
> > + tz->last_temperature, tz->temperature);
>
> Should we also teach the tracing facility about THERMAL_TEMP_INVALID?
I don't think there's a good way of putting this information in
trace. The format string is fixed and playing with it like we do here
is not an option. In practical terms, trace will collect a weird
"-27400" for the previous temperature, so it's not too bad. I guess
it would help if the invalid temperature was something more obvious,
like INT_MIN.
> > +}
> > +
> > +static void thermal_zone_device_reset(struct thermal_zone_device *tz)
> > +{
> > + struct thermal_instance *pos;
> > +
> > + tz->temperature = THERMAL_TEMP_INVALID;
> > + tz->passive = 0;
> > + list_for_each_entry(pos, &tz->thermal_instances, tz_node)
> > + pos->initialized = false;
> > }
> >
> > void thermal_zone_device_update(struct thermal_zone_device *tz)
> > @@ -1574,6 +1588,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type,
> > if (!tz->ops->get_temp)
> > thermal_zone_device_set_polling(tz, 0);
> >
> > + thermal_zone_device_reset(tz);
> > thermal_zone_device_update(tz);
> >
> > return tz;
> > diff --git a/drivers/thermal/thermal_core.h b/drivers/thermal/thermal_core.h
> > index 0531c75..6d9ffa5 100644
> > --- a/drivers/thermal/thermal_core.h
> > +++ b/drivers/thermal/thermal_core.h
> > @@ -41,6 +41,7 @@ struct thermal_instance {
> > struct thermal_zone_device *tz;
> > struct thermal_cooling_device *cdev;
> > int trip;
> > + bool initialized;
This could be more specific. If I understand it correctly, this flag
indicates if the trend is valid or not. Can we call it "valid_trend"
instead?
> > unsigned long upper; /* Highest cooling state for this trip point */
> > unsigned long lower; /* Lowest cooling state for this trip point */
> > unsigned long target; /* expected cooling state */
> > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > index 5eac316..8650b0b 100644
> > --- a/include/linux/thermal.h
> > +++ b/include/linux/thermal.h
> > @@ -40,6 +40,9 @@
> > /* No upper/lower limit requirement */
> > #define THERMAL_NO_LIMIT ((u32)~0)
> >
> > +/* Invalid/uninitialized temperature */
> > +#define THERMAL_TEMP_INVALID -27400
Out of curiosity, why -27400? Why not INT_MIN?
Cheers,
Javi
next prev parent reply other threads:[~2015-03-24 17:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 5:21 [PATCH 0/3] Thermal: thermal enhancements for boot and system sleep Zhang Rui
2015-03-24 5:21 ` [PATCH 1/3] Thermal: initialize thermal zone device correctly Zhang Rui
2015-03-24 15:00 ` Eduardo Valentin
2015-03-24 17:20 ` Javi Merino [this message]
2015-03-25 2:14 ` Zhang, Rui
2015-03-24 5:21 ` [PATCH 2/3] Thermal: handle thermal zone device properly during system sleep Zhang Rui
2015-03-24 15:06 ` Eduardo Valentin
2015-03-25 2:25 ` Zhang, Rui
2015-03-25 14:40 ` Eduardo Valentin
2015-03-24 16:39 ` Javi Merino
2015-03-25 2:28 ` Zhang, Rui
2015-03-24 5:21 ` [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered Zhang Rui
2015-03-24 15:12 ` Eduardo Valentin
2015-03-25 2:27 ` Zhang, Rui
-- strict thread matches above, loose matches on Subject: below --
2015-09-27 5:48 [PATCH 1/3] Thermal: initialize thermal zone device correctly Chen Yu
2015-09-28 14:28 ` Javi Merino
2015-09-28 17:30 ` Chen, Yu C
2015-09-28 17:47 ` Javi Merino
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=20150324172047.GB1824@e104805 \
--to=javi.merino@arm.com \
--cc=Punit.Agrawal@arm.com \
--cc=edubezval@gmail.com \
--cc=linux-pm@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=stable@vger.kernel.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