Hi Rui,

Thanks for starting a discussion on further finetuning the thermal layer.

On 30 May 2012 16:49, Zhang Rui [off-list ref] wrote:

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.

Totally agreed :)

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).

Yes I agree that ACTIVE trip type should support more than 1(ON)
state. and which state the the set_cur_state should call depends on
how the state is binded on the trip point. But again in doing these
there is so much logic put in handling this that the I dropped the
patch for new trip type ACTIVE_INSTANCE.

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.

Agreed

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.

OK this seems fine. But for exynos platform(also some other platforms)
this may be simply cur_temp - last_temp which is fine.

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)

This seems cool and to answer Mathew doubt this is needed because in
the not so critical thermal envelop the platforms may not want to go
to the lowest opp level and some intermediate level is fine.

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;

Actually I still feels that ACTIVE and PASSIVE are needed because they
have different way of calling the set_cur_rate. ACTIVE trip type is
associated with 1 trip point so on reaching a trip point a specific
state is called in set_cur_state. But PASSIVE basically
increments/decrements the state depending on thermal trend.

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

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm