[PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support

[Tudor Ambarus]

On 5/11/26 4:17 PM, Alexey Klimov wrote:
> On Thu May 7, 2026 at 9:31 AM BST, Tudor Ambarus wrote:
>> On 5/6/26 6:13 PM, Alexey Klimov wrote:
>>> On Wed May 6, 2026 at 12:39 PM BST, Tudor Ambarus wrote:
> 
> [..]
> 
>>>> new file mode 100644
>>>> index 000000000000..c68d60b4c0b3
>>>> --- /dev/null
>>>> +++ b/drivers/firmware/samsung/exynos-acpm-tmu.c
>>>
>>> [..]
>>>
>>>> +static int acpm_tmu_to_linux_err(s8 fw_err)
>>>> +{
>>>> +	/*
>>>> +	 * ACPM_TMU_INIT uses BIT(0) and BIT(1) of msg.rx.ret to flag APM
>>>> +	 * capabilities. Treat zero and all positive values as success.
>>>
>>> ACPM_TMU_INIT returns capabilities inside designated error field?
>>
>> yes
> 
> Heh. Okay.
> 
>>> What about other messages/commands? They just return error code there?
>>
>> all the other commands either return -1 for errors, regardless of the error
>> type, or 0 for success.
>>>
>>>> +	 */
>>>> +	if (fw_err >= 0)
>>>> +		return 0;
>>>> +
>>>> +	if (fw_err == -1)
>>>> +		return -EACCES;
>>>> +
>>>> +	return -EIO;
>>>> +}
>>>
>>> Could we map these return values with better granularity instead of
>>> returning -EIO for everything else that is not minus one?
>>
>> I think we're good as we are now. The firmware returns either -1 for errors,
>> zero for success, or BIT(0) and BIT(1) for TMU_INIT to flag some capabilities.
>> I can't tell if there are other commands that return capabilities as well,
>> or if there are other capabilities for TMU_INIT, I don't have access to the
>> firmware code.
> 
> On Exynos850 I see more than just one returned error codes. I definitely
> see 0xfe and 0xfd at least. I don't have any data to confirm that ff
> maps to -1 and fd-s, fe-s to -2,-3 though and what they mean. From my

for these error codes we will return -EIO which is alright. We can have
a more granular approach depending on the SoC if you want.

For GS101 above is alright, it matches the info I got from the firmware guys.

> experiments I suspect that 0xfe means that call/msg type is not
> implemented or not accessible and 0xfd means that passed parameter is
> wrong or incorrect or not found.
> 
> I am also not sure that I saw 0xff-s but, well, maybe that needs more
> experimenting.
> 

fe and ff will be covered as well by -EIO.

Let's keep this as it is for now, and if you need a more granular approach
we can differentiate that for e850.

Thanks,
ta