linux-toradex.git/drivers/thermal/thermal_core.c, branch v4.9.123

thermal: Enhance thermal_zone_device_update for events

2016-09-27T06:35:21+00:00

Added one additional parameter to thermal_zone_device_update() to provide
caller with an optional capability to specify reason.
Currently this event is used by user space governor to trigger different
processing based on event code. Also it saves an additional call to read
temperature when the event is received.
The following events are cuurently defined:
- Unspecified event
- New temperature sample
- Trip point violated
- Trip point changed
- thermal device up and down
- thermal device power capability changed

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Zhang Rui

thermal: Add support for hardware-tracked trip points

2016-09-27T06:02:16+00:00

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 .set_trips
callback is then called with the temperatures. If there is no trip
point above or below the current temperature, the passed trip
temperature will be -INT_MAX or INT_MAX 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 .set_trips is not implemented, the framework behaves as before.

This patch is based on an earlier version from Mikko Perttunen


Signed-off-by: Sascha Hauer 
Signed-off-by: Caesar Wang 
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Cc: linux-pm@vger.kernel.org
Reviewed-by: Javi Merino 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Zhang Rui

thermal: core: export apis to get slope and offset

2016-09-27T06:02:16+00:00

Add apis for platform thermal drivers to query for slope and offset
attributes, which might be needed for temperature calculations.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Zhang Rui

thermal: fix race condition when updating cooling device

2016-08-08T02:57:39+00:00

When multiple thermal zones are bound to the same cooling device, multiple
kernel threads may want to update the cooling device state by calling
thermal_cdev_update(). Having cdev not protected by a mutex can lead to a race
condition. Consider the following situation with two kernel threads k1 and k2:

	    Thread k1				Thread k2
                                    ||
                                    ||  call thermal_cdev_update()
                                    ||      ...
                                    ||      set_cur_state(cdev, target);
    call power_actor_set_power()    ||
        ...                         ||
        instance->target = state;   ||
        cdev->updated = false;      ||
                                    ||      cdev->updated = true;
                                    ||      // completes execution
    call thermal_cdev_update()      ||
        // cdev->updated == true    ||
        return;                     ||
                                    \/
                                    time

k2 has already looped through the thermal instances looking for the deepest
cooling device state and is preempted right before setting cdev->updated to
true. Now, k1 runs, modifies the thermal instance state and sets cdev->updated
to false. Then, k1 is preempted and k2 continues the execution by setting
cdev->updated to true, therefore preventing k1 from performing the update.
Notice that this is not an issue if k2 looks at the instance->target modified by
k1 "after" it is assigned by k1. In fact, in this case the update will happen
anyway and k1 can safely return immediately from thermal_cdev_update().

This may lead to a situation where a thermal governor never updates the cooling
device. For example, this is the case for the step_wise governor: when calling
the function thermal_zone_trip_update(), the governor may always get a new state
equal to the old one (which, however, wasn't notified to the cooling device) and
will therefore skip the update.

CC: Zhang Rui 
CC: Eduardo Valentin 
CC: Peter Feuerer 
Reported-by: Toby Huang 
Signed-off-by: Michele Di Giorgio 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui

thermal: use %d to print S32 parameters

2016-04-27T22:54:51+00:00

Power allocator's parameters are S32 type, so use %d to print them.

Acked-by: Javi Merino 
Signed-off-by: Leo Yan 
Signed-off-by: Eduardo Valentin

thermal: consistently use int for trip temp

2016-04-21T03:31:14+00:00

The commit 17e8351a7739 consistently use int for temperature,
however it missed a few in trip temperature and thermal_core.

In current codes, the trip->temperature used "unsigned long"
and zone->temperature used"int", if the temperature is negative
value, it will get wrong result when compare temperature with
trip temperature.

This patch can fix it.

Signed-off-by: Wei Ni 
Signed-off-by: Eduardo Valentin

Thermal: Ignore invalid trip points

2016-03-18T06:10:57+00:00

In some cases, platform thermal driver may report invalid trip points,
thermal core should not take any action for these trip points.

This fixed a regression that bogus trip point starts to screw up thermal
control on some Lenovo laptops, after
commit bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461
Author: Zhang Rui 
Date:   Fri Oct 30 16:31:47 2015 +0800

    Thermal: initialize thermal zone device correctly

    After thermal zone device registered, as we have not read any
    temperature before, thus tz->temperature should not be 0,
    which actually means 0C, and thermal trend is not available.
    In this case, we need specially handling for the first
    thermal_zone_device_update().

    Both thermal core framework and step_wise governor is
    enhanced to handle this. And since the step_wise governor
    is the only one that uses trends, so it's the only thermal
    governor that needs to be updated.

    Tested-by: Manuel Krause 
    Tested-by: szegad 
    Tested-by: prash 
    Tested-by: amish 
    Tested-by: Matthias 
    Reviewed-by: Javi Merino 
    Signed-off-by: Zhang Rui 
    Signed-off-by: Chen Yu 

CC:  #3.18+
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551
Signed-off-by: Zhang Rui

Merge branches 'thermal-intel', 'thermal-suspend-fix' and 'thermal-soc' into next

2016-01-23T03:43:27+00:00

thermal: trip_point_temp_store() calls thermal_zone_device_update()

2016-01-07T02:06:39+00:00

trip_point_temp_store() updates trip temperature. It should call
thermal_zone_device_update() immediately.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Eduardo Valentin

Thermal: do thermal zone update after a cooling device registered

2015-12-29T08:00:00+00:00

When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.

This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.

Here is the history of why current patch looks like this:
https://patchwork.kernel.org/patch/7273041/

CC:  #3.18+
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431
Tested-by: Manuel Krause 
Tested-by: szegad 
Tested-by: prash 
Tested-by: amish 
Reviewed-by: Javi Merino 
Signed-off-by: Zhang Rui 
Signed-off-by: Chen Yu