ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
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

  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