RE: [linux-pm] [RFC] the generic thermal layer enhancement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hi Rui,

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

Yes we should do that. I would also like to remove these values from the
registration API's. That makes the registration code way more simpler.
Right now, I do not see any driver using thermal_zone_device_register
with values other than 0's for these.

> G4. Multiple passive trip points
>     I get this idea also from the patches at
>     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:

Or just use 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;

I agree with you here...


To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Site Home]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Rubini]     [Photo]     [Yosemite Photos]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux