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

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

[Eduardo Valentin]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

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. 

The involved maintainers are:
HWMON:
M:      Jean Delvare <jdelvare@suse.com>
M:      Guenter Roeck <linux@roeck-us.net>

Thermal:
M:      Zhang Rui <rui.zhang@intel.com>
M:      Eduardo Valentin <edubezval@gmail.com>

IIO:
M:      Jonathan Cameron <jic23@kernel.org>

BR,

Eduardo Valentin

[1] - http://comments.gmane.org/gmane.linux.kernel.iio/19627


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Krzysztof Kozlowski]

On 25.08.2015 15:12, Eduardo Valentin wrote:
> 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.

I would rather expect using only one subsystem for exporting this
information to user-space. If the susbsytem lacks some features then it
could be expanded.

Some power supply drivers (fuel gauges or chargers) also provide
temperature data. They use the thermal for that. It would be weird to
export them through IIO...

Anyway from that point of view the topic is interesting to me.

Best regards,
Krzysztof

> 
> 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. 
> 
> The involved maintainers are:
> HWMON:
> M:      Jean Delvare <jdelvare@suse.com>
> M:      Guenter Roeck <linux@roeck-us.net>
> 
> Thermal:
> M:      Zhang Rui <rui.zhang@intel.com>
> M:      Eduardo Valentin <edubezval@gmail.com>
> 
> IIO:
> M:      Jonathan Cameron <jic23@kernel.org>
> 
> BR,
> 
> Eduardo Valentin
> 
> [1] - http://comments.gmane.org/gmane.linux.kernel.iio/19627
> 
> 
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

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

[Guenter Roeck]

On 08/24/2015 11:26 PM, Krzysztof Kozlowski wrote:
> On 25.08.2015 15:12, Eduardo Valentin wrote:
>> 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.
>
> I would rather expect using only one subsystem for exporting this
> information to user-space. If the susbsytem lacks some features then it
> could be expanded.
>
> Some power supply drivers (fuel gauges or chargers) also provide
> temperature data. They use the thermal for that. It would be weird to
> export them through IIO...
>

I agree, the current situation is less than optimal.

There are bridges from thermal and iio to hwmon, but they are not
perfect. Resulting hwmon device names are odd, and iio doesn't support
limits. The thermal-hwmon bridge only supports one trip point, and
it doesn't pass alarms.

Both the iio-hwmon and the thermal-hwmon bridge break the hwmon model
of reporting sensor data per chip, which makes it difficult to convert
drivers from hwmon to thermal (if that is suggested) without breaking
the userspace ABI.

At the same time, there is no bridge from the hwmon core to thermal.
Currently hwmon drivers supporting thermal register with both hwmon
and thermal, which is really undesirable. Implementing a hwmon-thermal
bridge in the hwmon core would require implementing a new hwmon registration
API. That is easier said then done, and would require more time than
at least I have available.

This, I think, is the core of the problem. Somehow would have to go in
and create that new hwmon registration API, if that is a solution
acceptable to the thermal maintainers. At the same time, the thermal-hwmon
bridge should be improved to export provide available information to hwmon.

An alternative would be for thermal to 'take over', convert all hwmon
drivers to thermal drivers, and retain a compatibility layer to provide
the data as hwmon device data to user space without breaking the existing
hwmon ABI. Again, someone would have to do that work.

Guenter

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

[Eduardo Valentin]

[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]

On Tue, Aug 25, 2015 at 03:26:43PM +0900, Krzysztof Kozlowski wrote:
> On 25.08.2015 15:12, Eduardo Valentin wrote:
> > 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.
> 
> I would rather expect using only one subsystem for exporting this
> information to user-space. If the susbsytem lacks some features then it
> could be expanded.

Yes. That would be the best scenario. I agree here. But in practice, we
have three different subsystem doing similar things around temperature
monitoring. Then, the topic is really to discuss how to either converge
to having one (which at this point, I doubt it would be that straight
forward, specially considering the fact that we must avoid breaking
userspace) or at least having the subsystems having a better interaction
between each other.

> 
> Some power supply drivers (fuel gauges or chargers) also provide
> temperature data. They use the thermal for that. It would be weird to
> export them through IIO...

Agreed here too. 

> 
> Anyway from that point of view the topic is interesting to me.

Cool!

BR,

Eduardo Valentin

