power: enable 30 W charging on Pocket EVO via direct-charge policy

[jesherman]

power: enable 30 W charging on Pocket EVO via direct-charge policy

Adds the Pocket EVO userspace charging policy for armada-os/armada-packages#35.

The kernel support exposes the required controls, but the charge pumps still need a sequenced handoff. This service:

• runs only when both EVO HL7139 supplies are present
• quiesces the Qualcomm charger (13 mA input-current vote), requests a safe PPS voltage, and enables the master and slave pumps
• watches battery and pump current, voltage, temperature, health, and state of charge
• tapers near the factory voltage limit and restores ordinary charging whenever the session ends
• re-establishes a session only after its full eligibility re-check — so a session interrupted by suspend (pumps are disabled by the kernel on suspend, see armada-packages#35) is not blindly resumed

Tier 1: raises the PPS target cap to 10.5 V with matching VIN guards, so a 3 A PD contract delivers ~31 W instead of ~26 W. Software-only — no kernel rebuild (the driver's 10 V VIN enable gate is checked only at enable time, and pumps are enabled at <=9.2 V; the ramp to 10.5 V never re-triggers it).

Measured results (Pocket EVO, kernel 7.2.0-rc7, 3 A PD contract)

• Stock Armada: 9.6 V × 1.87 A ≈ 17.9 W at the wall
• Previous (9.9 V cap): ~25.9 W at the wall
• Tier 1 (10.5 V cap): ~30.5 W at the wall, 32.1 W source, 27–28 W at the pump inputs, ~1.53/1.52 A pump balance, ~3.0 A combined input
• Sustained 20+ minutes under game load (75–90% SOC): no guard trips, no faults, battery 28–30 °C, pump die 62–63 °C and flat
• Idle at 89% SOC: battery pulls ~5.1 A at 10.2 V with no ramp stall, die 53–56 °C
• Cold-boot verified previously: the policy auto-starts a session after boot (no manual intervention), ramps through the inrush window

Key calibration finding

The HL7139 pump ADC over-reads current by ~4% (wall meter 2.93 A vs 3.05 A sysfs at 9.85 V). The 3 A PD contract therefore reads ~3.12 A in sysfs. The combined-input guard (3.12 A, 3-sample debounce) and the ramp/back-step band (3.08 A) are calibrated against that offset — the original 3.05 A guard fired on sysfs noise and never let the ramp pass ~9.9 V.

Notes

• Without this PR charging remains capped at ~18 W (9 V / 2 A plateau)
• The suspend interaction is handled by the kernel driver (pumps off on suspend) + this policy's eligibility re-check on resume
• The PPS voltage restore in cleanup() writes unconditionally: the firmware reports USB protocol type SDP even when its separate adapter type is PD-PPS, so a usb_type grep gate could never match. The kernel setter checks the raw adapter type and rejects non-PPS adapters itself

[jesherman]

im going to move this back to draft - there is definitely a driver dependency but performance seems intermittent maybe from policy changes. need to test more.

[jesherman]

Independent verification + hybrid hardening (2026-08-18)

Tested on a Pocket EVO with the hybrid build: this policy + the kernel pieces from armada-os/armada-packages#35 (0901 + 0063 + 0903 + 0904). Full cycle run from a 10% SOC start, including an 11-minute deep suspend.

Confirmed working

• Pumps auto-bind from DT at boot, policy auto-starts a direct-charge session once SOC ≥ 10%
• 25.9 W source / 24.4 W at the pump inputs at 15-18% SOC, balanced 1.47/1.45 A pump load, healthy temps (44-45 °C die), no kernel faults
• ICL handoff verified: 13 mA vote drops USB input current 1.87 A → 0 A, battery goes from charging to discharging at ~4.9 A, readback frozen at negotiated 3 A
• Unplug mid-session: guard trips instantly, pumps off, Qualcomm restored; policy re-establishes after the 60 s backoff
• Deep suspend (mem): kernel disables both pumps on PM_SUSPEND_PREPARE (0903), pumps stay off the entire suspend, policy re-establishes fresh after resume
• Battery STATUS=Charging during direct charge (0904) — UPower/SteamOS show the correct icon; previously the firmware reported Discharging because it only tracks its own (quiesced) buck

Fixes this test run found (now in the PR branches)

1. PPS voltage restore in cleanup() never fired — grep '\[PD_PPS\]' usb_type can never match: firmware reports protocol type SDP even when adapter type is PD-PPS (usb_type is a static capability list). Now writes unconditionally; the kernel setter validates the adapter type.
2. Low-SOC startup -ERANGE — 8.2 V min PPS target left VIN too close to the driver's 8.0 V enable floor; master pump sags VIN to ~7.98 V → slave enable rejected. Raised clamp to 8.8 V.
3. Enable inrush tripped per-pump current guard — watch loop sampled immediately after enable, caught a 2.68 A transient; added 3 s settle.
4. Battery icon said Discharging while charging (kernel, 0904) — see above.

Honest numbers

• Stock Armada: ~17.9 W at the wall (9.6 V × 1.87 A)
• With this PR set: 25-26 W at the pump inputs; 3.05 A combined-input guard is conservative (tripped once at 3.06 A; sustained run sits 2.89-2.93 A)
• All figures are source/request and device/pump-input power; the wall meter reads ~1 W higher than sysfs device

Remaining

• Taper at 4.45 V and 88% SOC session end verify naturally as the battery climbs (blocking nothing)

[jesherman]

Guard debounce added after cold-boot verification (2026-08-18)

During a cold-boot test the policy auto-started a session and ramped normally (2.43 → 2.89 → 3.02 A), then a single 0.5 s sample at 3.058 A (8 mA, ~0.3 % over the 3.05 A combined-input guard) ended the session — the controller was already pulling the PPS target back at that point. The 3.05 A guard value is correct (it must sit above the 2.88–2.95 A control band and below the 3 A PD contract), but a one-sample tripwire is too trigger-happy for a settling ramp.

The guard now requires 3 consecutive out-of-range samples (~1.5 s) before tearing down; a sustained overdraw still ends the session immediately. Verified on-device: the restart ramp crossed the same window and held ~26 W without a trip.

[jesherman]

Tier 1 update — 30.5 W at the wall, validated on-device (2026-08-18)

Raised the PPS target cap to 10.5 V with matching VIN guards. Software-only: the driver's 10 V VIN enable gate in armada-packages#35 is checked only at enable time, and this policy enables the pumps at ≤9.2 V, so no kernel rebuild was needed.

Measured (3 A PD contract, kernel 7.2.0-rc7):

• Sustained 20+ min under game load (75–90% SOC): ~30.5 W wall / 32.1 W source / 27–28 W at pump inputs, ~3.0 A combined input, 1.53/1.52 A balance, battery 28–30 °C, die 62–63 °C flat, no guard trips
• Idle at 89% SOC: battery pulls ~5.1 A at 10.2 V with no ramp stall, die 53–56 °C
• Session ends cleanly at the 90% SOC guard; unplug teardown is clean

Key calibration finding: the HL7139 pump ADC over-reads current by ~4% (wall meter 2.93 A vs 3.05 A sysfs at 9.85 V). The 3 A contract reads ~3.12 A in sysfs, so the combined-input guard (3.12 A, 3-sample debounce) and ramp band (3.08 A) are calibrated to the meter, not the raw sysfs value — the original 3.05 A guard fired on sysfs noise and capped the ramp at ~9.9 V.

Battery-current ramp gates (back-step 5.5 → 6.5 A, ramp 5.0 → 6.5 A) were raised to match Tier 1's ~6.2–6.5 A idle battery draw; the old gates would stall the ramp at ~29 W when the device is idle and the battery wants full current.

Note: an idle low-SOC (below ~70%) soak at 10.5 V is still outstanding — current data covers loaded (75–90%) and idle (89%) states.

[mrdidit]

Thanks for putting this together and for sharing the detailed Pocket EVO test results. I own an EVO myself, so I took a closer look at the safety and recovery paths before this becomes part of a normal Armada image.
The successful charging results are encouraging. This is only a static code review, I haven’t reproduced any of these failure cases on hardware, but I have a few concerns about what happens when a transition or I²C operation does not complete normally.

1. Please make direct charging explicitly opt-in for now.
   The service is enabled automatically, and on a Pocket EVO with the pump interfaces present it can start a direct-charge session whenever its eligibility checks pass, without the owner selecting it.
   Until the cleanup, suspend and fault-recovery paths are proven fail-closed, I think Qualcomm charging should remain the default. Dual-pump charging could be exposed as an experimental option requiring an explicit user action.
2. Cleanup should verify that both pumps are actually off.
   cleanup() uses set +e, ignores errors from both pump-disable writes, performs no online=0 readback, and then restores a fixed Qualcomm 9.6 V/3 A state.
   If one disable operation fails—for example because of an I²C timeout—the Qualcomm path could be restored while a pump remains enabled. Please avoid restoring Qualcomm current until both pumps have been confirmed off. A failed cleanup should remain visibly faulted and continue a bounded recovery attempt rather than report that normal charging was restored.
   Current cleanup implementation
3. Electrical and I²C faults should not automatically re-arm.
   The service currently waits 60 seconds after a session terminates and then becomes eligible again. Because the pump fault registers are read-to-clear, a transient fault may subsequently appear healthy.
   Normal endpoints and cable changes can reasonably permit a later session. Electrical, thermal, asymmetric-pump and I²C failures should stay latched and require an explicit re-enable or at least a cable cycle.
   Automatic retry loop
4. Confirm PD-PPS before reducing the Qualcomm current limit.
   Eligibility currently checks that USB is online, but not that the connected source supports PPS. A non-PPS source can therefore be reduced to 13 mA before the voltage request rejects it, followed by another attempt after the retry delay.
5. Please respect any supported charging-policy state.
   The direct-charge policy uses its own fixed SOC window. Where the platform exposes charge inhibit, bypass or a configured charge-end threshold, pump activation should not override that user-selected policy.
6. Some pair-level coherence checks would strengthen the active guard.
   The loop checks each pump’s individual voltage, current, temperature and health, which is good. It does not currently compare:
   • USB VBUS against each pump input;
   • master and slave input voltages;
   • requested PPS voltage against the measured values;
   • pump-local VBAT during the active session.
     These comparisons could help identify stale telemetry, an incomplete handoff or an asymmetric pump state.
7. It would be useful to define the daemon-failure behaviour.
   If the policy process is killed or crashes during an active session, the hardware protections remain, but the 500 ms software monitoring disappears until systemd restarts the daemon. Please document and test what guarantees pump shutdown during that interval.
   The main failure cases I would like to see tested are:

• a pump-disable I²C failure during cleanup;
• one pump remaining online while the other turns off;
• terminating the daemon during active charging;
• a transient pump IRQ fault followed by cleared status registers;
• connecting a non-PPS charger;
• cable removal during each initialization phase;
• charge inhibit or a configured endpoint below 90%.
  I’m not suggesting that the normal test results are invalid. My concern is specifically whether every abnormal path returns to a known safe state before Qualcomm charging is restored. Until that is demonstrated, I would be much more comfortable with this remaining an explicit experimental opt-in rather than an automatic charging policy.

[jesherman]

Thanks for the thorough review — all items are addressed in the updated head (64c7bd3):

1. Explicit opt-in — the service is no longer auto-enabled at image build; it only runs when the user creates /etc/armada/experimental/pocketevo-direct-charge and enables the unit. The policy idles (no writes at all) when the flag is absent, and the test suite asserts the enable line is absent from build_files/40-vendor-system-files.sh.

2. Verified pump-off before restoring Qualcomm — cleanup polls both online files up to 10 times after disabling (slave first, then master) and only restores the Qualcomm ICL/PPS request once both read 0. If either pump can't be confirmed off it exits non-zero with a latched fault and deliberately does not restore Qualcomm charging (fail closed). It runs as ExecStopPost, so it executes even when the daemon is SIGKILLed.

3. Latched faults — electrical/thermal/I2C faults latch in the state dir and block re-arming until the cable is cycled (VBUS absent + pump presence re-read). The unit also uses Restart=no so a failed cleanup leaves it dead until explicit user action.

4. PPS confirmed before the 13 mA handoff — the policy verifies the PD-PPS USB type before writing voltage_now/lowering ICL; the kernel additionally gates the VOLTAGE_NOW setter on a fresh USB_ADAP_TYPE read (kernel-side detail on PR AYN Thor Not Recognizing SD Card After Flashing With balenaEtcher #35).

5. Charge-inhibit/end-threshold respected — eligibility refuses to arm a direct-charge session when the platform requested charging to stop.

6. Pair coherence — the session guard compares master/slave voltage_avg (pump-local VBAT ADC) and current symmetry each sample; asymmetry beyond tolerance tears down the session and latches a fault.

7. Daemon-death behavior — Type=notify (READY after startup cleanup; WatchdogSec=15s), Restart=no, ExecStopPost cleanup. Tested: kill -9 triggers the ExecStopPost cleanup ("both pumps verified off") and the unit stays failed with NRestarts=0 — no automatic re-arm.

On-device verification (Pocket EVO, hotfix of this branch): PPS writes outside 3.3–10.5 V or off the 20 mV grid rejected; ICL > 3 A rejected; simulated stuck-pump cleanup fails closed; SIGKILL'd daemon leaves pumps off, no auto-restart; s2idle suspend/resume clean. Charger-attached session tests (non-PPS charger, mid-session cable pulls) to follow.

[jesherman]

Live-session test results (PD-PPS charger attached):

• The opt-in gate works: with the flag file present the unit arms and runs; without it nothing writes.
• usb_type correctly reports [PD_PPS] on real hardware with the 0902 getter mapping (previously [SDP] due to the firmware quirk) — the preflight gate now fires.
• Every session attempt armed correctly and tore down safely: the cable/coherence guard detected the failure, cleanup verified both pumps off, and the systemd watchdog killed a daemon hung on blocked sysfs reads. No safety violation in any run.

New firmware behavior discovered (needs more investigation): the 13 mA input-current-limit handoff write consistently wedges the battery-manager firmware when issued as part of a session start — the PD-PPS contract stays up (rail holds 8.8–9.9 V) but the charging engine drops (online → 0, status Discharging) and the whole power-supply class unregisters/re-registers transiently. The guard catches this every time (cable removed while quiescing Qualcomm charger), and recovery requires a physical replug.

Two policy fixes came out of this (in this push):

1. charge_end_soc() treated charge_control_end_threshold=0 (= unset) as "end at SOC 0", which made every session ineligible; 0 now means "no configured limit".
2. The session now raises the PPS rail to target before writing 13 mA (writing the limit while the rail is still at the 5 V default browns out the adapter contract). Watchdog pings are also fed inline through the session path (systemd pins WATCHDOG_PID to the main pid, so a background feeder is ignored).

The firmware wedge on the handoff write persists with both write orderings, so the next step is comparing the exact property sequence Android's charger HAL uses on this device (possibly a dedicated PD current-request property rather than ICL, or a required settle window). The direct-charge session itself never engaged the pumps because the guard correctly refused to enable them into an unverified source state.

[jesherman]

Follow-up: the handoff is solved — sustained 30 W-class direct charging confirmed on-device.

Root cause of the "cable removed" guards: three separate issues stacked on top of each other, none of them safety failures:

1. Handoff order — writing 13 mA while the PPS rail was still at the 5 V default browned out the adapter contract. The session now raises the rail to target (8.8–9.0 V) before the handoff write.
2. Quiesce signature misread — the buck's online flag drops to 0 as part of the quiesce (it stops sinking); the arm guard and watch loop treated that as a cable pull. The watch loop now detects real cable pulls via PPS rail collapse (a pull drops the rail to ~0/5 V, while quiesce holds 8–9 V under load).
3. Telemetry windows too tight for real physics: the adapter sags up to ~1 V below the request while the pumps spool up, and the slave pump's VBAT ADC reads ~100 mV (2.5 A) to ~260 mV (4.9 A) above the fuel gauge — the offset scales with current through its sense trace. Windows are now calibrated against on-device behavior (documented inline).

Also: charge_control_end_threshold=0 means "no limit configured", not "end at SOC 0" — this had made every session ineligible. And the watchdog (WatchdogSec=600 with inline feeding through cleanup, including while the cleanup subprocess runs) tolerates the multi-second battmgr sysfs stalls that occur under direct-charge load; a background feeder doesn't work because systemd pins WATCHDOG_PID to the main pid.

Validated results (Pocket EVO, this branch, PD-PPS charger):

• Sustained direct-charge sessions of 2–10 minutes: adapter 27–28.5 W (3.0–3.1 A @ 9.0–9.4 V PPS), battery 4.7–5.2 A at 4.0–4.2 V (~19–21 W into the cell), both pumps 6.5 W each
• SOC 44% → 64% across repeated sessions with zero guard trips after calibration
• Pump temps 51–53 °C throughout (well within limits), battery ≤ 31 °C
• All failure modes from the earlier test matrix still tear down safely (stuck pump, daemon SIGKILL, non-PPS source, rail collapse)

Both PR heads now carry the complete, live-validated stack (armada 85be1f0, armada-packages cb0f6d2).

[jesherman]

On discoverability of the opt-in (follow-up to item 1):

Agreed that a flag file nobody knows about would make the feature dead on arrival. The opt-in is now exposed through a user-facing CLI that ships in the image:

armada-charge-toggle status    # pump hardware, health, opt-in state, latched faults
armada-charge-toggle enable    # creates the flag file + enables the unit (root)
armada-charge-toggle disable   # removes both, restores normal Qualcomm charging

• status works without root and shows availability, pump health, battery state and any latched fault (with the cable-cycle recovery hint) — so a user who finds the command can see exactly what state they're in before enabling.
• enable/disable require root and do the flag-file + systemctl dance from item 1; the warning text in --help states it's experimental and recommends watching the first sessions (journalctl -u armada-pocketevo-charge-policy -f).
• The unit's ConditionPathExists still hard-gates the service on the flag file, so nothing runs unless the user explicitly opted in.

Kept as a CLI rather than a GUI toggle for now: it matches the existing armada-charge-debug precedent, keeps the experimental status visible in the tool's own output, and avoids suggesting a supported feature. A Decky "Experimental" settings toggle (the plumbing for it already exists — armada-control has the ToggleRow → control.sock → root-action pattern with capability gating) is the natural follow-up once the failure paths have broader hardware validation.

I would defer to @virtudude on how we would put a charging toggle in armada-control for device specific hooks like this, but this can be the source for him to pull from

[jesherman]

Two fixes folded in (2026-09-06), both found on-device:

1. notify_watchdog() — systemd 259 (Fedora 44) has no --watchdog flag; the flag-form ping failed silently (|| true), so WatchdogSec=600 SIGABRT'd the policy every 10 min mid-session/mid-latch (the "inconsistent charging" symptom). Switched to the portable variable form systemd-notify WATCHDOG=1. Proven by scratch unit tests: flag-form process killed at exactly 30 s, variable-form survives.

2. VBUS coherence guard — dropped the vs-request low window (usb_v < target - 1.2 V). The battmgr usb readback lags under load and is compared against a PPS target that moves every 0.5 s, so it cannot distinguish load sag from a real pull. At top-of-ramp the adapter sags 1.22-1.61 V below request while both pumps are healthy (usb/pump coherence ≤175 mV); the 1.2 V window tripped 4 sessions and a 1.5 V window still tripped a 5th (request=10.38 V usb=8.77 V master=8.94 V slave=8.88 V) on 2026-09-06, each latching until cable cycle and dropping the device to 18 W buck. Real pulls are still caught by the pump VIN range (8-10.5 V), usb↔pump coherence (800 mV), the usb upper bound (target + 500 mV), and the 5.4 V offline floor. All five incident tuples replayed against the new guard: no trip; a real-pull probe (5.05 V) still trips.