From: l.majewski@samsung.com (Lukasz Majewski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points
Date: Fri, 07 Nov 2014 11:05:51 +0100 [thread overview]
Message-ID: <20141107110551.5316836f@amdc2363> (raw)
In-Reply-To: <20141107014152.GD10180@developer>
Hi Eduardo,
> On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote:
> > This patch extends the of-thermal.c to provide information about
> > number of available non critical (i.e. non HW) trip points in the
> > system.
> >
> > Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> > ---
> > drivers/thermal/of-thermal.c | 12 ++++++++++++
> > drivers/thermal/thermal_core.h | 5 +++++
> > 2 files changed, 17 insertions(+)
> >
> > diff --git a/drivers/thermal/of-thermal.c
> > b/drivers/thermal/of-thermal.c index 23c8d6c..cd74e64 100644
> > --- a/drivers/thermal/of-thermal.c
> > +++ b/drivers/thermal/of-thermal.c
> > @@ -128,6 +128,18 @@ int of_thermal_is_trip_en(struct
> > thermal_zone_device *tz, int trip) return 1;
> > }
> >
> > +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *tz)
> > +{
> > + struct __thermal_zone *data = tz->devdata;
> > + int i;
> > +
> > + for (i = 0; i < data->ntrips; i++)
> > + if (data->trips[i].type != THERMAL_TRIP_CRITICAL)
> > + continue;
> > +
> > + return --i;
> > +}
> > +
>
>
>
> I am not against this addition. But looks like we start to spread some
> specific APIs that may not be used to other drivers.
Why do you think that this is a specific API? In the thermal OF we can
define trip point as "active", "passive", "hot" and "critical".
With the first three we can handle them and properly react. For the last
one SoC's PMU will power down the board.
Do you know if any board (e.g. from TI) is NOT supposed to shut down
when "critical" temperature is passed?
The real problem here is the accessibility to __thermal_trip and
__thermal_bind arrays.
Use case:
In the Exynos driver we do need to initialize TMU registers with
threshold temperatures.
The temperature is read via tz->ops->get_trip_temp() [1] (from
of-thermal.c).
Unfortunately, the current API is not exporting the number of
non-critical trip points to know how many times call [1].
Of course we could by hand instantiate [1] n times, but this looks for
me a bit clumsy.
Additionally, we now have implicit assumption about the order of defined
temperatures for trip points, but I think this is not a big issue.
> Maybe having a
> single API to provide a read-only copy the list / array of trips might
> be a better approach. I will think of a better way.
Definitely. Exporting available trip points is crucial.
>
> I also request you to document it accordingly.
Ok, I will do that.
>
>
> > static int of_thermal_get_trend(struct thermal_zone_device *tz,
> > int trip, enum thermal_trend *trend)
> > {
> > diff --git a/drivers/thermal/thermal_core.h
> > b/drivers/thermal/thermal_core.h index ed8ff05..334a7be 100644
> > --- a/drivers/thermal/thermal_core.h
> > +++ b/drivers/thermal/thermal_core.h
> > @@ -83,6 +83,7 @@ int of_parse_thermal_zones(void);
> > void of_thermal_destroy_zones(void);
> > int of_thermal_get_ntrips(struct thermal_zone_device *);
> > int of_thermal_is_trip_en(struct thermal_zone_device *, int);
> > +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *);
> > #else
> > static inline int of_parse_thermal_zones(void) { return 0; }
> > static inline void of_thermal_destroy_zones(void) { }
> > @@ -94,6 +95,10 @@ int of_thermal_is_trip_en(struct
> > thermal_zone_device *, int) {
> > return 0;
> > }
> > +int of_thermal_get_non_crit_ntrips(struct thermal_zone_device *)
> here, it is supposed to be static inline.
>
> > +{
> > + return 0;
> > +}
> > #endif
> >
> > #endif /* __THERMAL_CORE_H__ */
> > --
> > 2.0.0.rc2
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
next prev parent reply other threads:[~2014-11-07 10:05 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 16:38 [PATCH 00/21] thermal: exynos: Thermal code rework to use device tree Lukasz Majewski
2014-10-09 16:38 ` [PATCH 01/21] thermal: of: Extend of-thermal.c to provide number of trip points Lukasz Majewski
2014-11-07 1:34 ` Eduardo Valentin
2014-11-07 9:14 ` Lukasz Majewski
2014-10-09 16:38 ` [PATCH 02/21] thermal: of: Extend of-thermal.c to provide check if trip point is enabled Lukasz Majewski
2014-11-07 1:37 ` Eduardo Valentin
2014-11-07 9:15 ` Lukasz Majewski
2014-10-09 16:38 ` [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points Lukasz Majewski
2014-11-07 1:41 ` Eduardo Valentin
2014-11-07 10:05 ` Lukasz Majewski [this message]
2014-11-07 16:06 ` Eduardo Valentin
2014-11-07 16:43 ` Lukasz Majewski
2014-11-12 9:42 ` Lukasz Majewski
2014-11-18 15:20 ` Eduardo Valentin
2014-11-18 20:25 ` Lukasz Majewski
2014-11-07 23:04 ` Dmitry Torokhov
2014-10-09 16:38 ` [PATCH 04/21] thermal: of: Extend current of-thermal.c code to allow setting emulated temp Lukasz Majewski
2014-11-07 1:44 ` Eduardo Valentin
2014-11-07 11:20 ` Lukasz Majewski
2014-11-18 15:23 ` Eduardo Valentin
2014-11-18 20:28 ` Lukasz Majewski
2014-10-09 16:38 ` [PATCH 05/21] thermal: exynos: cosmetic: Correct comment format Lukasz Majewski
2014-10-09 16:38 ` [PATCH 06/21] thermal: exynos: Provide thermal_exynos.h file to be included in device tree files Lukasz Majewski
2014-10-09 16:38 ` [PATCH 07/21] thermal: dts: trats: Enable TMU on the Exynos4210 trats device Lukasz Majewski
2014-10-09 16:38 ` [PATCH 08/21] thermal: dts: exynos: Adding LD010 regulator node necessary for TMU on Odroid U3 board Lukasz Majewski
2014-10-09 16:38 ` [PATCH 09/21] thermal: dts: Provide bindings and enable TMU at Exynos4x12 devices Lukasz Majewski
2014-10-09 16:38 ` [PATCH 10/21] thermal: cpu_cooling: dts: Define device tree bindings for Exynos cpu cooling functionality Lukasz Majewski
2014-10-09 16:38 ` [PATCH 11/21] thermal: cpu_cooling: Modify exynos thermal code to use device tree for cpu cooling configuration Lukasz Majewski
2014-10-09 16:38 ` [PATCH 12/21] thermal: exynos: dts: Add default definition for the TMU sensor Lukasz Majewski
2014-10-09 16:38 ` [PATCH 13/21] thermal: dts: Default trip points definition for Exynos5420 SoCs Lukasz Majewski
2014-10-09 16:38 ` [PATCH 14/21] thermal: exynos: dts: Define default thermal-zones for Exynos4 Lukasz Majewski
2014-10-09 16:38 ` [PATCH 15/21] thermal: dts: exynos: Trip points and sensor configuration data for Exynos5440 Lukasz Majewski
2014-10-09 16:38 ` [PATCH 16/21] thermal: exynos: dts: Provide device tree bindings identical to one in exynos_tmu_data.c Lukasz Majewski
2014-10-09 16:38 ` [PATCH 17/21] thermal: samsung: core: Exynos TMU rework to use device tree for configuration Lukasz Majewski
2014-10-09 16:38 ` [PATCH 18/21] thermal: exynos: Remove exynos_thermal_common.[c|h] files Lukasz Majewski
2014-10-09 16:38 ` [PATCH 19/21] thermal: exynos: Remove exynos_tmu_data.c file Lukasz Majewski
2014-10-09 16:38 ` [PATCH 20/21] thermal: exynos: Make Exynos5250 TMU compatible with Exynos4412 Lukasz Majewski
2014-10-09 16:38 ` [PATCH 21/21] thermal: exynos: Make Exynos3250 " Lukasz Majewski
2014-10-09 23:34 ` Chanwoo Choi
2014-10-10 8:51 ` Lukasz Majewski
2014-10-23 8:50 ` [PATCH 00/21] thermal: exynos: Thermal code rework to use device tree Lukasz Majewski
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=20141107110551.5316836f@amdc2363 \
--to=l.majewski@samsung.com \
--cc=linux-arm-kernel@lists.infradead.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