mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Federico Amedeo Izzo" <federico@izzo.pro>
To: <linux-arm-msm@vger.kernel.org>, <linux-pm@vger.kernel.org>
Cc: <federico@izzo.pro>, <luca.weiss@fairphone.com>,
	<val@packet.cool>, <~postmarketos/upstreaming@lists.sr.ht>,
	<phone-devel@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: [RFC] power: supply: qcom_battmgr: implement battery charge control on kodiak phones
Date: Sun, 18 Oct 2026 11:46:25 +0200	[thread overview]
Message-ID: <DM7V9WDDVQ2I.3THP2TDPTP994@izzo.pro> (raw)

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

                 reply	other threads:[~2026-10-18  9:57 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM7V9WDDVQ2I.3THP2TDPTP994@izzo.pro \
    --to=federico@izzo.pro \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=luca.weiss@fairphone.com \
    --cc=phone-devel@vger.kernel.org \
    --cc=val@packet.cool \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®