lkml.org 
[lkml]   [2020]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[RFC][PATCH 0/5] thermal: Add new mechanism to get thermal notification
    Date
    I presented this idea during LPC 2018.
    Refer to the following link:
    https://linuxplumbersconf.org/event/2/contributions/182/attachments/38/45/LPC_2018_Thermal-Srinivas-Rui.pdf
    There was broad agreement about this.

    At that time, there was no use case for non x86 systems. But now there is
    interest from Linaro community. But this doesn't meet all the requirement for
    Linaro use cases. So I think, Daniel Lezcano <daniel.lezcano@linaro.org> is working
    on a follow up series.

    Thermal actions can be categorized in three types:
    1. Urgent actions in micro to less than milli second range
    2. Actions at milli seconds scale
    3. Non urgent actions but improves thermal management, which improves long
    term reliability of the system and also allow to meet safety standards

    The first category of actions usually handled by the hardware and firmware to
    meet the time scale. Some examples are sudden spike of CPU temperature which
    needs immediate action.

    Second category of actions are done at OS kernel level. Like graceful shutdown
    of a system, when a critical temperature is reached. Also a good place to take
    takes actions where there is a direct correlation from a thermal source to a
    cooling action (one to one relationship). The Linux thermal subsystem has in
    built governors to bind thermal zones to cooling devices.

    The third category acts at a scale of several seconds. This types of actions
    primarily focused for non CPU components, which takes time to heat up but
    once hot will take long time to cool. Like skin temperature or board
    temperature. Also there is no one to one relationship. For example skin can be
    hot, not only by CPU processing, but GPU, displays, networking, charger and
    ambient temperature etc. There are some thermally constraint laptops with 15+
    sensors and complex thermal relationship tables tying thermal hotspots to
    groups of devices. Also these relationships and threshold changes are context
    aware. This is done primary from user space thermal management programs. These
    programs primarily relies on the thermal sysfs for getting temperature samples
    and to get other notifications of change.

    There are several limitations of the thermal subsystem, which makes the user
    space management inefficient and complex.
    - Temperature needs to be polled from sysfs
    There is no way to set thermal thresholds and get notifications. We are getting
    around by using the passive trips as threshold and using user space governor to
    send uevents. The uevent is used for other non thermal events also. We have
    special strings to notify temperature samples.
    - We have platforms with 15+ zones, where we need to traverse each directory read
    "temp" string and convert to integer to process every second in some cases
    - For hotpluggable devices the zones can appear and disappear on fly. We have
    to again listen to uevents to find out that.
    - Based on the context, firmware updates temperature trips, again combination of
    user space governor and uevents are used as workaround.

    To be more flexible here /dev/thermal_notify device is created, where user
    space can wait for notifications and read events and data. A standard structure
    for notifications is defined. Based on the zone, additional thermal sysfs
    attributes are added to specify thresholds. More events and attributes can be
    added in future based on need. If the kernel config is not defined, there are
    are no additional thermal sysfs attributes.

    This patchset contains
    - A new config for creation of the /dev interface
    - Use of the new interface in the core for zone creation, deletion and
    temperature samples
    - Use of the framework in int340x drivers. More will be added in the next series

    This series is based on 4.7-rc1

    Srinivas Pandruvada (5):
    thermal: Add support for /dev/thermal_notify
    thermal: Add notification for zone creation and deletion
    thermal: Add support for setting notification thresholds
    thermal: Add support for setting polling interval
    thermal: int340x: Use new device interface

    drivers/thermal/Kconfig | 9 +
    drivers/thermal/Makefile | 3 +
    .../intel/int340x_thermal/int3403_thermal.c | 3 +
    .../int340x_thermal/int340x_thermal_zone.c | 29 +++
    .../int340x_thermal/int340x_thermal_zone.h | 7 +
    .../processor_thermal_device.c | 1 +
    drivers/thermal/thermal_core.c | 11 +
    drivers/thermal/thermal_dev_if.c | 195 ++++++++++++++++++
    drivers/thermal/thermal_sysfs.c | 168 ++++++++++++++-
    include/linux/thermal.h | 33 +++
    10 files changed, 457 insertions(+), 2 deletions(-)
    create mode 100644 drivers/thermal/thermal_dev_if.c

    --
    2.25.4

    \
     
     \ /
      Last update: 2020-05-04 20:17    [W:4.261 / U:0.348 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site