> 
> Best regards,
> Krzysztof
> 
> > 
> > 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. 
> > 
> > The involved maintainers are:
> > HWMON:
> > M:      Jean Delvare <jdelvare@suse.com>
> > M:      Guenter Roeck <linux@roeck-us.net>
> > 
> > Thermal:
> > M:      Zhang Rui <rui.zhang@intel.com>
> > M:      Eduardo Valentin <edubezval@gmail.com>
> > 
> > IIO:
> > M:      Jonathan Cameron <jic23@kernel.org>
> > 
> > BR,
> > 
> > Eduardo Valentin
> > 
> > [1] - http://comments.gmane.org/gmane.linux.kernel.iio/19627
> > 
> > 
> > 
> > _______________________________________________
> > Ksummit-discuss mailing list
> > Ksummit-discuss@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> > 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Eduardo Valentin]

[-- Attachment #1: Type: text/plain, Size: 4880 bytes --]

Hey Guenter!

On Tue, Aug 25, 2015 at 07:03:35AM -0700, Guenter Roeck wrote:
> On 08/24/2015 11:26 PM, Krzysztof Kozlowski wrote:
> >On 25.08.2015 15:12, Eduardo Valentin wrote:
> >>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.
> >
> >I would rather expect using only one subsystem for exporting this
> >information to user-space. If the susbsytem lacks some features then it
> >could be expanded.
> >
> >Some power supply drivers (fuel gauges or chargers) also provide
> >temperature data. They use the thermal for that. It would be weird to
> >export them through IIO...
> >
> 
> I agree, the current situation is less than optimal.
> 
> There are bridges from thermal and iio to hwmon, but they are not
> perfect. Resulting hwmon device names are odd, and iio doesn't support
> limits. The thermal-hwmon bridge only supports one trip point, and
> it doesn't pass alarms.
> 
> Both the iio-hwmon and the thermal-hwmon bridge break the hwmon model
> of reporting sensor data per chip, which makes it difficult to convert
> drivers from hwmon to thermal (if that is suggested) without breaking
> the userspace ABI.
> 
> At the same time, there is no bridge from the hwmon core to thermal.
> Currently hwmon drivers supporting thermal register with both hwmon
> and thermal, which is really undesirable. Implementing a hwmon-thermal
> bridge in the hwmon core would require implementing a new hwmon registration
> API. That is easier said then done, and would require more time than
> at least I have available.

Yes, we do have some bridges in place, and more coming (as thermal-iio
RFC). I just would like to have a more coordinated or a better overall
agreegation of these bridges. Specially to avoid breaking
compatibility, as you mentioned in the existing thermal-hwmon, and
iio-hwmon cases. This is the original motivation of this proposal,
define a clear path for this overlap.

> 
> This, I think, is the core of the problem. Somehow would have to go in
> and create that new hwmon registration API, if that is a solution
> acceptable to the thermal maintainers. At the same time, the thermal-hwmon
> bridge should be improved to export provide available information to hwmon.
> 


I don't think this is much of a concern from thermal subsystem, mainly
because most of the work would be first at the hwmon side.

On the other hand, I definitely agree that we need to sit down and
architecture what are the needed shared information between the
subsystems. And on top of that, how do we present them to userspace?
To avoid, for instance, having a half baked hwmon device showing up in
sysfs, if that is coming from thermal.

> An alternative would be for thermal to 'take over', convert all hwmon
> drivers to thermal drivers, and retain a compatibility layer to provide
> the data as hwmon device data to user space without breaking the existing
> hwmon ABI. Again, someone would have to do that work.
> 

This is more in the direction of having a single subsystem to perform
the task of monitoring temperature. The amount of work will be similar
in either cases above, I would say. There is no simple way out, we would
need to touch all drivers. 

Of course, this is a view in the hwmon <-> thermal case, but we need to
consider the iio interactions too. This is why I though of starting this
topic :-)

I think a first step would be to clarify the data that would be needed
to be shared between the subsystems. What are the involved callbacks,
and monitoring modes? Once that is clear enough, we can properly design
and write better bridges across the three subsystems. A latter step
would be to discuss the convergence, if needed at all, to a single way
of monitoring temperature (within kernel and userspace). 

> Guenter
> 

BR,

