Supporting thermal sensors on ipq806x

For Developers
21

Yep.
I managed to grab your new code and compile, but /sys/class/thermal remains empty.

But it looked like more realistic, as there were just 4 sensors defined instead of 11.

22

11 sensors are real, I can put more up to 11. If you check every thermal zone is represented with slope value same as, my 1St patch, but seperately

23

I am still not quite sure about that. There was some OEM documentation in the patches for Linux kernel, which suggested that the driver supports 11 sensors, while SoC may only use 5 of them. https://patchwork.kernel.org/patch/7360531/

+Optional properties:
+- qcom,sensor-id: List of sensor instances used in a given SoC. A TSENS IP can

  •   have a fixed number of sensors (like 11) but a given SoC can

  •   use only 5 of these and they might not always the first 5. They

  •   could be sensors 0, 1, 4, 8 and 9. This property is used to

  •   describe the subset of the sensors used. If this property is

  •   missing they are assumed to be the first 'n' sensors numbered

  •   sequentially in which case the number of sensors defaults to

  •   the number of slope values.

That was apparently changed before upstream acceptance, so that now the sensors are defined a bit differently, probably with items like the thermal-sensors = <&gcc 7>;

The dts extract that you tried to apply to 8065 was from the upstream apq8064 dts file, right?
(e.g. https://lkml.org/lkml/2016/7/12/43 )
But if I read that right, it seems to suggest the apq8064 uses sensors 7,8 ,9 and 10.

So I still see a possibility that there seems to be 11 sensors in the driver, but not all of those are real on each SoC. Or have you seen somewhere more detailed data for ipq8065? I tried to look for it, but did not find.

24

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...

25

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

26

And it doesn't work either...

27

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

28

@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.

29

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.

30

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

31

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.

32

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

Really thank you for testing :slight_smile:

34

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

35

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:

36

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

37

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

I'll do some cleaning and update the PR

38

Check this one out, it works :slight_smile:

39

@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.

40

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

41

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: