kit/linux-gts6l
1
0
Fork 0
Code Issues 18 Pull requests Projects Releases Packages Wiki Activity Actions

Battery / charger: SM5705 fuel gauge + charger (no power_supply at all) #9

New issue
Open
opened 2026-08-21 12:51:57 +00:00 by kit · 1 comment
kit commented 2026-08-21 12:51:57 +00:00
Owner
Copy link

Plasma Mobile shows no battery because there is no power_supply device at all — /sys/class/power_supply/ is empty and no fuel-gauge or charger driver ever probes. Not a userspace gap.

Hardware

It's the SM5705 (SiliconMitus) — a combined fuel gauge + charger, the same PMIC whose MUIC/extcon side we already run. From battery-data-gts6l-common.dtsi:

  • sm5705-fuelgauge@71 on qupv3_se11_i2c (= mainline i2c11: i2c@a8c000), IRQ tlmm 37 (fuel_int), JIG on tlmm 120.
  • Charger is the SM5705 side too (CONFIG_CHARGER_SM5705, CONFIG_FUELGAUGE_SM5705, CONFIG_MFD_SM5705).
  • Battery cell data (capacity curve, CV table, temp table) lives in battery-data-gts6l-common.dtsi under the Samsung battery,* bindings.

Mainline coverage — partial, and only the part we don't need

  • Present: drivers/extcon/extcon-sm5705.c — but that's the USB-cable-detect side, which we already use. It does not expose battery/charger.
  • Absent: no drivers/power/supply/sm5705*, no drivers/mfd/sm5705*. So the fuel gauge (SoC/voltage/current) and the charger have no mainline driver. This is a port, not a config flip.
  • Our board DTS enables the SM5705 MUIC at 0x25 but has no fuel-gauge node and doesn't enable i2c11.

Two routes

Route A — port the downstream SM5705 fuel-gauge driver (pragmatic).

  • Enable i2c11 + pinctrl in our DTS; add an sm5705-fuelgauge@71 node.
  • Port drivers/battery_v2/sm5705_fuelgauge.c (SiliconMitus, GPL) to a mainline power_supply provider. The fuel gauge is a self-contained I2C device reporting SoC / voltage / current / temp — a clean power_supply class driver, no MFD entanglement required for read-only reporting.
  • Battery capacity/temp tables come from the existing battery-data-* dtsi.
  • This alone gets Plasma a battery percentage and voltage — the thing actually asked for.

Route B — charger too (later). The SM5705 charger half (input current limit, charge enable, charging status) is a separate power_supply. Needs the MUIC/extcon (which we have) to tell it cable type. More work; not needed for the gauge to report.

Scope note

A read-only fuel-gauge port is small and high-value (battery indicator + upower + Plasma's power management all start working). Charging control is a follow-on. Downstream drivers/battery_v2/ is large but most of it is Samsung's battery manager framework (sec_battery) — we want just the SM5705 fuelgauge chip driver reshaped as a power_supply, not that whole stack.

Estimate: ~1 session for the read-only gauge; charger control a second.

Plasma Mobile shows no battery because there is **no `power_supply` device at all** — `/sys/class/power_supply/` is empty and no fuel-gauge or charger driver ever probes. Not a userspace gap. ## Hardware It's the **SM5705** (SiliconMitus) — a combined **fuel gauge + charger**, the same PMIC whose MUIC/extcon side we already run. From `battery-data-gts6l-common.dtsi`: - **`sm5705-fuelgauge@71`** on `qupv3_se11_i2c` (= mainline `i2c11: i2c@a8c000`), IRQ `tlmm 37` (`fuel_int`), JIG on `tlmm 120`. - Charger is the SM5705 side too (`CONFIG_CHARGER_SM5705`, `CONFIG_FUELGAUGE_SM5705`, `CONFIG_MFD_SM5705`). - Battery cell data (capacity curve, CV table, temp table) lives in `battery-data-gts6l-common.dtsi` under the Samsung `battery,*` bindings. ## Mainline coverage — partial, and only the part we don't need - **Present**: `drivers/extcon/extcon-sm5705.c` — but that's the USB-cable-detect side, which we already use. It does **not** expose battery/charger. - **Absent**: no `drivers/power/supply/sm5705*`, no `drivers/mfd/sm5705*`. So the fuel gauge (SoC/voltage/current) and the charger have **no mainline driver**. This is a port, not a config flip. - Our board DTS enables the SM5705 MUIC at 0x25 but has **no fuel-gauge node** and doesn't enable `i2c11`. ## Two routes **Route A — port the downstream SM5705 fuel-gauge driver (pragmatic).** - Enable `i2c11` + pinctrl in our DTS; add an `sm5705-fuelgauge@71` node. - Port `drivers/battery_v2/sm5705_fuelgauge.c` (SiliconMitus, GPL) to a mainline `power_supply` provider. The fuel gauge is a self-contained I2C device reporting SoC / voltage / current / temp — a clean power_supply class driver, no MFD entanglement required for read-only reporting. - Battery capacity/temp tables come from the existing `battery-data-*` dtsi. - This alone gets Plasma a battery percentage and voltage — the thing actually asked for. **Route B — charger too (later).** The SM5705 charger half (input current limit, charge enable, charging status) is a separate power_supply. Needs the MUIC/extcon (which we have) to tell it cable type. More work; not needed for the gauge to report. ## Scope note A read-only fuel-gauge port is small and high-value (battery indicator + `upower` + Plasma's power management all start working). Charging control is a follow-on. Downstream `drivers/battery_v2/` is large but most of it is Samsung's battery *manager* framework (`sec_battery`) — we want just the SM5705 fuelgauge chip driver reshaped as a `power_supply`, not that whole stack. Estimate: ~1 session for the read-only gauge; charger control a second.
kit commented 2026-08-25 10:50:40 +00:00
Author
Owner
Copy link

2026-08-25: confirmed from the running device — and pm8150b is a dead end

Independent confirmation of this issue's diagnosis, from the device rather than the DT, plus one thing ruled out.

SM5705 confirmed as the whole battery/charging stack

TWRP's /proc/last_kmsg (Samsung's sec_log_buf) contains its own kernel logging the gauge live:

sm5705_fuel_gauge_read_vcell: vbat result 0x2263:(4298)
sm5705_init_fuelgauge: VCELL(4298)
sm5705_fuel_gauge_read_current: current result 0x8209:(-254)
sm5705_init_fuelgauge: CURRENT(-254)
sm5705_fuel_gauge_read_ocv:  ocv result 0x2247:(4284)
sm5705_init_fuelgauge: SOC(1000)
[MUIC] ADC Value : 0x07, Chager Type : 0x02, Vbus Status : 0x01
chg_get_charger_status : cable_type(1), vbus_status(1)
sm5705_set_auto_current: get_charger_status(1)

So the gauge reports mV, mA (signed, negative = discharging), OCV and SoC in tenths of a percent, and the charger side is driven off the MUIC's cable-type detection — exactly the shape this issue describes. The stock DT confirms the full set: sm,sm5705 @0x49, sm5705-fuelgauge @0x71, samsung,sm5705-charger, samsung,sec-battery.

pm8150b is NOT an alternative route — the part is not fitted

Worth recording because it looks like an obvious shortcut (mainline has qcom,pm8150b-charger and qcom,spmi-adc5 drivers, so "just use the PMIC's charger" is tempting). It does not work on this device:

  • Samsung's own DT empties both of its SPMI nodes: qcom,pm8150b@2 { }; and qcom,pm8150b@3 { }; — no compatible, no children, while pm8150 and pm8150l have full trees.
  • Stock registers zero pm8150b rails (regulator_summary has none) and never mentions it in dmesg.
  • Our DT included pm8150b.dtsi regardless, and mainline duly tried to probe it. Its revision read fails at the arbiter:
spmi spmi-0: pmic_arb_wait_for_done: 0x2 0x104: transaction failed (0x3) reg: 0x3408
WARNING: CPU: 4 PID: 1 at drivers/spmi/spmi-pmic-arb.c:321 pmic_arb_wait_for_done+0x128/0x160
pmic-spmi 0-02: probe with driver pmic-spmi failed with error -5

Removed from our DT — that was the only kernel WARNING in the boot, and SPMI now enumerates cleanly as 0-00 0-01 0-04 0-05 (pm8150 + pm8150l only).

So Route A in the description stands as the only route: port the SM5705 fuel gauge as a power_supply provider on i2c11. Nothing to salvage from pm8150b.

Useful for verification

Once the gauge lands, the numbers can be sanity-checked against TWRP — boot to recovery and read /proc/last_kmsg for the sm5705_fuel_gauge_read_* lines, which give a known-good reading from Samsung's own driver on the same hardware minutes earlier.

## 2026-08-25: confirmed from the running device — and pm8150b is a dead end Independent confirmation of this issue's diagnosis, from the device rather than the DT, plus one thing ruled out. ### SM5705 confirmed as the whole battery/charging stack TWRP's `/proc/last_kmsg` (Samsung's `sec_log_buf`) contains its own kernel logging the gauge live: ``` sm5705_fuel_gauge_read_vcell: vbat result 0x2263:(4298) sm5705_init_fuelgauge: VCELL(4298) sm5705_fuel_gauge_read_current: current result 0x8209:(-254) sm5705_init_fuelgauge: CURRENT(-254) sm5705_fuel_gauge_read_ocv: ocv result 0x2247:(4284) sm5705_init_fuelgauge: SOC(1000) [MUIC] ADC Value : 0x07, Chager Type : 0x02, Vbus Status : 0x01 chg_get_charger_status : cable_type(1), vbus_status(1) sm5705_set_auto_current: get_charger_status(1) ``` So the gauge reports mV, mA (signed, negative = discharging), OCV and SoC in tenths of a percent, and the charger side is driven off the MUIC's cable-type detection — exactly the shape this issue describes. The stock DT confirms the full set: `sm,sm5705` @0x49, `sm5705-fuelgauge` @0x71, `samsung,sm5705-charger`, `samsung,sec-battery`. ### pm8150b is NOT an alternative route — the part is not fitted Worth recording because it looks like an obvious shortcut (mainline has `qcom,pm8150b-charger` and `qcom,spmi-adc5` drivers, so "just use the PMIC's charger" is tempting). It does not work on this device: - Samsung's own DT **empties both of its SPMI nodes**: `qcom,pm8150b@2 { };` and `qcom,pm8150b@3 { };` — no compatible, no children, while pm8150 and pm8150l have full trees. - Stock registers **zero** pm8150b rails (`regulator_summary` has none) and never mentions it in dmesg. - Our DT included `pm8150b.dtsi` regardless, and mainline duly tried to probe it. Its revision read fails at the arbiter: ``` spmi spmi-0: pmic_arb_wait_for_done: 0x2 0x104: transaction failed (0x3) reg: 0x3408 WARNING: CPU: 4 PID: 1 at drivers/spmi/spmi-pmic-arb.c:321 pmic_arb_wait_for_done+0x128/0x160 pmic-spmi 0-02: probe with driver pmic-spmi failed with error -5 ``` Removed from our DT — that was the only kernel WARNING in the boot, and SPMI now enumerates cleanly as `0-00 0-01 0-04 0-05` (pm8150 + pm8150l only). So Route A in the description stands as the only route: port the SM5705 fuel gauge as a `power_supply` provider on `i2c11`. Nothing to salvage from pm8150b. ### Useful for verification Once the gauge lands, the numbers can be sanity-checked against TWRP — boot to recovery and read `/proc/last_kmsg` for the `sm5705_fuel_gauge_read_*` lines, which give a known-good reading from Samsung's own driver on the same hardware minutes earlier.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
gts6l/6.17
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kit/linux-gts6l#9
No description provided.