Would you post to mainline as rfc as you can better explain behaviour?
Maybe as rfc first,and finally with CC:stable
Where did you find the max core temp?
Would you post to mainline as rfc as you can better explain behaviour?
Maybe as rfc first,and finally with CC:stable
Where did you find the max core temp?
Sureā¦ Where to post it?
Create patch with git format-patch, run through scripts/checkpatch.pl Get recipients (only lists+maintainer+reviewer) with scripts/get_maintainer.pl And send via git send-email
have wrote it down here (but comments only in german): https://www.fw-web.de/dokuwiki/doku.php?id=programming:git:start#git_format-patch
Send. Letās see if they apply the patch to the kernel.
At least there is a discussion open for the āhow is the right wayā
Have you tried the suggestion from daniel (passive to 70/75,active to 80/85)?
I replied but it was html so blocked in the mailing list.
It has no use to set frequency scaling on 2 different temperature trip points, as the lowest one makes sure the higher one(s) are never reached. It can be applied only at 1 trip point. Multiple trip points is only usefully for fan control to make sure the fan is not too noisy when it is not necessary to be noisy.
This is why it is a bug and needs a fix, not only adjustment.
Iāll see about an plain text Gmail client, cause on Android cannot switch Gmail to plain text. Then reply again in the mailing list. .
Basicly r64 has fan socket connected to pwm3 (inverted),but afaik it not represented in dts. If you know how to add it,we can use it for lower steps (passive,active) and leave the other 2 as cpu stepdown,if no fan connected or its cooling is not enough
Afair we need to add this to dts
fan0: pwm-fan {
compatible = "pwm-fan";
#cooling-cells = <2>;
pwms = <&pwm 2 10000 0>;
cooling-levels = <0 102 170 230>;
};
Maybe set last param of pwms to PWM_POLARITY_INVERTED
And of course add config option for pwm-fan (CONFIG_SENSORS_PWM_FAN=m)
if i add this to dtsi, i got this:
arch/arm64/boot/dts/mediatek/mt7622.dtsi:137.16-142.4: Warning (pwms_property): /pwm-fan: Missing property '#pwm-cells' in node /pwm@11006000 or bad phandle (referred from pwms[0])
i have added
#pwm-cells = <3>;
to the pwm-node, now error is gone, but i hope this does not break anything
if only bpi-r64 contains a fan-socket we can add fan in dts and override the cooling-trips with fan
added changes to https://github.com/frank-w/BPI-R2-4.14/tree/5.13-r64-fan
updated the branch above to have latest suggestions from Daniel applied (active before passive for r64 with fan and higher temps for passive and active)
i cannot test (mode 0 vs. inverted) fan because i have none with matching connector yet, imho for this we need at least 2 fan-steps, i do not fully understand itā¦in fan-definition we have 4 speeds (0-255), but only 1 trip point (active), so currently we do not see if fan speed is increasing or decreasing with increasing temp
For now I do not have any plans using a fan. The Bbp r64 is designed even without heatsinks. There can be 2 reasons.
They do not want to add a 5 cent piece of aluminum and choose to have the bpir64 running with limited performance
Or it simply does not need it, because it can run just fine without it.
I would like to hear from bananapi or Mediatek which one it is first, before implementing other solutions.
In the first kernel release of bananapi (4.4) there was no thermal zone defined at all. I.e. no throttling CPU frequency.
Could you test if settings without fan (mt7622.dtsi only) work for you?
I guess this is the best way getting upstream
I tried this:
thermal-zones {
cpu_thermal: cpu-thermal {
polling-delay-passive = <1000>;
polling-delay = <1000>;
thermal-sensors = <&thermal 0>;
trips {
cpu_passive: cpu-passive {
temperature = <70000>;
hysteresis = <2000>;
type = "passive";
};
cpu_active: cpu-active {
temperature = <60000>;
hysteresis = <2000>;
type = "active";
};
cpu_hot: cpu-hot {
temperature = <87000>;
hysteresis = <2000>;
type = "hot";
};
cpu-crit {
temperature = <107000>;
hysteresis = <2000>;
type = "critical";
};
};
cooling-maps {
map0 {
trip = <&cpu_passive>;
cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
<&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
map1 {
trip = <&cpu_active>;
cooling-device = <&cpu0 0 0>,
<&cpu1 0 0>;
};
map2 {
trip = <&cpu_hot>;
cooling-device = <&cpu0 0 0>,
<&cpu1 0 0>;
};
};
};
};
Passive trip higher then active trip in degrees. It works, temperature is regulated at 70 degrees with frequency throttling.
I however do not understand 70, 75 or even 80 degrees. The ;maximum junction temperature is 125 degrees. I cannot find documentation, but this should be the temperature where the soc itself is starting itās throttling to protect itself. Staying 35 degrees below this 125 degrrees Celcius should really be safe.
It would be such a waist if this nice soc is limited in performance in mainline kernel, because there is a hunch that 75 degrees is a nice temperature to regulate. Before the patch the soc is limited by a bug, and after it is limited by a hunchā¦ Not much improvementā¦
I tried bpi support contact email, if they know the correct temperature, but no reply yet.
here you disable trottling for active and hot thermal zones, thats why only at passive it is trottledā¦
have you tried my approach (iām waiting for a fan to test, but it should work without too)?
I donāt have a fan eitherā¦ but it should work
added fan to my board, but it is on at bootupā¦afair there was a problem i always have +5v on fan-port (remember that i see this on testing pwm)
@sinovoip, have you an idea why i always get 5V on FAN-port? in documentation this should be connected to pwm3 (2)
so what will be the best trotteling-setting without disabling any trip?
Do you know any per-cpu value for reading temp and freq?
i wonder why my r2 is not throttledā¦
echo "TEMP:" $(cat /sys/class/thermal/thermal_zone0/temp) " FREQ:" $(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq)
TEMP: 52713 FREQ: 1040000
so also over the passive trip (47 degrees, and all cpus are defined as cooling device)
mt7623n-bananapi-bpi-r2.dts does not contain any overrides for thermal-zones/cooling-devices
while comparing defconfigs, i guess on r2 i miss
CONFIG_CPU_THERMAL=y
if i enable this, i have same on r2ā¦trottling down on 47 degrees Celsius
root@bpi-r2:~# echo "TEMP:" $(cat /sys/class/thermal/thermal_zone0/temp) " FREQ:" $(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq)
TEMP: 47085 FREQ: 598000
root@bpi-r2:~# echo "TEMP:" $(cat /sys/class/thermal/thermal_zone0/temp) " FREQ:" $(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq)
TEMP: 47085 FREQ: 97999
root@bpi-r2:~#
Posted patch to increase passive trip to 57 degrees
https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
I was about to suggest checking kernel config, seems you found it already.
Too bad we did not hear anything from Mediatek or Bananapi as to which temperature to set these values to .
I have run my mt7622 on 88 degrees for several hours, build a kernel 5 or 6 times now. All builds successful, no problems at this temperature encountered yetā¦
This issue is reported to openwrt too (for mt7623):
I originally had thought that we could swap the first two trip point types and solve the problem, but looking more closely at the dtsi file I see that the first three trip points (passive, active, and hot) all refer to identical cooling maps which have unlimited CPU scaling as their only recourse.
I now believe the only real solution is to simply delete the first two trip points and cooling maps. There was some discussion of this earlier, I see, and I think it was hoped that Mediatek would weigh in on this issue. I donāt think we should wait. I have proposed a patch on the OpenWrt tracker for the MT7623 boards, and I think the same patch should be proposed upstream.
I considered trying to get fancy and have the first two trip points just be limited in the amount they scale, but the reality is, that neither 47Ā°C or even 67Ā°C are dangerous temperatures, so there is no need to even begin CPU throttling until 87Ā°C. Since the kernel will throttle the CPU speed all the way down to 98MHz if the temperature goes even a degree about the trip point, I believe this is an appropriate trip point.
Maybe a fan can be used in first 2 trips,but my tests with fan on r64 showing that fan was no real pwmā¦i have only on and off,did not know why as the mapping to pwm was right