Supporting thermal sensors on ipq806x

If you check stock netgear firmware you'll notice exact 11sensors in completely same representation :slight_smile:
And I'm not sure what they mean under "used" - not used but available or not used and not available.

Yes, dts is from apq8064, the twin brother. Actually like 70-85% of stuff is cross- applicable directly or requires a small tuning.

Slope values are now in coefficients property that describes exact sensor for each thermal zone.

Meanwhile I've backported more patches, this time related to qfprom. Might also be it that prevents driver from parsing qfprom region.

If it doesn't help then it might need to backport a thermal driver itself, that's not an easy task...

Unfortunately there's no info other than what you have found.

And it doesn't work either...

I've modified the comit a bit: fixed correct qfprom offsets for ipq806x, switched to 1st 3 sensors instead of 7, 9 and smth, added the patch for gcc from chromium project. Could you test it please, I won't be able to do it for about a day

@dissent1
I tested your commit, and it seemed to create the three thermal_zones for R7800, but I could not read "temp" data from them. (additionally there are two "cooling_device" items.

Note that I tested that exact commit db1cebce . I notice that you have continued work on the branch, so the tip might produce different results. Please tell me again when you think that it should work.

1 more try, ported almost all related commits

If it doesn't work, then the problem is somewhere in dts or the tsens driver itself.

Added a patch that fixes build error wth CONFIG_PM off (it's on in my tree, so I haven't experienced this error)

I tested that 316de07f7 based patch, but it did not work.
currently compiling your next "not OEM" 4d1b8b564 version.
EDIT: and that does not work either. the "temp" data itself produces always a read error.

So far, only your first "full-celsius" solution works.

Bad news :confused: I'll play a bit more with DT

Really thank you for testing :slight_smile:

@dissent1
note that I have every time tested only the last "thermal commit". I have not pulled your whole sta12 branch.

Yes, that's correct.
For some reason it seems, that it can't parse qfprom region. /sys/class/thermal/thermal_zone*/offset shows incorrect value :confused:

I might have found a problem - there's type "nvmem-cells" should be with s in the end cellS

Yes, it works! Not the upstream one though. Shows in millicelsius.

I'll do some cleaning and update the PR

Check this one out, it works :slight_smile:

@dissent1
I will test it.
Currently compiling it, but just the plain 65fb10e0 without the two commits after it. A bit wondering, because those two commits touch partially the same things.

Those 2 commits are for testing purposes

Update: merged those 2 commits into the main commit, as those properties and patch were excessive, they do nothing.

There is a problem though, when I'm trying to choose tsens 0, 1, 2 or 1, 2, 3 in thermal zone in DTS and compile the firmware, so after i flash it the router doesn't boot up

Your 65fb10e0 seems to work fine. My R7800 boots up and shows /sys/class/thermal/thermal_zone[0-3]

console shows sensible values:

root@lede:/sys/devices/virtual/thermal/thermal_zone1# cat temp
51508
root@lede:/sys/devices/virtual/thermal/thermal_zone1# cat trip_point_*
2000
75000
passive
2000
95000
critical

Luci statistics picks up the temp correctly:

There's strange message in dmesg that tsens is not calibrated, seems it needs some tuning

I get the same message, I guess:

[    1.990990] qcom-tsens 900000.clock-controller:thermal-sensor@900000: tsens calibration failed

The core functionality seems to work, though.

I tested with launching two simultaneous "openssl benchmark" processes to make sure that both cores are fully utilised. CPU util jumped to 100% and temps ramped up rather nicely and Luci stats picked that up...

So I would say that it works to a large extent.

If I got it right, this is the first/original version of the upstream driver from 2015, which got several adjustments before getting accepted to upstream Linux in 2016.

May I ask your help here... R7800 is new for me and I have not bricked it so far. Lucky me.

But what is the best way to recover from a non-booting R7800, from a "bad flash"?
Is there a TFTP recovery mode to be triggered via button during boot (like in some older Netgear routers), or what you do?