power: supply: qcom_battmgr: report charge levels on SM8350-class firmware

battmgr->unit is only ever assigned in the BATTMGR_BAT_INFO handler of the SC8280XP callback. The SM8350-class firmware does not implement that request - every property is fetched individually via BATTMGR_BAT_PROPERTY_GET - so unit keeps its zero-initialised value, QCOM_BATTMGR_UNIT_mWh.

POWER_SUPPLY_PROP_CHARGE_FULL and POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN are guarded by 'if (unit != QCOM_BATTMGR_UNIT_mAh) return -ENODATA;', hence both properties always fail on these platforms, even though the values are requested from the firmware and stored in info.last_full_capacity and info.design_capacity on every access:

  $ cat /sys/class/power_supply/qcom-battmgr-bat/charge_full
  cat: read error: No data available

Without a full charge value userspace cannot derive an absolute energy level, so UPower reports a zero energy level and never computes a time-to-empty/time-to-full estimate:

    energy:              0 Wh
    energy-full:         0 Wh
    energy-rate:         12.4713 W
    percentage:          59%

The firmware of this class reports charge domain values, so set the unit statically when registering the SM8350/SM8550 power supplies. With this patch the properties read back consistently on a Fairphone 5:

  charge_full         4116000
  charge_full_design  4260000
  capacity            85

Fixes 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply")

Signed-off-by Jan-Michael Brummer <[email protected]>

---

The SM8350-class firmware does not implement a dedicated 'charge now' property. It does however report BATT_CHG_COUNTER, and on this class of firmware that value is the remaining charge in uAh rather than a monotonic counter. Measured on a Fairphone 5 with charge_full at 4116000 uAh:

  BATT_CHG_COUNTER   reported capacity   counter / charge_full
  2434614            59%                 59.1%
  3525354            85%                 85.6%

Map POWER_SUPPLY_PROP_CHARGE_NOW onto the same firmware property and store the value in status.capacity, which the CHARGE_NOW/ENERGY_NOW case of qcom_battmgr_bat_get_property() already reads.

Together with the preceding patch this gives userspace both the full charge and the current charge. UPower now derives an energy level and runtime estimates in both directions:

    state:               discharging      state:               charging
    energy:              14.4347 Wh       energy:              15.6003 Wh
    energy-full:         16.8807 Wh       energy-full:         18.1505 Wh
    energy-rate:         3.39313 W        energy-rate:         7.3492 W
    time to empty:       4.3 hours        time to full:        20.8 minutes

Signed-off-by Jan-Michael Brummer <[email protected]>

---

Quoted 18 lines · Jan-Michael Brummer

The SM8350-class firmware does not implement a dedicated 'charge now' property. It does however report BATT_CHG_COUNTER, and on this class of firmware that value is the remaining charge in uAh rather than a monotonic counter. Measured on a Fairphone 5 with charge_full at 4116000 uAh:

  BATT_CHG_COUNTER   reported capacity   counter / charge_full
  2434614            59%                 59.1%
  3525354            85%                 85.6%

Map POWER_SUPPLY_PROP_CHARGE_NOW onto the same firmware property and store the value in status.capacity, which the CHARGE_NOW/ENERGY_NOW case of qcom_battmgr_bat_get_property() already reads.

Together with the preceding patch this gives userspace both the full charge and the current charge. UPower now derives an energy level and runtime estimates in both directions:

Quoted 8 lines

    state:               discharging      state:               charging
    energy:              14.4347 Wh       energy:              15.6003 Wh
    energy-full:         16.8807 Wh       energy-full:         18.1505 Wh
    energy-rate:         3.39313 W        energy-rate:         7.3492 W
    time to empty:       4.3 hours        time to full:        20.8 minutes

Signed-off-by Jan-Michael Brummer <[email protected]>

---

Ok this makes more sense now. We should still gate the other property though.

[...]

drivers/power/supply/qcom_battmgr.c static void qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr, · line 1451

Quoted 9 lines

drivers/power/supply/qcom_battmgr.c +4 -1

@@ -1442,7 +1445,10 @@ static void qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr,
 			battmgr->info.technology = le32_to_cpu(resp->intval.value);
 			break;
 		case BATT_CHG_COUNTER:
-			battmgr->info.charge_count = le32_to_cpu(resp->intval.value);
+			val = le32_to_cpu(resp->intval.value);
+			battmgr->info.charge_count = val;
+			/* the firmware reports the remaining charge here */
+			battmgr->status.capacity = val;

Let me try and find whether we can rely on this - on newer targets many properties are more or less just front-ends for vendor plumbing (because there's a ton of different chargers etc.)

Quoted 36 lines · Jan-Michael Brummer

Quoted 35 lines

The SM8350-class firmware does not implement a dedicated 'charge now'
property. It does however report BATT_CHG_COUNTER, and on this class of
firmware that value is the remaining charge in uAh rather than a monotonic counter. Measured on a Fairphone 5 with charge_full at 4116000 uAh:

  BATT_CHG_COUNTER   reported capacity   counter / charge_full 2434614            59%                 59.1% 3525354            85%                 85.6%

Map POWER_SUPPLY_PROP_CHARGE_NOW onto the same firmware property and
store the value in status.capacity, which the CHARGE_NOW/ENERGY_NOW case
of qcom_battmgr_bat_get_property() already reads.

Together with the preceding patch this gives userspace both the full
charge and the current charge. UPower now derives an energy level and
runtime estimates in both directions:

    state:               discharging      state:
charging
    energy:              14.4347 Wh       energy:
15.6003 Wh
    energy-full:         16.8807 Wh       energy-full:
18.1505 Wh
    energy-rate:         3.39313 W        energy-rate:
7.3492 W
    time to empty:       4.3 hours        time to full:
20.8 minutes

Quoted 5 lines

Quoted 2 lines

Signed-off-by Jan-Michael Brummer <[email protected]>

---

Ok this makes more sense now. We should still gate the other property though.

Quoted 12 lines

[...]

Quoted 9 lines

(quoted diff) +0 -0

@@ -1442,7 +1445,10 @@ static void
 qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr,

  battmgr->info.technology = le32_to_cpu(resp->intval.value);
  break;
  case BATT_CHG_COUNTER:

(quoted diff) +0 -1

-			battmgr->info.charge_count =

le32_to_cpu(resp->intval.value);

drivers/power/supply/qcom_battmgr.c +1 -0

+			val = le32_to_cpu(resp->intval.value);

Quoted 8 lines

drivers/power/supply/qcom_battmgr.c static void qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr, · line 1451

Quoted 4 lines

(quoted diff) +2 -0

+			battmgr->info.charge_count = val;
+			/* the firmware reports the remaining

charge here */

drivers/power/supply/qcom_battmgr.c +1 -0

+			battmgr->status.capacity = val;

Let me try and find whether we can rely on this - on newer targets many properties are more or less just front-ends for vendor plumbing (because there's a ton of different chargers etc.)

There's a comment saying /* remaining capacity in uAh */, so it seems like this should be OK

Konrad