Update and a correction: EC 3.5.8 works with the October SoC
Hey Christopher, an update, and a correction to what I posted earlier.
I wrote that the October SoC (2.158.15) locks owners out of EC 3.5.8. That was wrong. On Oct 25 we only tried the EC mailbox: our own module using nvfancontrol’s protocol (OEM1 command 17 and the shared page, through the SoC firmware’s FF-A eSPI service). Its very first read-only capability query timed out with eSPI status 5, and we jumped from “this path doesn’t work on this pairing” to “this pairing can’t take fan requests”. To be clear, that says nothing about your driver: yours goes through the EC packet relay, a different FF-A service, which we never tried on this mix.
What we skipped was ACPI: \_SB.FAN0/FAN1 _FSL through cooling_device*/cur_state, which the BIOS turns into an EC fan command with a target of 975 + 33.75 × level rpm. On EC 3.5.8 + SoC 2.158.15 it just works, no module needed:
- 100: both fans at 4,320 rpm (on 3.13.7 the same write is accepted and ignored)
- 40: ~2,270 rpm. 20: the second fan stalls. 0: both stop, so we never go below 40.
- 20 cores busy: 73 °C peak, ~60 °C settled (3.13.7: 92 °C and climbing)
- one write moves both fans on our unit; in the DSDT both devices go through the same method, which sets both fan targets
To your earlier question: on 3.13.7 our fans never went past ~3,090 rpm, even at 92 °C.
One difference worth noting: your driver sets a floor, so the EC can still add cooling on top. The ACPI level is a target that replaces the EC’s own curve, at least at normal temperatures, so the script has to do all the work. That’s why we keep a hard minimum of 40 and go to 100 on any error. On the June pair, your floor approach is the more conservative one.
Thanks again: your report that 3.5.8 works on your units is what sent us back to it. Full steps are in our thread: New DGX Spark: fans barely speed up at high temps and can't be adjusted. Critical. Please open fan control