From: Heiko Stuebner <heiko@sntech.de>
To: ksummit-discuss@lists.linuxfoundation.org
Cc: Zhang Rui <rui.zhang@intel.com>, Jean Delvare <jdelvare@suse.com>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] [CORE TOPIC] The three ways of temperature sensing in Linux
Date: Tue, 25 Aug 2015 23:31:46 +0200 [thread overview]
Message-ID: <2185734.lNGgzKaky2@phil> (raw)
In-Reply-To: <20150825061208.GA13186@localhost.localdomain>
Am Montag, 24. August 2015, 23:12:10 schrieb Eduardo Valentin:
> Hi all,
>
> [Not sure if this is TECH or CORE, as it touches more than one
> subsystem]
>
> Not sure how late it is to post this, but I am trying anyway.
>
> During LPC 2015 last week it came out the topic of the interaction
> between the thermal subsystem with HWMON. On top of it, we also got a
> proposal [1] of having thermal exposing its registered devices as IIO.
>
> I know the three subsystem coexist today for some years. They also have
> their own design goals. However, the fact that we have three different
> subsystems for doing very similar task may be confusing, for the driver
> writer, and for user space too.
>
> Another aspect of it is the possible code duplication. For example, it
> would interesting to get board temperature sensors, typically registered
> as hwmon devices, to be available in the thermal subsystem while
> constructing thermal zones out of them. Some user process would expect
> the opposite though, to read the thermal zone sensors as hwmon devices,
> or as IIO devices.
>
> Therefore, it would be interesting to have a better convergence on how
> these subsystems talk to each other, and how this is exposed to user
> space.
On Rockchip we currently have two scenarios:
rk3066 simply has a "dumb" (ts-)adc just emitting voltages and is actually the
same ip as the saradc and thus an iio adc driver. It will need something like
the iio-thermal driver that was posted by someone quite some time ago to
actually get temperatures and act on them.
The rk3288 on the other hand has a much more intelligent tsadc - including
temperature-specific actions, which also already has a thermal driver in the
kernel.
So far I always thought hwmon was some sort of grandfather to the thermal
subsystem without any specific api, but I've also not needed one at all yet.
Heiko
next prev parent reply other threads:[~2015-08-25 21:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 6:12 Eduardo Valentin
2015-08-25 6:26 ` Krzysztof Kozlowski
2015-08-25 14:03 ` Guenter Roeck
2015-08-25 21:26 ` Eduardo Valentin
2015-08-25 21:13 ` Eduardo Valentin
2015-08-25 21:31 ` Heiko Stuebner [this message]
2015-08-25 23:55 ` Guenter Roeck
2015-08-26 0:12 ` Eduardo Valentin
2015-08-26 4:14 ` Guenter Roeck
2015-08-26 6:04 ` Jonathan Cameron
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=2185734.lNGgzKaky2@phil \
--to=heiko@sntech.de \
--cc=jdelvare@suse.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--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