[RFC] the generic thermal layer enhancement

[Zhang Rui <rui.zhang@intel.com>]

Hi, all,

It is great to see more and more users of the generic thermal layer.
But as we know, the original design of the generic thermal layer comes
from ACPI thermal management, and some of its implementation seems to be
too ACPI specific nowadays.

Recently I'm thinking of enhance the generic thermal layer so that it
works well for more platforms.

Below are some thoughts of mine, after reading the patches from Amit
Daniel Kachhap, and ACPI 3.0 thermal model. Actually, I have started
coding some RFC patches. But I do really want to get feedback from you
before going on.

G1. supporting multiple cooling states for active cooling devices.

    The current active cooling device supports two cooling states only,
    please refer to the code below, in driver/thermal/thermal_sys.c
                case THERMAL_TRIP_ACTIVE:
                        ...
                        if (temp >= trip_temp)
                                cdev->ops->set_cur_state(cdev, 1);
                        else
                                cdev->ops->set_cur_state(cdev, 0);
                        break;

    This is an ACPI specific thing, as our ACPI FAN used to support
    ON/OFF only.
    I think it is reasonable to support multiple active cooling states
    as they are common on many platforms, and note that this is also
    true for ACPI 3.0 FAN device (_FPS).

G2. introduce cooling states range for a certain trip point

    This problem comes with the first one.
    If the cooling devices support multiple cooling states, and surely
    we may want only several cooling states for a certain trip point,
    and other cooling states for other active trip points.
    To do this, we should be able to describe the cooling device
    behavior for a certain trip point, rather than for the entire
    thermal zone.

G3. kernel thermal passive cooling algorithm

    Currently, tc1 and tc2 are hard requirements for kernel passive
    cooling. But non-ACPI platforms do not have this information
    (please correct me if I'm wrong).
    Say, for the patches here
    http://marc.info/?l=linux-acpi&m=133681581305341&w=2
    They just want to slow down the processor when current temperature
    is higher than the trip point and speed up the processor when the
    temperature is lower than the trip point.

    According to Matthew, the platform drivers are responsible to
    provide proper tc1 and tc2 values to use kernel passive cooling.
    But I'm just wondering if we can use something instead.
    Say, introduce .get_trend() in thermal_zone_device_ops.
    And we set cur_state++ or cur_state-- based on the value returned
    by .get_trend(), instead of using tc1 and tc2.

G4. Multiple passive trip points

    I get this idea also from the patches at
    http://marc.info/?l=linux-acpi&m=133681581305341&w=2

    IMO, they want to get an acceptable performance at a tolerable
    temperature.
    Say, a platform with four P-states. P3 is really low.
    And I'm okay with the temperature at 60C, but 80C? No.
    With G2 resolved, we can use processor P0~P2 for Passive trip point
    0 (50C), and P3 for Passive trip point 1 (70C). And then the
    temperature may be jumping at around 60C or even 65C, without
    entering P3.

    Further more, IMO, this also works for ACPI platforms.
    Say, we can easily change p-state to cool the system, but using
    t-state is definitely what we do not want to see. The current
    implementation does not expose this difference to the generic
    thermal layer, but if we can have two passive trip points, and use
    p-state for the first one only... (this works if we start polling
    after entering passive cooling mode, without hardware notification)

G5. unify active cooling and passive cooling code

    If G4 and G5 are resolved, a new problem to me is that there is no
    difference between passive cooling and active cooling except the
    cooling policy.
    Then we can share the same code for both active and passive cooling.
    maybe something like:

    case THERMAL_TRIP_ACTIVE:
    case THERMAL_TRIP_PASSIVE:
         ...
         tz->ops->get_trend();
         if (trend == HEATING)
                 cdev->ops->set_cur_state(cdev, cur_state++);
         else if (trend == COOLING)
                 cdev->ops->set_cur_state(cdev, cur_state--);
         break;

Here are the gaps in my point of view, I'd like to get your ideas about
which are reasonable and which are not.

Any comments are appreciated! Thanks!

-rui