FP3 Thermal HAL non-functional: missing SEPolicy + incorrect trip point index

Participate Development
1

I’m posting here in order to get some attention from the devs on this issue since other ways of reaching out have hit dead-ends. I’ll be publishing fixed source code shortly as well. I hope this will resolve some corner cases around usability and performance of the device.

Symptom

- a persistent thermal critical event, as can be seen on `adb shell dumpsys thermalservice`

- Scheduled JobScheduler/WorkManager jobs may not run because of thermal status

Cause

The issue is two fold.

1. Missing SEPolicy for thermal HAL.

I see that Qualcomm did not originally provide thermal HAL 2.0 implementation for this hardware and support is added by fairphone link. But SEPolicy was not applied.

Notably this file link is not included in the device SEPolicy.

As a result, thermal status is not updated when kernel sends the event update and is not reset at the right time, if at all. The thermal status is only updated when ThermalUtils::readTemperatures is called by the framework, which is very infrequent. Further, because there is no permission to write to /sys/class/thermal/thermal_zone%d/trip_point_1_temp and /sys/class/thermal/thermal_zone%d/trip_point_1_hyst, the kernel thermal event definitions (what it considers critical temperature) are out of sync with the HAL’s.

2. Mismatch of kernel device config between kernel and HAL

Some kernel thermal zone device does not have trip_point_1_temp and trip_point_1_hyst. This will become clear once SEPolicy is added and HAL attempts to write to these files.

Some /sys/class/thermal/thermal_zone%d only have trip_point_0_temp, but the HAL always writes to trip_point_1_temp and trip_point_1_hyst, which will fail. This means the kernel thermal event definition is still out of sync with the HAL’s.

Recommended actions

1. Include file in build files.

2. Patch thermal HAL to use trip_point_0_temp and trip_point_0_hyst.

2

Devs are normally not reading here and support for the FP3 ended just a few days ago, so I dont think FP will do anything.

So maybe at first pinging @TeamB58 if you have any info or ideas?

3

Thanks for the ping. SEPolicy support was indeed added via this commit and there was nothing obvious found in the logs.

But yes, as @yvmuell pointed out, FP3 received it’s last software update and unfortunately nothing can be done on the official release side. But still, it can be addressed from software side and a locally generated build(without GMS) can be flashed and used.

Feel free to submit the patch to gerrit or share here. At the moment I can’t confirm because there isn’t enough data/logs in OP.

Thanks.

4

You can see the problem on a rooted device.

  1. Set persist.log.tag.android.hardware.thermal@2.0-service.qti to v to enable logging
$ adb shell getprop | grep log.tag
[persist.log.tag.android.hardware.thermal@2.0-service.qti]: [v]
  1. Enabled “always trust device” or something like that on the adb authorization dialog so you can get logs as the device boots
  2. Run adb logcat | grep "android.hardware.thermal@2.0-service.qti", then boot the device

All the sensor tripping temperatures will fail to be configured. For example, you can see the following logs

03-30 10:25:42.004   617   617 D android.hardware.thermal@2.0-service.qti: Entering initThreshold
03-30 10:25:42.004   617   617 D android.hardware.thermal@2.0-service.qti: Path:/sys/class/thermal/thermal_zone0/policy Val:user_space
03-30 10:25:42.004   617   617 D android.hardware.thermal@2.0-service.qti: Sensor: skin high trip:40000
03-30 10:25:42.004   617   617 E android.hardware.thermal@2.0-service.qti: Error opening file: /sys/class/thermal/thermal_zone0/trip_point_1_temp

This sensor reads the device skin temperature.

You can verify on adb shell that /sys/class/thermal/thermal_zone0/trip_point_1_temp does not exist, but trip_point_0_temp does.

You can read the content of /sys/class/thermal/thermal_zone0/trip_point_0_temp and see that it is mismatched with the value 40000 expected by the HAL.

adb shell "cat /sys/class/thermal/thermal_zone0/trip_point_0_temp"
65000

You can also see

03-30 10:25:42.023   617   644 E android.hardware.thermal@2.0-service.qti: socket creation error:13

which comes from the kernel message monitor (link). This means the HAL cannot get thermal event triggers from the kernel. Instead, the HAL relies on a pulling method to update thermal status whenever there is a API call.

These two problems combined will manifest as a persistent critical thermal event in the system once:

  • skin temperature reaches above 40 C
  • An API call reads the thermal status, causing it to update to critical
  • As a result, various system functions are throttled down (JobManager timer events could be disabled, think periodic notifications etc)
  • Status will not reset even if temperature comes down, unless another API call reads the thermal status. Kernel event triggers will not reach the HAL, because the tripping temperature are different between kernel and HAL. Kernel will trip at 65 while HAL already tripped at 40. Sepolicy also prevents HAL from receiving those events.

FIX

  1. Include this sepolicy file in the makefile
  2. Change trip_point_1_temp and trip_point_1_hyst to trip_point_0_temp and trip_point_0_hyst in here