Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Dear Zhang, Eduardo, > Dear Zhang, Eduardo > > Do you have any comments/feedback for me regarding this thermal > framework related patch? > > I've already received some feedback from Durga for this patch, but I > think that maintainers are most welcome to express their opinion :-) > Will you find time to give me the feedback about proposed changes to thermal_core.c regarding the cpufreq boost support? > Thanks in advance. > -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Dear Zhang, Eduardo, Dear Zhang, Eduardo Do you have any comments/feedback for me regarding this thermal framework related patch? I've already received some feedback from Durga for this patch, but I think that maintainers are most welcome to express their opinion :-) Will you find time to give me the feedback about proposed changes to thermal_core.c regarding the cpufreq boost support? Thanks in advance. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Dear Zhang, Eduardo
Do you have any comments/feedback for me regarding this thermal
framework related patch?
I've already received some feedback from Durga for this patch, but I
think that maintainers are most welcome to express their opinion :-)
Thanks in advance.
> This patch provides auto disable/enable operation for boost. When any
> defined trip point is passed, the boost is disabled.
> In that moment thermal monitor workqueue is woken up and it monitors
> if the device temperature drops below 75% of the smallest trip point.
> When device cools down, the boost is enabled again.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Myungjoo Ham
>
> ---
> Changes for v5:
> - Move boost disable code from cpu_cooling.c to thermal_core.c
> (to handle_non_critical_trips)
> - Extent struct thermal_zone_device by adding overheated bool flag
> - Implement auto enable of boost after device cools down
> - Introduce boost_polling flag, which indicates if thermal uses it's
> predefined pool delay or has woken up thermal workqueue only to wait
> until device cools down.
>
> Changes for v4:
> - New patch
>
> drivers/thermal/thermal_core.c | 31 +++
> include/linux/thermal.h|2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c
> b/drivers/thermal/thermal_core.c index d755440..12adbad 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> thermal_zone_device *tz) static void handle_non_critical_trips(struct
> thermal_zone_device *tz, int trip, enum thermal_trip_type trip_type)
> {
> + if (cpufreq_boost_supported()) {
> + tz->overheated = true;
> + cpufreq_boost_trigger_state(0);
> + if (!tz->polling_delay) {
> + tz->boost_polling = true;
> + tz->polling_delay = 1000;
> + }
> + }
> +
> if (tz->governor)
> tz->governor->throttle(tz, trip);
> }
> @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
> work_struct *work) struct thermal_zone_device *tz =
> container_of(work, struct thermal_zone_device,
> poll_queue.work);
> + long trip_temp;
> +
> + if (cpufreq_boost_supported() && tz->overheated) {
> + tz->ops->get_trip_temp(tz, 0, _temp);
> + /*
> + * Enable boost again only when current temperature
> is less
> + * than 75% of trip_temp[0]
> + */
> + if ((tz->temperature + (trip_temp >> 2)) <
> trip_temp) {
> + tz->overheated = false;
> + if (tz->boost_polling) {
> + tz->boost_polling = false;
> + tz->polling_delay = 0;
> + monitor_thermal_zone(tz);
> + }
> +
> + cpufreq_boost_trigger_state(1);
> + return;
> + }
> + }
> +
> thermal_zone_device_update(tz);
> }
>
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a386a1c..f1aa3c2 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -172,6 +172,8 @@ struct thermal_zone_device {
> int emul_temperature;
> int passive;
> unsigned int forced_passive;
> + bool overheated;
> + bool boost_polling;
> const struct thermal_zone_device_ops *ops;
> const struct thermal_zone_params *tzp;
> struct thermal_governor *governor;
--
Best regards,
Lukasz Majewski
Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Dear Zhang, Eduardo
Do you have any comments/feedback for me regarding this thermal
framework related patch?
I've already received some feedback from Durga for this patch, but I
think that maintainers are most welcome to express their opinion :-)
Thanks in advance.
This patch provides auto disable/enable operation for boost. When any
defined trip point is passed, the boost is disabled.
In that moment thermal monitor workqueue is woken up and it monitors
if the device temperature drops below 75% of the smallest trip point.
When device cools down, the boost is enabled again.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes for v5:
- Move boost disable code from cpu_cooling.c to thermal_core.c
(to handle_non_critical_trips)
- Extent struct thermal_zone_device by adding overheated bool flag
- Implement auto enable of boost after device cools down
- Introduce boost_polling flag, which indicates if thermal uses it's
predefined pool delay or has woken up thermal workqueue only to wait
until device cools down.
Changes for v4:
- New patch
drivers/thermal/thermal_core.c | 31 +++
include/linux/thermal.h|2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/thermal/thermal_core.c
b/drivers/thermal/thermal_core.c index d755440..12adbad 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -33,6 +33,7 @@
#include linux/idr.h
#include linux/thermal.h
#include linux/reboot.h
+#include linux/cpufreq.h
#include net/netlink.h
#include net/genetlink.h
@@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
thermal_zone_device *tz) static void handle_non_critical_trips(struct
thermal_zone_device *tz, int trip, enum thermal_trip_type trip_type)
{
+ if (cpufreq_boost_supported()) {
+ tz-overheated = true;
+ cpufreq_boost_trigger_state(0);
+ if (!tz-polling_delay) {
+ tz-boost_polling = true;
+ tz-polling_delay = 1000;
+ }
+ }
+
if (tz-governor)
tz-governor-throttle(tz, trip);
}
@@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
work_struct *work) struct thermal_zone_device *tz =
container_of(work, struct thermal_zone_device,
poll_queue.work);
+ long trip_temp;
+
+ if (cpufreq_boost_supported() tz-overheated) {
+ tz-ops-get_trip_temp(tz, 0, trip_temp);
+ /*
+ * Enable boost again only when current temperature
is less
+ * than 75% of trip_temp[0]
+ */
+ if ((tz-temperature + (trip_temp 2))
trip_temp) {
+ tz-overheated = false;
+ if (tz-boost_polling) {
+ tz-boost_polling = false;
+ tz-polling_delay = 0;
+ monitor_thermal_zone(tz);
+ }
+
+ cpufreq_boost_trigger_state(1);
+ return;
+ }
+ }
+
thermal_zone_device_update(tz);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a386a1c..f1aa3c2 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -172,6 +172,8 @@ struct thermal_zone_device {
int emul_temperature;
int passive;
unsigned int forced_passive;
+ bool overheated;
+ bool boost_polling;
const struct thermal_zone_device_ops *ops;
const struct thermal_zone_params *tzp;
struct thermal_governor *governor;
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
On Fri, 05 Jul 2013 05:31:42 +, R, Durgadoss wrote:
Hi Durga,
> Hi Lukasz,
>
> > -Original Message-
> > From: Lukasz Majewski [mailto:l.majew...@majess.pl]
> > Sent: Friday, July 05, 2013 2:28 AM
> > To: R, Durgadoss
> > Cc: Lukasz Majewski; Viresh Kumar; Rafael J. Wysocki; Zhang, Rui;
> > Eduardo Valentin; cpuf...@vger.kernel.org; Linux PM list; Jonghwa
> > Lee; linux-kernel; Andre Przywara; Daniel Lezcano; Kukjin Kim;
> > Myungjoo Ham Subject: Re: [PATCH v5 5/7] thermal:boost: Automatic
> > enable/disable of BOOST feature
> >
> > On Thu, 4 Jul 2013 17:19:04 +
> > "R, Durgadoss" wrote:
> > Hi,
> >
>
> [Cut.]
>
> > > > @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> > > > thermal_zone_device *tz)
> > > > static void handle_non_critical_trips(struct
> > > > thermal_zone_device *tz, int trip, enum thermal_trip_type
> > > > trip_type) {
> > > > + if (cpufreq_boost_supported()) {
> > > > + tz->overheated = true;
> > > > + cpufreq_boost_trigger_state(0);
> > > > + if (!tz->polling_delay) {
> > > > + tz->boost_polling = true;
> > > > + tz->polling_delay = 1000;
> > > > + }
> > > > + }
> > > > +
> > > > if (tz->governor)
> > > > tz->governor->throttle(tz, trip);
> > > > }
> > > > @@ -453,6 +463,27 @@ static void
> > > > thermal_zone_device_check(struct work_struct *work)
> > > > struct thermal_zone_device *tz = container_of(work,
> > > > struct thermal_zone_device,
> > > > poll_queue.work);
> > > > + long trip_temp;
> > > > +
> > > > + if (cpufreq_boost_supported() && tz->overheated) {
> > >
> > > Not all thermal drivers support trip points. So, we first need a
> > > if (tz->ops->get_trip_temp) check here.
> >
> > Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs
> > supported by thermal set trip points.
>
> We would wish to get there. But not the reality today ;)
Ok, I see :-).
>
> >
> > >
> > > > + tz->ops->get_trip_temp(tz, 0, _temp);
> > > > + /*
> > > > +* Enable boost again only when current
> > > > temperature is less
> > > > +* than 75% of trip_temp[0]
> > > > +*/
> > > > + if ((tz->temperature + (trip_temp >> 2)) <
> > > > trip_temp) {
> > >
> > > Another way would be to use the get_trend APIs for this thermal
> > > zone. If the trend is cooling we can re-enable boost otherwise
> > > not.
> >
> > Trend evaluation seems like a good complementary idea.
> >
> > However, I would also like to have the relative temperature drop
> > measurement (if possible) like above (to 75% of the first trip
> > point).
> >
> > Then I would be more confident, that everything cooled down and
> > that I can start boost again.
> >
> > >
> > > > + tz->overheated = false;
> > > > + if (tz->boost_polling) {
> > > > + tz->boost_polling = false;
> > > > + tz->polling_delay = 0;
> > > > + monitor_thermal_zone(tz);
> > > > + }
> > >
> > > Overall, I believe this will work well only if the thermal zone is
> > > CPU.
> >
> > My assumption:
> >
> > When I enable boost at CPU, then I also shall cool down the CPU. And
> > the CPU zone seemed a natural choice.
> >
> > However I might be missing something, so hints are welcome.
> >
> > >
> > > Another suggestion is: We tried hard to remove all throttling
> > > logic from thermal_core.c.
> >
> > By throttling logic you mean:
> > if ((tz->temperature + (trip_temp >> 2)) and other conditions (like
> > trend measurement)?
>
> Yes. That is correct.
Ok.
>
> >
> > > May be we should include this kind of logic in
> > > step_wise.c ?
> >
> > It sounds interesting (since ->throttle at thermal_core.c is called
> > always when needed), but I'm afraid of a code duplication when one
> > use Boost with fair_share or other thermal governor.
>
> right. So, for the time being, (as part of this patch series)
> I am Okay to have this code in thermal_core.c. From the thermal
> subsystem perspective, we will (need to) work out a better/
> cleaner/easier approach for this later.
Thanks for understanding. I'm going to embed the trend checking in the
next version of this patch (to be more confident that I can reenable
boost).
>
> Thanks,
> Durga
>
--
Best regards,
Lukasz Majewski
Samsung R Institute Poland (SRPOL) | Linux Platform Group
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
On Fri, 05 Jul 2013 05:31:42 +, R, Durgadoss wrote:
Hi Durga,
Hi Lukasz,
-Original Message-
From: Lukasz Majewski [mailto:l.majew...@majess.pl]
Sent: Friday, July 05, 2013 2:28 AM
To: R, Durgadoss
Cc: Lukasz Majewski; Viresh Kumar; Rafael J. Wysocki; Zhang, Rui;
Eduardo Valentin; cpuf...@vger.kernel.org; Linux PM list; Jonghwa
Lee; linux-kernel; Andre Przywara; Daniel Lezcano; Kukjin Kim;
Myungjoo Ham Subject: Re: [PATCH v5 5/7] thermal:boost: Automatic
enable/disable of BOOST feature
On Thu, 4 Jul 2013 17:19:04 +
R, Durgadoss durgados...@intel.com wrote:
Hi,
[Cut.]
@@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
thermal_zone_device *tz)
static void handle_non_critical_trips(struct
thermal_zone_device *tz, int trip, enum thermal_trip_type
trip_type) {
+ if (cpufreq_boost_supported()) {
+ tz-overheated = true;
+ cpufreq_boost_trigger_state(0);
+ if (!tz-polling_delay) {
+ tz-boost_polling = true;
+ tz-polling_delay = 1000;
+ }
+ }
+
if (tz-governor)
tz-governor-throttle(tz, trip);
}
@@ -453,6 +463,27 @@ static void
thermal_zone_device_check(struct work_struct *work)
struct thermal_zone_device *tz = container_of(work,
struct thermal_zone_device,
poll_queue.work);
+ long trip_temp;
+
+ if (cpufreq_boost_supported() tz-overheated) {
Not all thermal drivers support trip points. So, we first need a
if (tz-ops-get_trip_temp) check here.
Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs
supported by thermal set trip points.
We would wish to get there. But not the reality today ;)
Ok, I see :-).
+ tz-ops-get_trip_temp(tz, 0, trip_temp);
+ /*
+* Enable boost again only when current
temperature is less
+* than 75% of trip_temp[0]
+*/
+ if ((tz-temperature + (trip_temp 2))
trip_temp) {
Another way would be to use the get_trend APIs for this thermal
zone. If the trend is cooling we can re-enable boost otherwise
not.
Trend evaluation seems like a good complementary idea.
However, I would also like to have the relative temperature drop
measurement (if possible) like above (to 75% of the first trip
point).
Then I would be more confident, that everything cooled down and
that I can start boost again.
+ tz-overheated = false;
+ if (tz-boost_polling) {
+ tz-boost_polling = false;
+ tz-polling_delay = 0;
+ monitor_thermal_zone(tz);
+ }
Overall, I believe this will work well only if the thermal zone is
CPU.
My assumption:
When I enable boost at CPU, then I also shall cool down the CPU. And
the CPU zone seemed a natural choice.
However I might be missing something, so hints are welcome.
Another suggestion is: We tried hard to remove all throttling
logic from thermal_core.c.
By throttling logic you mean:
if ((tz-temperature + (trip_temp 2)) and other conditions (like
trend measurement)?
Yes. That is correct.
Ok.
May be we should include this kind of logic in
step_wise.c ?
It sounds interesting (since -throttle at thermal_core.c is called
always when needed), but I'm afraid of a code duplication when one
use Boost with fair_share or other thermal governor.
right. So, for the time being, (as part of this patch series)
I am Okay to have this code in thermal_core.c. From the thermal
subsystem perspective, we will (need to) work out a better/
cleaner/easier approach for this later.
Thanks for understanding. I'm going to embed the trend checking in the
next version of this patch (to be more confident that I can reenable
boost).
Thanks,
Durga
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Hi Lukasz,
> -Original Message-
> From: Lukasz Majewski [mailto:l.majew...@majess.pl]
> Sent: Friday, July 05, 2013 2:28 AM
> To: R, Durgadoss
> Cc: Lukasz Majewski; Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo
> Valentin; cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; linux-kernel;
> Andre Przywara; Daniel Lezcano; Kukjin Kim; Myungjoo Ham
> Subject: Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
> feature
>
> On Thu, 4 Jul 2013 17:19:04 +
> "R, Durgadoss" wrote:
> Hi,
>
[Cut.]
> > > @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> > > thermal_zone_device *tz)
> > > static void handle_non_critical_trips(struct thermal_zone_device
> > > *tz, int trip, enum thermal_trip_type trip_type)
> > > {
> > > + if (cpufreq_boost_supported()) {
> > > + tz->overheated = true;
> > > + cpufreq_boost_trigger_state(0);
> > > + if (!tz->polling_delay) {
> > > + tz->boost_polling = true;
> > > + tz->polling_delay = 1000;
> > > + }
> > > + }
> > > +
> > > if (tz->governor)
> > > tz->governor->throttle(tz, trip);
> > > }
> > > @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
> > > work_struct *work)
> > > struct thermal_zone_device *tz = container_of(work, struct
> > > thermal_zone_device,
> > > poll_queue.work);
> > > + long trip_temp;
> > > +
> > > + if (cpufreq_boost_supported() && tz->overheated) {
> >
> > Not all thermal drivers support trip points. So, we first need a
> > if (tz->ops->get_trip_temp) check here.
>
> Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs supported
> by thermal set trip points.
We would wish to get there. But not the reality today ;)
>
> >
> > > + tz->ops->get_trip_temp(tz, 0, _temp);
> > > + /*
> > > + * Enable boost again only when current
> > > temperature is less
> > > + * than 75% of trip_temp[0]
> > > + */
> > > + if ((tz->temperature + (trip_temp >> 2)) <
> > > trip_temp) {
> >
> > Another way would be to use the get_trend APIs for this thermal zone.
> > If the trend is cooling we can re-enable boost otherwise not.
>
> Trend evaluation seems like a good complementary idea.
>
> However, I would also like to have the relative temperature drop
> measurement (if possible) like above (to 75% of the first trip point).
>
> Then I would be more confident, that everything cooled down and that I
> can start boost again.
>
> >
> > > + tz->overheated = false;
> > > + if (tz->boost_polling) {
> > > + tz->boost_polling = false;
> > > + tz->polling_delay = 0;
> > > + monitor_thermal_zone(tz);
> > > + }
> >
> > Overall, I believe this will work well only if the thermal zone is
> > CPU.
>
> My assumption:
>
> When I enable boost at CPU, then I also shall cool down the CPU. And
> the CPU zone seemed a natural choice.
>
> However I might be missing something, so hints are welcome.
>
> >
> > Another suggestion is: We tried hard to remove all throttling logic
> > from thermal_core.c.
>
> By throttling logic you mean:
> if ((tz->temperature + (trip_temp >> 2)) and other conditions (like
> trend measurement)?
Yes. That is correct.
>
> > May be we should include this kind of logic in
> > step_wise.c ?
>
> It sounds interesting (since ->throttle at thermal_core.c is called
> always when needed), but I'm afraid of a code duplication when one
> use Boost with fair_share or other thermal governor.
right. So, for the time being, (as part of this patch series)
I am Okay to have this code in thermal_core.c. From the thermal
subsystem perspective, we will (need to) work out a better/
cleaner/easier approach for this later.
Thanks,
Durga
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
On Thu, 4 Jul 2013 17:19:04 +
"R, Durgadoss" wrote:
Hi,
> Hi Lukasz,
>
> > -Original Message-
> > From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> > ow...@vger.kernel.org] On Behalf Of Lukasz Majewski
> > Sent: Thursday, July 04, 2013 2:20 PM
> > To: Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo Valentin
> > Cc: cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz
> > Majewski; l.majew...@majess.pl; linux-kernel; Andre Przywara;
> > Daniel Lezcano; Kukjin Kim; Myungjoo Ham
> > Subject: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of
> > BOOST feature
> >
> > This patch provides auto disable/enable operation for boost. When
> > any defined trip point is passed, the boost is disabled.
> > In that moment thermal monitor workqueue is woken up and it monitors
> > if the device temperature drops below 75% of the smallest trip
> > point. When device cools down, the boost is enabled again.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Myungjoo Ham
> >
> > ---
> > Changes for v5:
> > - Move boost disable code from cpu_cooling.c to thermal_core.c
> > (to handle_non_critical_trips)
> > - Extent struct thermal_zone_device by adding overheated bool flag
> > - Implement auto enable of boost after device cools down
> > - Introduce boost_polling flag, which indicates if thermal uses
> > it's predefined pool delay or has woken up thermal workqueue only
> > to wait until device cools down.
> >
> > Changes for v4:
> > - New patch
> >
> > drivers/thermal/thermal_core.c | 31
> > +++ include/linux/thermal.h|
> > 2 ++ 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/thermal/thermal_core.c
> > b/drivers/thermal/thermal_core.c index d755440..12adbad 100644
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -33,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> > thermal_zone_device *tz)
> > static void handle_non_critical_trips(struct thermal_zone_device
> > *tz, int trip, enum thermal_trip_type trip_type)
> > {
> > + if (cpufreq_boost_supported()) {
> > + tz->overheated = true;
> > + cpufreq_boost_trigger_state(0);
> > + if (!tz->polling_delay) {
> > + tz->boost_polling = true;
> > + tz->polling_delay = 1000;
> > + }
> > + }
> > +
> > if (tz->governor)
> > tz->governor->throttle(tz, trip);
> > }
> > @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
> > work_struct *work)
> > struct thermal_zone_device *tz = container_of(work, struct
> > thermal_zone_device,
> > poll_queue.work);
> > + long trip_temp;
> > +
> > + if (cpufreq_boost_supported() && tz->overheated) {
>
> Not all thermal drivers support trip points. So, we first need a
> if (tz->ops->get_trip_temp) check here.
Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs supported
by thermal set trip points.
>
> > + tz->ops->get_trip_temp(tz, 0, _temp);
> > + /*
> > +* Enable boost again only when current
> > temperature is less
> > +* than 75% of trip_temp[0]
> > +*/
> > + if ((tz->temperature + (trip_temp >> 2)) <
> > trip_temp) {
>
> Another way would be to use the get_trend APIs for this thermal zone.
> If the trend is cooling we can re-enable boost otherwise not.
Trend evaluation seems like a good complementary idea.
However, I would also like to have the relative temperature drop
measurement (if possible) like above (to 75% of the first trip point).
Then I would be more confident, that everything cooled down and that I
can start boost again.
>
> > + tz->overheated = false;
> > + if (tz->boost_polling) {
> > + tz->boost_polling = false;
> > + tz->polling_delay = 0;
> > + monitor_thermal_zone(tz);
> > + }
>
> Overall, I believe this will work well only if the thermal zone is
> CPU.
My assumption:
When I enable boost at CPU, then I also shall cool down the CPU. And
the CPU zone seemed a natural choice.
However I might be missing something, so hints are welcome.
>
> Another suggestion is: We tried hard to remove all throttling logic
> from thermal_core.c.
By throttling logic you mean:
if ((tz->temperature + (trip_temp >> 2)) and other conditions (like
trend measurement)?
> May be we should include this kind of logic in
> step_wise.c ?
It sounds interesting (since ->throttle at thermal_core.c is called
always when needed), but I'm afraid of a code duplication when one
use Boost with fair_share or other thermal governor.
> Rui/Eduardo: Any thoughts on
RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Hi Lukasz,
> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Lukasz Majewski
> Sent: Thursday, July 04, 2013 2:20 PM
> To: Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo Valentin
> Cc: cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz Majewski;
> l.majew...@majess.pl; linux-kernel; Andre Przywara; Daniel Lezcano; Kukjin
> Kim;
> Myungjoo Ham
> Subject: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
> feature
>
> This patch provides auto disable/enable operation for boost. When any
> defined trip point is passed, the boost is disabled.
> In that moment thermal monitor workqueue is woken up and it monitors
> if the device temperature drops below 75% of the smallest trip point.
> When device cools down, the boost is enabled again.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Myungjoo Ham
>
> ---
> Changes for v5:
> - Move boost disable code from cpu_cooling.c to thermal_core.c
> (to handle_non_critical_trips)
> - Extent struct thermal_zone_device by adding overheated bool flag
> - Implement auto enable of boost after device cools down
> - Introduce boost_polling flag, which indicates if thermal uses it's
> predefined
> pool delay or has woken up thermal workqueue only to wait until device
> cools down.
>
> Changes for v4:
> - New patch
>
> drivers/thermal/thermal_core.c | 31 +++
> include/linux/thermal.h|2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index d755440..12adbad 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
> thermal_zone_device *tz)
> static void handle_non_critical_trips(struct thermal_zone_device *tz,
> int trip, enum thermal_trip_type trip_type)
> {
> + if (cpufreq_boost_supported()) {
> + tz->overheated = true;
> + cpufreq_boost_trigger_state(0);
> + if (!tz->polling_delay) {
> + tz->boost_polling = true;
> + tz->polling_delay = 1000;
> + }
> + }
> +
> if (tz->governor)
> tz->governor->throttle(tz, trip);
> }
> @@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
> work_struct *work)
> struct thermal_zone_device *tz = container_of(work, struct
> thermal_zone_device,
> poll_queue.work);
> + long trip_temp;
> +
> + if (cpufreq_boost_supported() && tz->overheated) {
Not all thermal drivers support trip points. So, we first need a
if (tz->ops->get_trip_temp) check here.
> + tz->ops->get_trip_temp(tz, 0, _temp);
> + /*
> + * Enable boost again only when current temperature is less
> + * than 75% of trip_temp[0]
> + */
> + if ((tz->temperature + (trip_temp >> 2)) < trip_temp) {
Another way would be to use the get_trend APIs for this thermal zone.
If the trend is cooling we can re-enable boost otherwise not.
> + tz->overheated = false;
> + if (tz->boost_polling) {
> + tz->boost_polling = false;
> + tz->polling_delay = 0;
> + monitor_thermal_zone(tz);
> + }
Overall, I believe this will work well only if the thermal zone is CPU.
Another suggestion is: We tried hard to remove all throttling logic from
thermal_core.c. May be we should include this kind of logic in
step_wise.c ? Rui/Eduardo: Any thoughts on this ?
Thanks,
Durga
> +
> + cpufreq_boost_trigger_state(1);
> + return;
> + }
> + }
> +
> thermal_zone_device_update(tz);
> }
>
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a386a1c..f1aa3c2 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -172,6 +172,8 @@ struct thermal_zone_device {
> int emul_temperature;
> int passive;
> unsigned int forced_passive;
> + bool overheated;
> + bool boost_polling;
> const struct thermal_zone_device_ops *ops;
> const struct thermal_zone_params *tzp;
> struct thermal_governor *governor;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Hi Lukasz,
-Original Message-
From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
ow...@vger.kernel.org] On Behalf Of Lukasz Majewski
Sent: Thursday, July 04, 2013 2:20 PM
To: Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo Valentin
Cc: cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz Majewski;
l.majew...@majess.pl; linux-kernel; Andre Przywara; Daniel Lezcano; Kukjin
Kim;
Myungjoo Ham
Subject: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
feature
This patch provides auto disable/enable operation for boost. When any
defined trip point is passed, the boost is disabled.
In that moment thermal monitor workqueue is woken up and it monitors
if the device temperature drops below 75% of the smallest trip point.
When device cools down, the boost is enabled again.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes for v5:
- Move boost disable code from cpu_cooling.c to thermal_core.c
(to handle_non_critical_trips)
- Extent struct thermal_zone_device by adding overheated bool flag
- Implement auto enable of boost after device cools down
- Introduce boost_polling flag, which indicates if thermal uses it's
predefined
pool delay or has woken up thermal workqueue only to wait until device
cools down.
Changes for v4:
- New patch
drivers/thermal/thermal_core.c | 31 +++
include/linux/thermal.h|2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d755440..12adbad 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -33,6 +33,7 @@
#include linux/idr.h
#include linux/thermal.h
#include linux/reboot.h
+#include linux/cpufreq.h
#include net/netlink.h
#include net/genetlink.h
@@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
thermal_zone_device *tz)
static void handle_non_critical_trips(struct thermal_zone_device *tz,
int trip, enum thermal_trip_type trip_type)
{
+ if (cpufreq_boost_supported()) {
+ tz-overheated = true;
+ cpufreq_boost_trigger_state(0);
+ if (!tz-polling_delay) {
+ tz-boost_polling = true;
+ tz-polling_delay = 1000;
+ }
+ }
+
if (tz-governor)
tz-governor-throttle(tz, trip);
}
@@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
work_struct *work)
struct thermal_zone_device *tz = container_of(work, struct
thermal_zone_device,
poll_queue.work);
+ long trip_temp;
+
+ if (cpufreq_boost_supported() tz-overheated) {
Not all thermal drivers support trip points. So, we first need a
if (tz-ops-get_trip_temp) check here.
+ tz-ops-get_trip_temp(tz, 0, trip_temp);
+ /*
+ * Enable boost again only when current temperature is less
+ * than 75% of trip_temp[0]
+ */
+ if ((tz-temperature + (trip_temp 2)) trip_temp) {
Another way would be to use the get_trend APIs for this thermal zone.
If the trend is cooling we can re-enable boost otherwise not.
+ tz-overheated = false;
+ if (tz-boost_polling) {
+ tz-boost_polling = false;
+ tz-polling_delay = 0;
+ monitor_thermal_zone(tz);
+ }
Overall, I believe this will work well only if the thermal zone is CPU.
Another suggestion is: We tried hard to remove all throttling logic from
thermal_core.c. May be we should include this kind of logic in
step_wise.c ? Rui/Eduardo: Any thoughts on this ?
Thanks,
Durga
+
+ cpufreq_boost_trigger_state(1);
+ return;
+ }
+ }
+
thermal_zone_device_update(tz);
}
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index a386a1c..f1aa3c2 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -172,6 +172,8 @@ struct thermal_zone_device {
int emul_temperature;
int passive;
unsigned int forced_passive;
+ bool overheated;
+ bool boost_polling;
const struct thermal_zone_device_ops *ops;
const struct thermal_zone_params *tzp;
struct thermal_governor *governor;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
On Thu, 4 Jul 2013 17:19:04 +
R, Durgadoss durgados...@intel.com wrote:
Hi,
Hi Lukasz,
-Original Message-
From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
ow...@vger.kernel.org] On Behalf Of Lukasz Majewski
Sent: Thursday, July 04, 2013 2:20 PM
To: Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo Valentin
Cc: cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz
Majewski; l.majew...@majess.pl; linux-kernel; Andre Przywara;
Daniel Lezcano; Kukjin Kim; Myungjoo Ham
Subject: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of
BOOST feature
This patch provides auto disable/enable operation for boost. When
any defined trip point is passed, the boost is disabled.
In that moment thermal monitor workqueue is woken up and it monitors
if the device temperature drops below 75% of the smallest trip
point. When device cools down, the boost is enabled again.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes for v5:
- Move boost disable code from cpu_cooling.c to thermal_core.c
(to handle_non_critical_trips)
- Extent struct thermal_zone_device by adding overheated bool flag
- Implement auto enable of boost after device cools down
- Introduce boost_polling flag, which indicates if thermal uses
it's predefined pool delay or has woken up thermal workqueue only
to wait until device cools down.
Changes for v4:
- New patch
drivers/thermal/thermal_core.c | 31
+++ include/linux/thermal.h|
2 ++ 2 files changed, 33 insertions(+)
diff --git a/drivers/thermal/thermal_core.c
b/drivers/thermal/thermal_core.c index d755440..12adbad 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -33,6 +33,7 @@
#include linux/idr.h
#include linux/thermal.h
#include linux/reboot.h
+#include linux/cpufreq.h
#include net/netlink.h
#include net/genetlink.h
@@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
thermal_zone_device *tz)
static void handle_non_critical_trips(struct thermal_zone_device
*tz, int trip, enum thermal_trip_type trip_type)
{
+ if (cpufreq_boost_supported()) {
+ tz-overheated = true;
+ cpufreq_boost_trigger_state(0);
+ if (!tz-polling_delay) {
+ tz-boost_polling = true;
+ tz-polling_delay = 1000;
+ }
+ }
+
if (tz-governor)
tz-governor-throttle(tz, trip);
}
@@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
work_struct *work)
struct thermal_zone_device *tz = container_of(work, struct
thermal_zone_device,
poll_queue.work);
+ long trip_temp;
+
+ if (cpufreq_boost_supported() tz-overheated) {
Not all thermal drivers support trip points. So, we first need a
if (tz-ops-get_trip_temp) check here.
Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs supported
by thermal set trip points.
+ tz-ops-get_trip_temp(tz, 0, trip_temp);
+ /*
+* Enable boost again only when current
temperature is less
+* than 75% of trip_temp[0]
+*/
+ if ((tz-temperature + (trip_temp 2))
trip_temp) {
Another way would be to use the get_trend APIs for this thermal zone.
If the trend is cooling we can re-enable boost otherwise not.
Trend evaluation seems like a good complementary idea.
However, I would also like to have the relative temperature drop
measurement (if possible) like above (to 75% of the first trip point).
Then I would be more confident, that everything cooled down and that I
can start boost again.
+ tz-overheated = false;
+ if (tz-boost_polling) {
+ tz-boost_polling = false;
+ tz-polling_delay = 0;
+ monitor_thermal_zone(tz);
+ }
Overall, I believe this will work well only if the thermal zone is
CPU.
My assumption:
When I enable boost at CPU, then I also shall cool down the CPU. And
the CPU zone seemed a natural choice.
However I might be missing something, so hints are welcome.
Another suggestion is: We tried hard to remove all throttling logic
from thermal_core.c.
By throttling logic you mean:
if ((tz-temperature + (trip_temp 2)) and other conditions (like
trend measurement)?
May be we should include this kind of logic in
step_wise.c ?
It sounds interesting (since -throttle at thermal_core.c is called
always when needed), but I'm afraid of a code duplication when one
use Boost with fair_share or other thermal governor.
Rui/Eduardo: Any thoughts on this ?
Thanks,
Durga
+
+
RE: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST feature
Hi Lukasz,
-Original Message-
From: Lukasz Majewski [mailto:l.majew...@majess.pl]
Sent: Friday, July 05, 2013 2:28 AM
To: R, Durgadoss
Cc: Lukasz Majewski; Viresh Kumar; Rafael J. Wysocki; Zhang, Rui; Eduardo
Valentin; cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; linux-kernel;
Andre Przywara; Daniel Lezcano; Kukjin Kim; Myungjoo Ham
Subject: Re: [PATCH v5 5/7] thermal:boost: Automatic enable/disable of BOOST
feature
On Thu, 4 Jul 2013 17:19:04 +
R, Durgadoss durgados...@intel.com wrote:
Hi,
[Cut.]
@@ -326,6 +327,15 @@ static void monitor_thermal_zone(struct
thermal_zone_device *tz)
static void handle_non_critical_trips(struct thermal_zone_device
*tz, int trip, enum thermal_trip_type trip_type)
{
+ if (cpufreq_boost_supported()) {
+ tz-overheated = true;
+ cpufreq_boost_trigger_state(0);
+ if (!tz-polling_delay) {
+ tz-boost_polling = true;
+ tz-polling_delay = 1000;
+ }
+ }
+
if (tz-governor)
tz-governor-throttle(tz, trip);
}
@@ -453,6 +463,27 @@ static void thermal_zone_device_check(struct
work_struct *work)
struct thermal_zone_device *tz = container_of(work, struct
thermal_zone_device,
poll_queue.work);
+ long trip_temp;
+
+ if (cpufreq_boost_supported() tz-overheated) {
Not all thermal drivers support trip points. So, we first need a
if (tz-ops-get_trip_temp) check here.
Ok, thanks for tip. Bluntly speaking, I thought, that all SoCs supported
by thermal set trip points.
We would wish to get there. But not the reality today ;)
+ tz-ops-get_trip_temp(tz, 0, trip_temp);
+ /*
+ * Enable boost again only when current
temperature is less
+ * than 75% of trip_temp[0]
+ */
+ if ((tz-temperature + (trip_temp 2))
trip_temp) {
Another way would be to use the get_trend APIs for this thermal zone.
If the trend is cooling we can re-enable boost otherwise not.
Trend evaluation seems like a good complementary idea.
However, I would also like to have the relative temperature drop
measurement (if possible) like above (to 75% of the first trip point).
Then I would be more confident, that everything cooled down and that I
can start boost again.
+ tz-overheated = false;
+ if (tz-boost_polling) {
+ tz-boost_polling = false;
+ tz-polling_delay = 0;
+ monitor_thermal_zone(tz);
+ }
Overall, I believe this will work well only if the thermal zone is
CPU.
My assumption:
When I enable boost at CPU, then I also shall cool down the CPU. And
the CPU zone seemed a natural choice.
However I might be missing something, so hints are welcome.
Another suggestion is: We tried hard to remove all throttling logic
from thermal_core.c.
By throttling logic you mean:
if ((tz-temperature + (trip_temp 2)) and other conditions (like
trend measurement)?
Yes. That is correct.
May be we should include this kind of logic in
step_wise.c ?
It sounds interesting (since -throttle at thermal_core.c is called
always when needed), but I'm afraid of a code duplication when one
use Boost with fair_share or other thermal governor.
right. So, for the time being, (as part of this patch series)
I am Okay to have this code in thermal_core.c. From the thermal
subsystem perspective, we will (need to) work out a better/
cleaner/easier approach for this later.
Thanks,
Durga
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
