From: Chris Morgan <macroalpha82@gmail.com>
To: linux-pm@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
maccraft123mc@gmail.com, zhangqing@rock-chips.com,
zyw@rock-chips.com, sre@kernel.org, heiko@sntech.de,
conor+dt@kernel.org, krzk+dt@kernel.org, robh@kernel.org,
lee@kernel.org, Chris Morgan <macromorgan@hotmail.com>
Subject: [PATCH 0/5] Fix Incorrect State of Charge for RK817
Date: Mon, 26 Oct 2026 12:48:29 -0500 [thread overview]
Message-ID: <20261026174834.1652309-1-macroalpha82@gmail.com> (raw)
From: Chris Morgan <macromorgan@hotmail.com>
Users of the popular firmware RockNIX had identified a few bugs with
accurately displaying the correct state of charge for RK817 battery
devices. With the help of one user analyzing the code with Claude
they were able to identify a few potential bugs along with potential
solutions which I was then able to verify. These bugs are as follows:
1) Incorrectly clamping a value with a max of 10000 instead of 100000.
This bug caused the state of charge to sometimes read as 10% instead
of 100% as it should have.
2) Using the boot_voltage value to calibrate the battery in scenarios
where it could not be trusted. The boot_voltage register populates
immediately at power-on, and the driver would check if this value
was older than 30 minutes before using it. Unfortunately when combined
with the default behavior of the bootloader to turn the device off
when plugged in (requiring a user to explicitly power the device on)
the boot_voltage and boot_timer values were wrong. The boot voltage
would not account for any voltage added while the device was off,
and the boot_counter that tracks the time the device was off would
be reset. To fix this we adopted the same behavior as the BSP driver
which would typically (outside of first-boot scenarios) use a value
saved to NVRAM or the value from the coulomb counter directly and
then recalibrate with the OCV voltage once it was available.
3) A similar issue would happen during suspend, as values from the
coulomb counter could not be relied upon. So we add suspend specific
recalibration to the driver.
Included in this series is another fix that would cause the battery
to drain while the system was shut down. This patch replicates the
Rockchip BSP driver to set a shutdown register and provides a
device-tree parameter to override the behavior (though I am not aware
of any existing boards that need the override).
Chris Morgan (5):
power: supply: rk817-charger: Fix NVRAM SoC Value
power: supply: rk817-charger: Resolve boot state of charge from the
coulomb counter
power: supply: rk817-charger: Correct the gauge across system sleep
dt-bindings: power: supply: rk817-charger: Add
rockchip,gate-function-disable
power: supply: rk817-charger: Clear SYS_CAN_SD register by default
.../bindings/mfd/rockchip,rk817.yaml | 7 +
drivers/power/supply/rk817_charger.c | 336 +++++++++++++++---
include/linux/mfd/rk808.h | 3 +
3 files changed, 290 insertions(+), 56 deletions(-)
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next reply other threads:[~2026-10-26 17:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 17:48 Chris Morgan [this message]
2026-10-26 17:48 ` [PATCH 1/5] power: supply: rk817-charger: Fix NVRAM SoC Value Chris Morgan
2026-10-26 17:48 ` [PATCH 2/5] power: supply: rk817-charger: Resolve boot state of charge from the coulomb counter Chris Morgan
2026-10-26 17:48 ` [PATCH 3/5] power: supply: rk817-charger: Correct the gauge across system sleep Chris Morgan
2026-10-26 17:48 ` [PATCH 4/5] dt-bindings: power: supply: rk817-charger: Add rockchip,gate-function-disable Chris Morgan
2026-10-26 19:23 ` Heiko Stübner
2026-10-27 15:53 ` Chris Morgan
2026-10-27 22:40 ` Heiko Stübner
2026-10-28 14:16 ` Chris Morgan
2026-10-28 13:08 ` Krzysztof Kozlowski
2026-10-26 17:48 ` [PATCH 5/5] power: supply: rk817-charger: Clear SYS_CAN_SD register by default Chris Morgan
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=20261026174834.1652309-1-macroalpha82@gmail.com \
--to=macroalpha82@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maccraft123mc@gmail.com \
--cc=macromorgan@hotmail.com \
--cc=robh@kernel.org \
--cc=sre@kernel.org \
--cc=zhangqing@rock-chips.com \
--cc=zyw@rock-chips.com \
/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