Eduardo Valentin

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [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

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

[Guenter Roeck]

On Tue, Aug 25, 2015 at 11:31:46PM +0200, Heiko Stuebner wrote:
> 
> 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.
> 
Yes, I have heard that before.

Its scope is quite different, though. One does thermal management, one monitors
the hardware. Monitoring the hardware is a bit more than just monitoring its
temperature. It also means to monitor and report voltages, current, power,
energy, humidity, and fan speeds, as well as associated alarms. Thermal
management takes an active role, hardware monitoring by its nature doesn't.

On top of that, many devices report much more than temperatures.
System managers may report and sometimes control all of the above. SuperIO
chips monitor voltages, temperatures, and fan speeds, and often implement fan
control. PMBus devices primarily control voltages, but may report literally
everything except for humidity (including fan speeds). And so on. 

Maybe just have a look into drivers/hwmon/pmbus/ltc2978.c, and let me know
where you would like to have this driver (and all the other PMBus drivers)
moved to.

Thanks,
Guenter

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

[Eduardo Valentin]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

On Tue, Aug 25, 2015 at 04:55:18PM -0700, Guenter Roeck wrote:
> On Tue, Aug 25, 2015 at 11:31:46PM +0200, Heiko Stuebner wrote:
> > 
> > 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.
> > 
> Yes, I have heard that before.

And that is a misconception, I would say, as both have different design
goals. Keep in mind that my original proposal is to discuss what touches
the monitoring part.

> 
> Its scope is quite different, though. One does thermal management, one monitors
> the hardware. Monitoring the hardware is a bit more than just monitoring its
> temperature. It also means to monitor and report voltages, current, power,
> energy, humidity, and fan speeds, as well as associated alarms. Thermal
> management takes an active role, hardware monitoring by its nature doesn't.

I agree here. Also, keep in mind that the scope of thermal subsystem is
not only monitor temperature, but also cover what needs to be done when
the system state changes and needs action, typically on top of
temperature thresholds/trip points.

> 
> On top of that, many devices report much more than temperatures.
> System managers may report and sometimes control all of the above. SuperIO
> chips monitor voltages, temperatures, and fan speeds, and often implement fan
> control. PMBus devices primarily control voltages, but may report literally
> everything except for humidity (including fan speeds). And so on. 


There are discussions to have power / voltage / current (and humidity
too) inputs to the thermal subsystem. And that's probably where the issue
gets worse. Another take we could have is to centralize the hw monitoring
part of the problem in, well, hwmon, and make thermal a user of it. Then
we would move the thermal drivers, at least the sensing part of
them, to hwmon. But then again, we still have the IIO case :-).

BR,

Eduardo Valentin
> 
> Maybe just have a look into drivers/hwmon/pmbus/ltc2978.c, and let me know
> where you would like to have this driver (and all the other PMBus drivers)
> moved to.



> 
> Thanks,
> Guenter
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Guenter Roeck]

On 08/25/2015 05:12 PM, Eduardo Valentin wrote:
> On Tue, Aug 25, 2015 at 04:55:18PM -0700, Guenter Roeck wrote:
>> On Tue, Aug 25, 2015 at 11:31:46PM +0200, Heiko Stuebner wrote:
>>>
>>> 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.
>>>
>> Yes, I have heard that before.
>
> And that is a misconception, I would say, as both have different design
> goals. Keep in mind that my original proposal is to discuss what touches
> the monitoring part.
>

Is that still true for thermal ? I have the impression that there is
a desire to move the monitoring part into thermal.

>>
>> Its scope is quite different, though. One does thermal management, one monitors
>> the hardware. Monitoring the hardware is a bit more than just monitoring its
>> temperature. It also means to monitor and report voltages, current, power,
>> energy, humidity, and fan speeds, as well as associated alarms. Thermal
>> management takes an active role, hardware monitoring by its nature doesn't.
>
> I agree here. Also, keep in mind that the scope of thermal subsystem is
> not only monitor temperature, but also cover what needs to be done when
> the system state changes and needs action, typically on top of
> temperature thresholds/trip points.
>
>>
>> On top of that, many devices report much more than temperatures.
>> System managers may report and sometimes control all of the above. SuperIO
>> chips monitor voltages, temperatures, and fan speeds, and often implement fan
>> control. PMBus devices primarily control voltages, but may report literally
>> everything except for humidity (including fan speeds). And so on.
>
>
> There are discussions to have power / voltage / current (and humidity
> too) inputs to the thermal subsystem. And that's probably where the issue
> gets worse. Another take we could have is to centralize the hw monitoring
> part of the problem in, well, hwmon, and make thermal a user of it. Then
> we would move the thermal drivers, at least the sensing part of
> them, to hwmon. But then again, we still have the IIO case :-).
>

