Re: [PATCH 06/15] power: supply: cpcap-battery: Initialize with user provided data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi.

Hmm I'm getting -EINVAL when I do echo 1600000 > charge_now but yet the
value does get updated?

Hm. I'm getting "Permission denied" when trying to do this.
Anyway, charge_now value is not supposed to be initialized by the user.
Only charge_full should be writable.

And I'm still not seeing capacity show up after that though even with full battery.. I think we should be able to calculate it if either a high or
low value has been seen?

There are two steps needed to calibrate the battery: to hit the "fully charged" state and to hit "battery empty" state. When the both states were hit the driver will initialize charge_full value. And it will start reporting correct charge_now
and capacity (battery charge percentage) values.

Once the charge_full value is calculated it's recommended to be saved by the user
to a permanent storage between reboots.

Saving/restoring the value can be done in init scripts.

For saving the calibration value just use the command like:
cat /sys/class/power_supply/battery/charge_full > /battery_cf

To restore (after device reboot or power on):
cat /battery_cf > /sys/class/power_supply/battery/charge_full

This will allow the kernel to do fast calibration. I.e. you will
only need to fully charge _OR_ fully discharge the battery to start
seeing correct charge_now and capacity values.

Also, we should have the driver default to using the charge_full_design
value if nothing is written from userspace and we see a high or low value.

I'd prefer to have charge_full value undefined until the battery is calibrated. This way the userspace can estimate current battery capacity using voltage as a
fallback for uncalibrated battery. The voltage estimation will be  way more
accurate than having charge_full = charge_full_design on pretty old Droid 4
batteries. For example, my battery after calibration has about 1000 mAh,
while charge_full_design is 1740000.

Maybe some pessimistic estimate could be used instead of just using
charge_full_design if no value is initialized from the userspace?
Something like (charge_full_design / 4) * 3 maybe?

It's better to rely on voltage estimated percentage.
In Maemo Leste we patched upower to use the following formula, which gives pretty
good results:

percentage = (voltage - voltage_empty) / (voltage_full - voltage_empty) * 100

Actually, the formula we use is a bit more complicated.

If you're curious, here's how it's actually done:
https://github.com/maemo-leste/upower/blob/master/src/linux/up-device-supply.c#L756

--
Best regards, Spinal



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux