RK3326/RK3566: battery, SD card and suspend/resume fixes

[Jacob-Matthew-Cook]

Summary

Battery, SD-card and suspend/resume fixes for the RK817-based RK3326/RK3566 handhelds, plus two mmc fixes that apply to every device.

Draft status: four of the kernel patches here (two dwc2, two rk817) are upstream candidates; the PR sits in draft while that series goes to the lists, so the tree and the submission stay in sync.

• RK817 gauge: wrong after any charge the driver couldn't watch — metered testing proved the coulomb counter blind while the system sleeps or sits powered off (1.4 A × 15 min registered ~1%), and every corrective signal (RELAX_STS, CHARGE_FINISH) gone again before the monitor runs after wake; the BSP driver's resume-time compensations exist for exactly this. The fix is @macromorgan's series extended to correct from persisted evidence: at boot, counter corroborating the saved soc within fcc/10 wins, divergence is arbitrated by measured voltage (rested relax pair, else OFF_CNT-proven-fresh PWRON_VOL, else the counter per the BSP's halt handling), and after a genuine off interval voltage overrides even an agreeing counter — a blind counter agrees with a stale save. Across sleep: suspend stamps time/charge-state/current and clears the relax flags; resume recalibrates from a pair latched during that sleep, else credits elapsed × current, saturating at full. Full write-up: findings / flow chart. Also fixes the saved-soc sanity clamp (10%→100%). factoryreset rk817-fuelgauge powers off so the next power-on samples PWRON_VOL fresh (gated ES entry; companion: GuiMenu: add RK817 fuel gauge reset entry emulationstation-next#30). Pixel2 powers off on measured voltage_avg rather than the gauge.
• dwc2: two system-sleep crashes (found testing this branch; upstream candidates, same root cause — the kernel's new PM register save/restore trusts state a never-activated controller doesn't have). (1) Resuming on battery after the USB power domain shuts off, the register-restore path dereferences eps_in[i] without a NULL check; on dedicated-direction-endpoint cores (PX30: no ep2in) that's a guaranteed oops mid-resume — frozen screen, dead device. (2) Booted with no cable, the PHY never starts its clock, the core soft reset at gadget bind times out and the error is ignored; suspend's register backup then stalls the AHB on the clock-dead core — hard hang, no oops, only a hardware watchdog recovers. Both root-caused from pstore/ramoops captures (in the commit messages), both fixes verified on the reproducing hardware.
• batteryplus — S922X-only wiring becomes a BATTERYPLUS_SUPPORT option (S922X/RK3326/RK3566); accepts voltage_avg (RK817 has no voltage_now); RetroArch reads /tmp/battery.percent. Its voltage anchors now come from the battery's own DT data (ocv-capacity-table-0, falling back to voltage_{min,max}_design) rather than assuming a 4.2V pack, so the GKD Pixel2's 4.35V cell no longer reads 100% across the top third of its range. The full anchor is seeded only when absent, so the daemon's own learning still wins.
• Pixel2 USB-OTG — the port kept sourcing 5 V after unplug and couldn't charge. usbgadget follows the extcon ID pin; dwc2 releases vbus-supply on host→device, which mainline never does.
• mmc (all devices) — a failed cache-enable, or a failed resume, removed a mounted card: ext4 replays its journal, exFAT is left corrupted, and on a boot medium the machine wedges. Cache-enable is now non-fatal and resume is retried after a power cycle. 99-automount.rules handles remove, so a card that returns is remounted instead of leaving /storage/roms empty until reboot. Note the two interact: a card that fails cache-enable now runs cache-less rather than being re-initialised by the resume retry.
• RK3566 GPU — apply RK3326's mali-bifrost regulator-balance patch; keep mali_kbase sole owner of the GPU clocks.
• input_sense — get_devices() never retried (RETRY started at its own limit) and appended duplicates, so a restart could attach to an incomplete set and lose the volume keys.

Testing

Built and tested on a GKD Pixel2 (RK3326) and an RG353M (RK3566).

• dwc2 resume oops: root-caused from a pstore-captured backtrace (full oops in the commit message); with the fix, 5/5 on-battery suspend/resume cycles on the previously 100%-reproducing Pixel2, dwc2_resume returning 0 in ~11 ms per cycle (the restore path executing, not skipped).
• dwc2 suspend hang: boot-unplugged + direct sleep froze the machine hard on every attempt (no oops — captured via ramoops + hardware-watchdog warm reset); with the fix, multiple clean cycles on the same hardware, and USB still self-heals on cable plug-in.
• mmc 0007/0008 exercised on the hardware that produced the failures. The RG353M no longer corrupts its games card on resume, and the Pixel2 no longer hangs after repeated suspend/resume. 0008's retry path observed firing live (8 rapid cycles, 2 reproductions, 2 clean recoveries at SDR104, zero wedge signatures).
• unbalanced disables for vdd_gpu fired on every suspend before the mali-bifrost patch; 9 cycles after it: zero warnings, GPU healthy.
• rk817 series: voltage_ocv semantics confirmed on hardware by @macromorgan; suspend/resume confirmed under Rockchip BL31; the sleep-blindness, dead relax gate, invisible CHARGE_FINISH, and reboot-at-full re-anchor all measured on RG353M. Kernel patches apply at strict zero fuzz (-F0) to both consumer kernels of the shared Rockchip tree (7.0.2 RK3566/76, 7.1.2 RK3326); the mmc patches additionally to 6.18.45 (RK3399) and 7.2 (H700/SM6115/SM8xxx).
• Still pending on hardware: the v3 correction paths — sleep-charge (expect the slept charging dmesg line and a corrected percentage), overnight rest (recalibration at wake), off-charge boot (off-time voltage overrides), and the reset tool's BAT_CON set direction.
• Test images (all four, plus update tars): https://github.com/Jacob-Matthew-Cook/distribution/releases/tag/power-charge-sleep-fixes-20260821 — 20260830 builds of head 45cf0548a0, kernel marker strings verified present.

Additional Context

Affects every RK817 handheld booting the mainline u-boots (RG353x/RG503, RG-DS, Powkiddy X55/RGB30/RK2023, GKD Pixel2, odroid-go, RG351, GameForce Chi). The gauge fix is kernel-side and a mainline candidate, so it covers stock bootloaders too — odroid-go2, anbernic-rgxx3 and pinetab2-rk3566 defconfigs all enable the plug-in shutdown.

DEVICE_USB_ROLE_FOLLOW_ID is Pixel2-only. BATTERYPLUS_SUPPORT is opt-in per device, but note the anchor change does alter reported percentages on every device that enables it: measured against each board's own OCV table, worst-case error drops from +54 to +12 points on the Pixel2 and from +39 to +17 on odroid-go2, since the stock 3250/4000 anchors were not right for 4.2V packs either.

---

AI Usage

Did you use AI tools to help write this code? YES

🤖 Generated with Claude Code

[sydarn]

Just to comment on this. I feel that rk817 and mmc patches should be done in alignment with upstream. For rk817 macromorgan is upstream. For mmc, I feel uneasy having custom patches. It would be good hear what kernel maintainers say about these.

The other stuff looks good to me, though I'd ask someone with experience of batteryplus to review that.

[Jacob-Matthew-Cook]

Just to comment on this. I feel that rk817 and mmc patches should be done in alignment with upstream. For rk817 macromorgan is upstream. For mmc, I feel uneasy having custom patches. It would be good hear what kernel maintainers say about these.

The other stuff looks good to me, though I'd ask someone with experience of batteryplus to review that.

You make a good point. We can keep this as a draft if you'd like while those changes are reported upstream. Regarding the mainline kernel SD card patches:

• 0007 is very critical to prevent SD card corruption on RG353M and other similar devices. We have documented cases of it rendering Exfat secondary ROM cards unusable/corrupted, and it has triggered journal recovery from my own unit (with an Ext4 partition)
• 0008 is not as critical, but it fixes a major issue when resume/suspend is spammed repeatedly (notably the GKD Pixel 2). In some cases, the primary SD card is outright not detected again/resumed, which is functionally equivalent to the card being removed from the slot and can cause hard crashes.

I fully respect the opinions/decisions from the senior devs/maintainers. If folks prefer I leave this as a draft, that is fine with me.

Lastly, if you would like me to report these mainline kernel issues upstream now, I can do that. However, I am not sure what we should do in the meantime, nor am I confident they will accept these changes.

[Jacob-Matthew-Cook]

Patch 0008 empirically proven on the original failing hardware. GKD Pixel2, 20260824 test build, the same SD512 461 GiB boot card that produced the original hard wedge; kernel log streamed off-device over the USB gadget network during the test so no evidence could be lost to a storage stall. Eight rapid suspend/resume cycles reproduced the failure twice; both recovered:

dwmmc_rockchip ff370000.mmc: Busy; trying anyway
mmc_host mmc0: Timeout sending command (cmd 0x202000 ...)   ← the old death signature
mmc0: resume failed (-95), retrying after a power cycle     ← patch 0008 fires
mmc_host mmc0: Bus speed = 150000000Hz (...)                ← card back at SDR104
PM: suspend entry (deep)                                    ← next cycle, clean

Post-recovery checks, all clean: no error -95 doing runtime resume (the swallowed error that used to wedge all storage I/O), no card removal, no ext4/journal errors, no D-state tasks; /storage verified read-write seconds after wake. On the pre-patch kernel this exact sequence left jbd2/writeback wedged in D-state with the machine unusable. Retry counter on-device agrees: 2 firings, 2 recoveries, 0 hard failures.

[Jacob-Matthew-Cook]

Two (unrelated to this PR's original scope) kernel regressions found & fixed while testing this branch: dwc2 crashes on system sleep

Both come from the same root cause: the current kernel's new dwc2 PM code backs up/restores the controller's registers across system sleep, and it trusts controller state that a never-fully-activated controller doesn't have. Found on the GKD Pixel 2 (RK3326/PX30); both were root-caused from pstore/ramoops captures and both fixes are verified on the previously 100%-reproducing hardware. The patches apply cleanly to both kernels this branch ships (7.1.2 RK3326, 7.0.2 RK3566).

Bug 1 — NULL deref on resume (003-usb-dwc2-gadget-fix-null-deref-on-register-restore.patch)
Suspending on battery powers off the USB domain; on resume the register-restore path runs and its desc-DMA workaround dereferences hsotg->eps_in[i] without a NULL check. On cores with dedicated-direction endpoints (PX30: dev_ep_dirs=0x6664, no ep2in) that's a guaranteed oops mid-resume — board hangs with the screen frozen. With VBUS present the power domain is retained and the path never runs, which is why it only crashed off-charger. Fix: guard the two workaround sites with the endpoint's existence. Verified: 5/5 on-battery suspend/resume cycles, dwc2_resume returning 0 in ~11 ms per cycle.

Bug 2 — hard hang on suspend entry after boot with no cable (004-usb-dwc2-skip-pm-callbacks-after-failed-core-reset.patch)
Booted unplugged, the PHY never starts its UTMI clock and the core soft reset at gadget bind times out (dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST in dmesg) — and the error is ignored. At suspend entry the register backup then reads device-mode CSRs on the clock-dead core, which doesn't fault — it stalls the AHB, wedging the CPU with no oops (only a hardware watchdog recovers; that's how the trace was captured). Fix: record the failed reset (core_reset_failed flag) and have the suspend/resume callbacks leave the controller alone while it's set; a later successful reset (cable plug-in restarts the PHY) clears the flag, so USB self-heals exactly as it already did in this state. Verified: boot-unplugged + direct suspend, multiple clean cycles.

This PR is now a draft pending upstream submission: both patches are in git am format with the captures in the commit messages (Cc: stable). @macromorgan they just need Fixes: SHAs from kernel git history (the desc-DMA restore workaround for 003; the critical-register backup/restore-on-system-sleep series for 004) if you're willing to carry them up.

[Jacob-Matthew-Cook]

Superseded (Sep 3): this describes v3. Its premise that the counter cannot count while powered off was disproved by the off-charge test below, and the boot ladder has since been reduced to counter-first in v4; see the v4 comment further down. The hardware results here still stand.

Fuel gauge: final design (v3, 45cf0548a0) — now hardware-validated end to end on RG353M

The core hardware finding, refined by instrumented testing: the RK817 coulomb counter is erratic across suspend (measured 69% capture of a metered charge on one sleep, ~139% on another) while counting reliably through powered-off charging — and every corrective signal the driver could read live (RELAX_STS, CHARGE_FINISH) is gone again before its monitor runs after wake. Rockchip's BSP compensates at resume (sleep-seconds × current, relax recalibration, an optional wakelock forbidding sleep-while-charging) and avoids the off-charge case entirely by having its U-Boot babysit the gauge during charge — a luxury mainline systems don't have.

The shipped series corrects from persisted evidence, never live observation:

1. Boot — counter corroborating the saved SoC within fcc/10 → counter. On divergence, measured voltage arbitrates: rested relax pair decides outright, else an OFF_CNT-proven-fresh in-range PWRON_VOL picks the side it corroborates, else the counter (BSP halt handling). After any genuine off interval, strong voltage disagreement can override even an agreeing counter (insurance for genuinely corrupted counters, per the original 0% field reports).
2. Suspend — stamp boottime, charge state, current; clear the relax-updated flags.
3. Resume — a pair with flags set was latched during this sleep: recalibrate from it. Else a charging sleep credits elapsed × current where the counter fell short, saturating at full. Every such wake logs slept charging for Ns: counter moved X of expected Y uAh.

Hardware validation (all on RG353M, kernel values via SSH, not the UI):

• Sleep-charge: 93% + 15-min charging sleep → woke at 100%, exact arithmetic (moved 173032 of expected 247318 uAh, credit capped at fcc), stable through the first 24 s (no reseed race). The neighboring sleep over-counted and was correctly credited nothing.
• Relax path: unplugged 18-min sleep → pair latched mid-sleep (GG_STS flags + rising RELAX_VOL1/2), read at wake via the suspend-cleared flags, and correctly not applied at <5% divergence.
• Off-charge boot (the original bug): 74% saved → 1.5 h powered-off charge → booted showing 100% with no reboot crutch: the counter had tracked the full charge, and the divergence arm believed it (counter/saved soc disagree … taking counter). The previously carried keep-saved logic would have shown 74%.
• Reset tool: verified by hand earlier on both devices; BAT_CON set-direction proven by @macromorgan.
• One display-layer caveat for testers: the ES battery header lags the kernel value by minutes and refreshes on resume — judge the gauge by /sys/class/power_supply/battery/capacity, not the header.

Design docs (current): plain-terms overview · findings · three-lane flow chart. @macromorgan the series (your two patches as revised + the sleep-correction third) is upstream-formatted with these measurements in the commit messages — ready for your read whenever suits.

[Jacob-Matthew-Cook]

Good news on the dwc2 crashes: released builds are not affected.

I tested the latest stable (20260901) on the Pixel 2 — no crashes, even though it ships the exact same 7.1.2 dwc2 code with none of the fixes. The reason: both bugs need the USB controller sitting in gadget/device mode while unplugged, and the only thing that puts it there is this PR's own USB role management (the ID-follow fix for the stuck-5V OTG port). Upstream's simpler usbgadget never configures the controller that way, so stable never steps on the landmines.

What that means: the kernel bugs are real but latent outside this PR, the exposure and the fixes ship together here (no window where a build has one without the other), and there's no urgency for stable. Cc: stable still applies upstream — any system that binds a USB gadget with no cable attached and then suspends on battery can hit these.

[Jacob-Matthew-Cook]

Fuel gauge: v4 (876e5c28f5), simplified after macromorgan's review

Chris asked for a boot ladder he could understand and support, and for FG_INIT to go. Re-auditing v3 against what the hardware actually exercised: most of the boot ladder never fired, and the v3 boot override rested on a claim the off-charge test disproved the same night it shipped (the counter does count while powered off). v4 keeps only what the hardware used.

The whole design in three sentences: the coulomb counter is the source; a rested voltage corrects it; sleep gets a time × current credit.

• Boot. First boot (BAT_CON): OCV lookup of PWRON_VOL, as before. Otherwise: the counter, unless it reads zero or negative, in which case the saved SoC (at most 8 s old). No OFF_CNT, no boot voltage, no relax read at boot, no FG_INIT. The BSP kernel agrees: it reads OFF_CNT into a flag it never uses and consults PWRON_VOL only on BAT_CON.
• Awake. Chris's 8 s relax recalibration, unchanged.
• Sleep. Suspend stamps boottime, charge, current and charging state, and clears the relax flags. Resume recomputes SoC from the counter, recalibrates from a pair latched during the sleep if there is one, else credits elapsed × current where a charging sleep fell short, capped at full. One fix inside: v3 compared the wake-time pair against the pre-sleep SoC; v4 compares against the counter.

Why not voltage-first after a power-off: PWRON_VOL samples at the power-on instant. A plugged power-on samples under charge current (RG353M: above the pack's 4.172 V maximum while at 74%, so it would report full), and an RG DS held 2.63 V in it while running (0%). Meanwhile the counter tracked 74% → full through the same off-charge exactly.

Verification: applies at zero fuzz on 7.1.2 and 7.0.2, compiles clean, checkpatch clean. Every case recorded in v1–v3 resolves to the same value under v4 (in each of them v3 ended up taking the counter anyway). Pending on this build: off-charge boot, a sleep-charge from ~40% (no taper or full-cap flattery), one unplugged overnight sleep, warm-reboot continuity.

Follow-up (same day), on @macromorgan's point that Q_PRES can also run past full: the runtime path already capped the counter at full before computing SoC, but the boot path and the wake-time recompute did not, so an over-counted Q_PRES could sit above 100% internally until the next tick. Now capped at full in both places (three lines, 876e5c28f5). Kept "invalid" at zero-or-below on purpose: a counter a few percent over full is the normal end of an off-charge with a slightly under-learned capacity and should read 100%, and the relax recalibration corrects a wrong 100% at the first rest.

Docs rewritten to v4, same links: plain-terms overview · findings · three-lane flow chart. Builds for both devices are running now; the pre-release assets will be swapped in place when they finish and I will note it here. @macromorgan the 002 subject is now "Resolve boot state of charge from the columb counter"; your From line and DCO chain are unchanged, and Cc: stable is off 005 (no Fixes: target).