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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/31/26 8:25 AM, Anvesh Jain P wrote:
> 
> 
> 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.

[...]

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

Are you saying that without this patch, we could be in a situation where
the fan simply wouldn't spin because the LUT would be null on the EC
side? Would UEFI not do it for us?

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

We have to deduce the RPM number, whereas IIUC we can query the PWM
state (if not, then there's no point)

Konrad