Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip points

[Matthew Longnecker <mlongnecker@nvidia.com>]

On 7/1/2014 11:15 AM, Stephen Warren wrote:
> On 07/01/2014 01:27 AM, Mikko Perttunen wrote:
>> >Inline.
>> >
>> >On 01/07/14 00:08, Stephen Warren wrote:
>>> >>On 06/27/2014 02:11 AM, Mikko Perttunen wrote:
>>>> >>>This adds support for hardware-tracked trip points to the device tree
>>>> >>>thermal sensor framework.
>>>> >>>
>>>> >>>The framework supports an arbitrary number of trip points. Whenever
>>>> >>>the current temperature is updated, the trip points immediately
>>>> >>>below and above the current temperature are found. A sensor driver
>>>> >>>callback `set_trips' is then called with the temperatures.
>>>> >>>If there is no trip point above or below the current temperature,
>>>> >>>the passed trip temperature will be LONG_MAX or LONG_MIN respectively.
>>>> >>>In this callback, the driver should program the hardware such that
>>>> >>>it is notified when either of these trip points are triggered.
>>>> >>>When a trip point is triggered, the driver should call
>>>> >>>`thermal_zone_device_update' for the respective thermal zone. This
>>>> >>>will cause the trip points to be updated again.
>>>> >>>
>>>> >>>If the `set_trips' callback is not implemented (is NULL), the framework
>>>> >>>behaves as before.
>>> >>
>>> >>Is there no "core thermal" code? I would have expected this new feature
>>> >>to be implemented in "core" code rather than of/dt "support" code.
>>> >>Perhaps there would also be some additions to the of/dt code, but I'd
>>> >>still expect the bulk of the feature to be complete independant of
>>> >>of/dt. Systems still using board files or ACPI or ... would surely
>>> >>benefit from this too?

Stephen, the "core thermal code" defined two major object types:
  * a thermal zone
  * a cooling device

Each thermal zone corresponds to a physical region in space within a 
device. A sane person might expect there to be one physical temperature 
sensor associated with each zone. But, that's not always the case.

Because the thermal core did not expose the concept of a "sensor" 
separately from a "zone", many drivers which register thermal zones are 
messy -- they include a mix of device driver code (i.e. poking at 
register for a thermal sensor IP block) and device-agnostic code for 
implementing behaviors required of a thermal zone.

of-thermal does more than just parse device tree. It registers thermal 
zones using its own implementation of that device-agnostic code. Having 
that centralized implementation of the thermal zone code allows thermal 
sensor device drivers which talk to of-thermal to be simpler than 
drivers which try to talk directly to the thermal core.

The fact that you need to use DT to make use of the simpler sensor 
driver interface doesn't seem like a good reason to push back on Mikko's 
change.

-Matt