[Ksummit-discuss] [TECH TOPIC] [CORE TOPIC] The three ways of temperature sensing in Linux

[Heiko Stuebner]

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