Re: [PATCH 4/8] platform: arm64: qcom-hamoa-ec: Add fan RPM query and LUT calibration

On 7/30/2026 10:38 PM, Konrad Dybcio wrote:
> On 7/30/26 8:35 AM, Anvesh Jain P wrote:
>>
>>
>> On 7/29/2026 4:37 PM, Konrad Dybcio wrote:
>>> On 7/28/26 7:44 PM, Anvesh Jain P wrote:
>>>> Add the EC command definitions and handler functions for querying fan
>>>> RPM and programming per-fan LUTs (lookup tables mapping SoC
>>>> temperature to target RPM), and introduce a raw i2c_transfer()-based
>>>> transport for the two commands, since their variable-length,
>>>> sub-command-addressed payloads don't fit the smbus block-data model
>>>> used by the existing commands.
>>>>
>>>> Fan LUT geometry and temperature breakpoints vary by board, so encode
>>>> them in per-compatible qcom_ec_lut_config data selected via
>>>> device_get_match_data(). Add configs for the Hamoa CRD, Hamoa/Purwa
>>>> IOT EVK, and Glymur CRD ECs; IOT EVK boards share the Hamoa LUT
>>>> geometry but are bring-up platforms without a calibrated fan curve,
>>>> so skip_lut_set suppresses the LUT-set command on those boards.
> 
> [...]
> 
>>>> Since the LUT values depend on each fan's maximum RPM, which varies
>>>> per board assembly, calibrate it at runtime: drive the fan to full
>>>> PWM, wait for it to spin up, and read back the achieved RPM via the
>>>> new query command. Run calibration in a work item at probe time and
>>>> after EC reset recovery, and make it abortable via a completion so
>>>> suspend can cut it short. Track calibration completion state so the
>>>> LUT is programmed once calibration finishes and again on every
>>>> subsequent power-supply-driven profile switch.
>>>
>>> I don't want my laptop to become a jetplane on every bootup. I
>>> doubt anyone does.
>>>
>>> Konrad
>>
>> There's no EC command that reports a fan's max/rated RPM directly — the
>> only way to learn it is to drive the fan to full PWM and read back what
>> it actually spins up to, which is what calibration does. It's bounded to
>> a 10s timeout per fan and only runs once at probe (and again after EC
>> reset recovery).
> 
> 1. please fix the firmware so new designs will have that
> 2a. if we're storing a LUT already, can't we store the max RPM too?
> 2b. if we don't know fan RPM, we can still expose a PWM hwmon
> 
> Konrad


1. Agreed, will raise this with the EC firmware team for new designs.

2a. The EC's LUT storage isn't persistent across reboots, so we'd need
to cache max_rpm on the driver side instead to skip recalibration.
Initial probe after a fresh boot would still need one calibration pass
either way.

2b. cur_state already reports RPM-derived state via the cooling-device
ABI. Is it worth also adding PWM hwmon on top of that?

-- 
Best Regards,
Anvesh