Interrupt driven thermal OF sensors (was: [PATCH 2/3] lm90: initialize parameters from devicetree)

["Stéphan Kochen" <stephan-j6uo2F6POYhmR6Xm/wNWPw@public.gmane.org>]

On Fri, Jan 22, 2016 at 06:53:50PM -0800, Guenter Roeck wrote:
> The thermal subsystem supports setting trip points, which I would think
> is what you are looking for here. Question is if an how you can use the
> information from the thermal subsystem (and thus the thermal zone configuration)
> to set the various limits in the lm90 driver. This should hopefully be sufficient
> to fix your immediate problem. For handling alerts, I guess we'll have to wait for
> thermal subsystem improvements (unless of course you volunteer to do that work.

I may take a shot at this. So in short, the goal is to have a device
tree thermal zone communicate trip points to the sensor driver, and use
interrupts to act on trips.

(This indirectly solves my problem of my sensor having weird initial
values. Perhaps we also want a solution for this case if the thermal
subsystem is disabled, but for me there'd be no need.)

Here's what I see:

 - The thermal core layer already supports interrupt driven systems.
   Support is missing from thermal OF, the layer between thermal core
   and the sensor driver implementing device tree support.

 - Thermal OF registers a device in thermal core for each zone defined
   in the device tree.

 - In theory, a thermal zone in the device tree can have multiple
   sensors, and multiple zones can refer to the same sensor, but the
   current implementation only supports 1-on-1 relations.

 - There are already exports thermal_zone_device_update and
   thermal_notify_framework in thermal core, which allow external code
   to trigger an update.

 - Updates happen by explicit calls to such exports, or by an optional
   and configurable interval in thermal core.

What I think we want:

 - Any additions should be optional extensions implemented by sensor
   drivers. Polling should keep on working for all sensor drivers
   already supporting thermal OF, with no interface changes.

 - For interrupt-capable sensor drivers, the thermal OF device should
   keep the sensor driver updated with the current nearest trip
   temperature and hysteresis. (Don't burden drivers with a full list of
   trip points.)

 - In the case of LM90, this would set the low and high alert
   temperatures. LM90 can have additional alerts (critical, emergency),
   but a sensor driver registered with thermal OF should disable any
   additional alerts.

 - Similarly, a sensor driver should disable alerts when there is no
   current trip temperature or hysteresis. (E.g., we're below the lowest
   trip point.)

Implementation-wise:

 - The struct thermal_zone_of_device_ops needs an additional function to
   set the current sensor trip temperature and hysteresis. Presence of
   this function indicates the sensor driver has interrupt support.

 - The thermal OF device will call this function every time the
   temperature slides across trip points. (Or when trip points are
   altered.)

 - The thermal OF device should ignore the polling delay (set it to 0)
   if its sensor has interrupt support. (In this case, we can also make
   polling-delay optional. It's currently required in the device tree.)

 - On interrupt, the sensor driver should call
   thermal_zone_device_update with its thermal_zone_device, as returned
   by thermal_zone_of_sensor_register.

My only concern is that I don't understand kernel contexts and interrupt
handling well enough. It looks like at least its up to the sensor driver
to ensure calls into the thermal subsystem have long left the hardware
interrupt context, which I think should be sufficient.

Hoping all of this sounds about right!

-- 
Stéphan Kochen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html