> On 04/04/2024 Armin Wolf wrote: > Am 04.04.24 um 10:37 schrieb Mikael Lund Jepsen: > >> We are using the Intel ElkhartLake CRB board and need to read the CPU Fan tacho signal from Linux userspace (so we can raise an application-level alert if fan is broken). >> >> The CPU Fan PWM output and tacho inputs are controlled by firmware running on the PSE controller (Cortex-M), which is embedded in the ElkhartLake SoC. >> The PSE Firmware contains an ECLite feature which updates the eclite_opregion.tacho_rpm field. This field is also declared in ACPI (offset 330) by the bootloader (Slimbootloader). >> >> Fan control works fine via the thermal_zone sysfs interface, but we cannot find any entries for the tacho. >> As we understand it, the ishtp_eclite driver merely acts as glue layer to the PSE/ECLite, so some other kernel code needs to call it, we guess based on ACPI definitions. >> >> Does any drivers exist which expose the tacho value to userspace (preferably via hwmon as is the standard way to do this in previous Intel designs with LPC + SuperIO)? >> Or if none exist, we may need to add this, but could really use some pointers to understand how such a driver should communicate with ECLite via the ishtp_eclite driver. >> >> Note: The official Intel binary release of the PSE FW (MR7) does not enable the low-level TGPIO SEDI driver in the PSE environment, so the tacho input is simply ignored. >> If rebuilding the PSE FW (https://github.com/intel/pse-fw) with the SEDI driver enabled, ECLite starts to read tacho as expected, but this does makes us wonder how well implemented (or used) the >tacho feature really is. >> >> Best regards >> Mikael Lund Jepsen >> Software Engineer >> Danelec > > Hi, > > maybe you could provide a ACPI Fan device which implements fan speed reporting through the _FST control method? > In such a case the generic ACPI fan driver would export this value to user space through sysfs. > > If you want to use the standard hwmon sysfs interface instead, i can provide you with a prototype patch for exposing this values as a standard hwmon device. > > Thanks, > Armin Wolf Hi Armin, A standard hwmon device would actually be preferable to me, as we need to support older platforms as well in the same codebase, and they already use that. If you could provide a prototype patch, I would be very grateful. Thanks, Mikael
