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

[Anvesh Jain P]

On 8/19/2026 10:11 PM, Konrad Dybcio wrote:
> 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?
>

The EC has a default LUT from flash, but it is not calibrated properly
for this specific board's temperature and RPM characteristics. UEFI
doesn't initialize it either but fan would spin at some unrelated RPM
settings. Since the Hamoa EC can only store one LUT profile at a time,
we need to reprogram it on each profile switch to match the current
board's actual fan behavior.

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

We don't have an EC command to read back the PWM state, we can only read
RPM. So there's no point adding PWM hwmon since we can't query it
directly from the EC.

-- 
Best Regards,
Anvesh