Hi Rui,
First, thank you very much for taking the time to answer!
Le 27 juillet 2016, Zhang Rui a écrit :
As you have mentioned thermal.c, I think you are using ACPI thermal
control on your platform, right?
trip_point_?_hyst files are created by thermal core, if the platform
thermal driver supports hysteresis, and ACPI thermal driver, which is
used in your case, does not support hysteresis.
I don't know what my system is using. In fact I know nothing about ACPI. I
couldn't find documentation (which doesn't mean there is no doc, just I
couldn't find it) explaining how this works. So I tried to guess,
gathering pieces of information by observing the behaviour of files in
/sys, and looking into code (but not being sure this code is relevant to
my system!).
What I can say (I still don't know if it is valuable info):
- there is no hwmon/ directory anywhere under /sys,
- the thermal_zone* and cooling_device* directories are in
/sys/devices/virtual/thermal.
how are trip point temperatures set at boot,
ACPI thermal driver gets the trip point temperature information from
ACPI tables.
So, from some computer firmware.
and how are they reset when crossed?
Usually, ACPI trip point is not reset when crossed, but it does
have granularity, which determines when to generate a
temperature change notification.
Say, for a platform that the trip point temperature is 50C, and
granularity is 5C, when the ACPI thermal driver receives a notification
at 50C, it starts to spin the fan.
Then next time when the ACPI thermal driver gets a temperature change
notification, the temperature is either 55C, which means we need to
take further action to cool the system, or the temperature is 45C and
we can turn off the fan.
In some cases, the trip point may get reset. You can refer to section
11.1.2 in ACPI spec 6.1. IN this case, a trip point change notification
will be sent to thermal driver, and ACPI thermal driver will re-
evaluate the trip point control methods to get new trip point
temperature. But AFAICS, this is really rare.
Maybe I used the word "reset" inappropriately. Simply, I noticed the
contents of trip_point_4_temp changes from 50000 to 45000 when temp
reaches 50000 and the fan starts to spin. If the initial contents of
trip_point_4_temp is 60000 (thanks to the thermal.act kernel parameter),
it also changes to 45000 when temp reaches 60000 and the fan starts to
spin. So it looks like in my case the turn-off temperature of 45 °C is
chosen independently of the turn-on temperature. (And temp never gets down
to this so low value of 45, so fan spins endlessly...)
I'm aiming at changing the temperatures at which the fan starts and
stops. The kernel parameter thermal.act=XXX did change the "fan on"
temperature, but not the "fan off" one. I expected the hysteresis
T(on)-T(off) to be constant, and thus I thought T(off) would raise as
much as I raised T(on), but this is not the case.
Dynamic trip point can only be supported by platform thermal design.
Specifying such values in userspace does not make sense, because it's
not guaranteed that the thermal driver can get notification upon the
values you specified, thus it would screw up the thermal control
entirely.
Do you mean: if the system has a 5 °C granularity, and I had set
trip_point_4_temp to a value not multiple of 5 °C, say 53 °C, then the
driver would not e.g. turn off the fan when the temperature changes from
e.g. 55 to 50, because the driver does not check "temp <=
trip_point_4_temp" but rather "temp == trip_point_4_temp"?
Your insight and help is much appreciated.
Best regards,
Lucas Levrel
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
