From: edubezval@gmail.com (Eduardo Valentin)
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: Tue, 18 Nov 2014 11:20:26 -0400 [thread overview]
Message-ID: <20141118152024.GA18674@developer> (raw)
In-Reply-To: <20141112104241.50f644a4@amdc2363>
Hello Lukasz,
On Wed, Nov 12, 2014 at 10:42:41AM +0100, Lukasz Majewski wrote:
> Hi Eduardo,
>
> >
> > Hello Lukasz,
> >
> > On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote:
> > > 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?
> > >
> >
> > So, my point is not really about the usage of trip points. It is just
> > that the of-thermal API will grow with in a wide way with specific
> > functions to check some property on the trip point array. And not all
> > drivers may be using these function, e.g. the above proposal.
> >
> > > 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.
> >
> >
> > I understand your use case. My point was simply that this use case may
> > be specific to your driver (or few drivers).
> > >
> > > 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.
> > >
> >
> > Yeah, I think it is the best thing to do. Share a read-only array /
> > copy of the needed data, and then drivers would check what ever
> > property they need from the array. Just make sure you document that
> > this is a read-only array (i.e. any possible change they do, won't
> > affect the original array).
>
> So I assume that you don't mind that I will prepare such of-thermal.c
> modification?
No, please, feel free to send the proposal along with your patchset. To
me, it makes sense you do it, because you will also present a real use
case of this required change.
>
> >
> > > >
> > > > I also request you to document it accordingly.
> > >
> > > Ok, I will do that.
> >
> > Cool!
> >
> >
> >
> > >
> > > >
> > > >
> > > > > 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
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141118/767cfb83/attachment-0001.sig>
next prev parent reply other threads:[~2014-11-18 15:20 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
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 [this message]
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=20141118152024.GA18674@developer \
--to=edubezval@gmail.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;
as well as URLs for NNTP newsgroup(s).