Hi, * Merlijn Wajer <merlijn@xxxxxxxxxx> [180303 19:19]: > Hi, > > I'm trying to get UPower to return a non-zero battery percentage on the > Droid4, and I'm running into some problems, related to the values > exposed in sysfs, here: > > /sys/devices/platform/44000000.ocp/48098000.spi/spi_master/spi0/spi0.0/48098000.spi:pmic@0:battery/power_supply/battery/ > > I first noticed that /capacity was not available, but /capacity_level > is. Reading Documentation/power/power_supply_class.txt, it seems that > /capacity should only be available when the hardware supports it (and > not extrapolated from voltage levels for example) - unchanged since > initial commit in 2007. Well Pavel posted something called libbattery that might help: https://github.com/pavelmachek/libbattery > It goes on to suggest that userspace could perhaps do something clever > to deal with lack of these values. UPower can fall back to reading > /energy_now and /energy_full ; but this is also not available. > As far as I can tell, it doesn't (want to?) deal with extrapolating > based on min/max/current voltage. > > If the device is not a battery (!), UPower will also try to set a rough > estimate based on /capacity_level, which would work for the Droid4, > except that ... it is a battery, so UPower decides not to read > /capacity_level. (I will see about filing a bug with them about this) > > My question is - would it be possible to get /energy_now and > /energy_full available as properties, or does the chip not expose this? > (I guess that if it did, /capacity would also be available?) Those still need calculations that are currently missing. We do have current consumption, voltage and a Colomb counter data available though so it should be possible. Who knows, maybe libbattery already mostly gets you there. Then I think there's a 1w chip on the battery too that contains some values, and might be usable to store also battery related data. But a file system for storing the data with libbattery is probably the generic solution. > Other suggestions are also appreciated. We could have libbattery could write back the estimates via /sys to the kernel battery framework for providing compability with all kind of user space software. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