My suggestion would have been to separate subsystems into logical entities.
Let thermal handle thermal policies and decisions, let hwmon read (and write)
low speed sensor values, let iio handle high speed io, and interconnect it all
with sensible APIs.

However, it seems to me that the direction in the thermal community
is more along the line of handling both monitoring and the decision
making process in thermal (and maybe some of it in iio). Or, in other
words, to rewrite all hwmon drivers, give them a new API, and move them
into, say, drivers/thermal/chips/.

I personally think that this might not be such a good idea, as it will
distract the thermal subsystem from its original focus. But the focus
may be shifting, or maybe I am just plain wrong.

Given that, I would not object if that is where things are going.
All I am asking for is to keep supporting the existing ABI.

Thanks,
Guenter

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

[Jonathan Cameron]

[-- Attachment #1: Type: text/plain, Size: 4355 bytes --]



On 26 August 2015 01:12:31 BST, Eduardo Valentin <edubezval@gmail.com> wrote:
>On Tue, Aug 25, 2015 at 04:55:18PM -0700, Guenter Roeck wrote:
>> On Tue, Aug 25, 2015 at 11:31:46PM +0200, Heiko Stuebner wrote:
>> > 
>> > 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.
>> > 
>> Yes, I have heard that before.
>
>And that is a misconception, I would say, as both have different design
>goals. Keep in mind that my original proposal is to discuss what
>touches
>the monitoring part.
>
>> 
>> Its scope is quite different, though. One does thermal management,
>one monitors
>> the hardware. Monitoring the hardware is a bit more than just
>monitoring its
>> temperature. It also means to monitor and report voltages, current,
>power,
>> energy, humidity, and fan speeds, as well as associated alarms.
>Thermal
>> management takes an active role, hardware monitoring by its nature
>doesn't.
>
>I agree here. Also, keep in mind that the scope of thermal subsystem is
>not only monitor temperature, but also cover what needs to be done when
>the system state changes and needs action, typically on top of
>temperature thresholds/trip points.
>
>> 
>> On top of that, many devices report much more than temperatures.
>> System managers may report and sometimes control all of the above.
>SuperIO
>> chips monitor voltages, temperatures, and fan speeds, and often
>implement fan
>> control. PMBus devices primarily control voltages, but may report
>literally
>> everything except for humidity (including fan speeds). And so on. 
>
>
>There are discussions to have power / voltage / current (and humidity
>too) inputs to the thermal subsystem. And that's probably where the
>issue
>gets worse. Another take we could have is to centralize the hw
>monitoring
>part of the problem in, well, hwmon, and make thermal a user of it.
>Then
>we would move the thermal drivers, at least the sensing part of
>them, to hwmon. But then again, we still have the IIO case :-).

At least for temperature monitoring with temp specific sensors, right now IIO
 doesn't really have any overlap. 
We do have temp sensors as part of IMUs and humidity sensors plus a few unusual 
temp sensors (remote IR sensors and high speed thermo couple devices)

The iio hwmon bridge was meant for case where a fast ADC happens to be
used for a slow hwmon job.

As I understand it, the proposed IIO interface for thermal is due to a need 
for a low overhead fat pipe to userspace governors. 

Current bit IIO doesn't do that are relevant:
1) event access within the kernel (trip points?) Userspace interface been present from the start.
2) multiple trip points of the same type.
(Not a big addition but not relevant for
 our core use cases and mostly only present on hwmon chips)

Note ultimate intent for a long time has been to fully separate IIO backend and
 frontend (userspace interface). No one has had time to work on this for a while
 though. So right now you can sit what you like on IIO but the IIO interface will be
 there as well, if unused.

Speaking of which, don't forget the other overlapping subsystems.

E.g. input and battery/power. 
We have a non mainline input bridge and
 a few users for battery monitoring in mainline.

At the end of the day lots of things (fast and slow) can be wired up to ridiculous rate ADCs. Not unusual on SOCs for a
 1Msp ADC to be used to read the battery voltage.

Plus there will always be someone out there using a £1000+ IMUs in their gaming rig 

Jonathan


>
>BR,
>
>Eduardo Valentin
>> 
>> Maybe just have a look into drivers/hwmon/pmbus/ltc2978.c, and let me
>know
>> where you would like to have this driver (and all the other PMBus
>drivers)
>> moved to.
>
>
>
>> 
>> Thanks,
>> Guenter
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 5374 bytes --]