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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
