[RFC] power: supply: qcom_battmgr: implement battery charge control on kodiak phones

[RFC] power: supply: qcom_battmgr: implement battery charge control on kodiak phones

[Federico Amedeo Izzo]

Hello,

I want to implement battery charge control support on two kodiak phones:
motorola-dubai and fairphone-fp5. I kindly ask your feedback on my 
implementation proposal below.

This feature also known as "charging limit" or "battery health" lets the user
limit the battery charging range to 0-80% tipically, in order to extend the
lifetime of the battery. It can also be used with a lower range 0-50% to
prevent battery degradation on devices always connected to a charger.

Newer SoCs like SM8550 and X1E80100 implement charge control in the battmgr
firmware, but kodiak (SM8350 in qcom-battmgr.c) does not support that (I tried
using the same property ID as newer SoCs with no luck.

Looking at downstream implementations, both dubai and fp5 implement the ability
to stop and start the charge with custom extensions to the battmgr firmware,
while the actual charge control logic is implemented in a kernel driver (dubai)
or in a userspace java service (fp5).

My plan is to expose the start/stop firmware capability of the two phones using
the charge_behaviour sysfs property, then implement the charge control logic
(start/stop charge depending on current level vs thresholds) in the qcom-battmgr
driver itself and expose the sysfs properties charge_control_start/end_threshold
to let userspace change the thresholds. The scope of this "software"
implementation would be limited to SM8350 in qcom-battmgr as later SoCs can
already do this in firmware.

Best regards,
Federico Amedeo Izzo

Re: [RFC] power: supply: qcom_battmgr: implement battery charge control on kodiak phones

[Konrad Dybcio]

On 10/18/26 11:46 AM, Federico Amedeo Izzo wrote:
> Hello,
> 
> I want to implement battery charge control support on two kodiak phones:
> motorola-dubai and fairphone-fp5. I kindly ask your feedback on my 
> implementation proposal below.
> 
> This feature also known as "charging limit" or "battery health" lets the user
> limit the battery charging range to 0-80% tipically, in order to extend the
> lifetime of the battery. It can also be used with a lower range 0-50% to
> prevent battery degradation on devices always connected to a charger.
> 
> Newer SoCs like SM8550 and X1E80100 implement charge control in the battmgr
> firmware, but kodiak (SM8350 in qcom-battmgr.c) does not support that (I tried
> using the same property ID as newer SoCs with no luck.
> 
> Looking at downstream implementations, both dubai and fp5 implement the ability
> to stop and start the charge with custom extensions to the battmgr firmware,
> while the actual charge control logic is implemented in a kernel driver (dubai)
> or in a userspace java service (fp5).
> 
> My plan is to expose the start/stop firmware capability of the two phones using
> the charge_behaviour sysfs property, then implement the charge control logic
> (start/stop charge depending on current level vs thresholds) in the qcom-battmgr
> driver itself and expose the sysfs properties charge_control_start/end_threshold
> to let userspace change the thresholds. The scope of this "software"
> implementation would be limited to SM8350 in qcom-battmgr as later SoCs can
> already do this in firmware.

I suppose this is something that could be introduced at the framework
level (+sre) - using a "stop charging" command to implement a charging
level cap.

For battmgr, I see there's a BATTMGR_SET_CHARGE_RATE (0x6) command
with the following arguments:

struct {
	struct pmic_glink_hdr hdr;
	__le32 battery_id;
	__le32 charge_rate;
	__le32 charging_path;
}

charge_rate being the % of full charge current that is allowed.
Maybe that could work. Or maybe there's an existing mechanism that
I failed to notice.

Konrad