Motorola Droid 4 progress, power consumption
Hi!
4.17-rc1 is quite usable on droid 4; basically everything works. OHCI is running all the time, which means we burn a lot of power needlessly.
Anyway, >5.5hours of standby with screen off, GSM on is already usable.
This is the core of code I'm using.
https://github.com/pavelmachek/unicsy_demo
Battery graphs are attached. I'm not sure if the battery was really close to empty at that point -- voltage curve should have different shape if that was the case.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 5 lines · Pavel Machek
Hi!
4.17-rc1 is quite usable on droid 4; basically everything works. OHCI is running all the time, which means we burn a lot of power needlessly.
To work around that we can use n_gsm and and then suspend USB device. That will need the modem wake gpio working that I'll be sending patches for at some point.
And we should make cdc_wdm, qcaux and ohci support runtime PM for autosuspend at some point. For *hci, we can make it work along what Roger did in his earlier series here except by using Linux generic wakeirq support:
https://lkml.org/lkml/2013/7/10/355
Quoted 2 lines
Anyway, >5.5hours of standby with screen off, GSM on is already usable.
Just to rub that in, you do mean GSM usable for voice calls and SMS with your unicsy_demo with mainline kernel plus the pending LCD related patches, right? :)
Quoted 7 lines
This is the core of code I'm using.
https://github.com/pavelmachek/unicsy_demo
Battery graphs are attached. I'm not sure if the battery was really close to empty at that point -- voltage curve should have different shape if that was the case.
Cool. BTW, the value for POWER_SUPPLY_POWER_AVG should be quite accurate for the whole device power consumption.
It comes from the shunt resistor measured by the PMIC. Sorry I don't remember how often it needs to be polled but I'm guessing polling it once a minute or so should be plenty.
Hmm oh and the POWER_SUPPLY_CHARGE_COUNTER value should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes to POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved on POWER_SUPPLY_CAPACITY_LEVEL_FULL.
Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and POWER_SUPPLY_POWER_AVG.
Regards,
Tony
Hi!
Quoted 6 lines
Quoted 2 lines
Anyway, >5.5hours of standby with screen off, GSM on is already usable.
Just to rub that in, you do mean GSM usable for voice calls and SMS with your
unicsy_demowith mainline kernel plus the pending LCD related patches, right? :)
Plus some other patches, yes.
Quoted 10 lines
Quoted 7 lines
This is the core of code I'm using.
https://github.com/pavelmachek/unicsy_demo
Battery graphs are attached. I'm not sure if the battery was really close to empty at that point -- voltage curve should have different shape if that was the case.
Cool. BTW, the value for
POWER_SUPPLY_POWER_AVGshould be quite accurate for the whole device power consumption.
Aha, I was looking in the wrong directory. Yes, these look useful.
Quoted 3 lines
It comes from the shunt resistor measured by the PMIC. Sorry I don't remember how often it needs to be polled but I'm guessing polling it once a minute or so should be plenty.
Ok. I normally do once in 30 seconds.
Quoted 9 lines
Hmm oh and the
POWER_SUPPLY_CHARGE_COUNTERvalue should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes toPOWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved onPOWER_SUPPLY_CAPACITY_LEVEL_FULL.Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and
POWER_SUPPLY_POWER_AVG.
Ok, more stuff on TODO list. I actually use python hacks, and not libbattery now.
Is this one correct?
voltage_min_design:3100000
I believe you mentioned flash stops working at 3.3V. What is important from my point of view is to shut the system down when the battery is low. I believe that still needs to be implemented.
Is it appropriate to shutdown at POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL? But then libbattery will race with shutdown to save the thresholds...
I also have some hacks to allow configuration of the full voltage. Charging to 4.35V is pretty agressive, and I believe baterry will be damaged less if we only charge to 4.1V.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 10 lines · Pavel Machek
Hi!
Quoted 6 lines
Quoted 2 lines
Anyway, >5.5hours of standby with screen off, GSM on is already usable.
Just to rub that in, you do mean GSM usable for voice calls and SMS with your
unicsy_demowith mainline kernel plus the pending LCD related patches, right? :)Plus some other patches, yes.
Cool :)
Quoted 16 lines
Quoted 3 lines
It comes from the shunt resistor measured by the PMIC. Sorry I don't remember how often it needs to be polled but I'm guessing polling it once a minute or so should be plenty.
Ok. I normally do once in 30 seconds.
Quoted 9 lines
Hmm oh and the
POWER_SUPPLY_CHARGE_COUNTERvalue should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes toPOWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved onPOWER_SUPPLY_CAPACITY_LEVEL_FULL.Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and
POWER_SUPPLY_POWER_AVG.
Quoted 6 lines
Ok, more stuff on TODO list. I actually use python hacks, and not libbattery now.
Is this one correct?
voltage_min_design:3100000
Yes I think that's the voltage we get battery empty interrupt and cpcap_battery_irq_thread() calls orderly_poweroff() shuts down the device.
Quoted 3 lines
I believe you mentioned flash stops working at 3.3V. What is important from my point of view is to shut the system down when the battery is low. I believe that still needs to be implemented.
The 3.3V case was for a different device, so the minimum level can board specific and less than what the battery thinks it might be.
Quoted 2 lines
Is it appropriate to shutdown at
POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL? But then libbattery will race with shutdown to save the thresholds...
No need to do anything except notify user at the battery low interrupt CPCAP_BATTERY_IRQ_ACTION_BATTERY_LOW :)
Quoted 3 lines
I also have some hacks to allow configuration of the full voltage. Charging to 4.35V is pretty agressive, and I believe baterry will be damaged less if we only charge to 4.1V.
That should be based on the PMIC register values that Android uses. Worth rechecking for sure, I thought it is higher than normal too for the charge voltage.
Regards,
Tony
Hi!
Quoted 7 lines
Quoted 3 lines
I also have some hacks to allow configuration of the full voltage. Charging to 4.35V is pretty agressive, and I believe baterry will be damaged less if we only charge to 4.1V.
That should be based on the PMIC register values that Android uses. Worth rechecking for sure, I thought it is higher than normal too for the charge voltage.
Actually that part is ok. Android probably charges it to 4.35V, and battery is designed to handle that... For a year, or two. But I don't need full capacity at the moment, and perhaps battery will last three years if it is only charged to 4.1V.
Best regards,
Pavel
Signature · 9 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180502/b7d72c94/attachment.sig>
Hi!
Quoted 15 lines
Quoted 2 lines
Anyway, >5.5hours of standby with screen off, GSM on is already usable.
Just to rub that in, you do mean GSM usable for voice calls and SMS with your
unicsy_demowith mainline kernel plus the pending LCD related patches, right? :)Quoted 7 lines
This is the core of code I'm using.
https://github.com/pavelmachek/unicsy_demo
Battery graphs are attached. I'm not sure if the battery was really close to empty at that point -- voltage curve should have different shape if that was the case.
Quoted 6 lines
Cool. BTW, the value for
POWER_SUPPLY_POWER_AVGshould be quite accurate for the whole device power consumption.It comes from the shunt resistor measured by the PMIC. Sorry I don't remember how often it needs to be polled but I'm guessing polling it once a minute or so should be plenty.
I'd like current_avg more, but if I cat it manually, it changes on order of seconds, and quite significantly... which suggest shorter polling interval would be needed.
user at devuan:/sys/class/power_supply/battery$ date; cat current_now current_avg
Thu May 3 09:33:05 CEST 2018
-71000
-218408
user at devuan:/sys/class/power_supply/battery$ date; cat current_now current_avg
Thu May 3 09:33:06 CEST 2018
-61000
-200238
user at devuan:/sys/class/power_supply/battery$ date; cat current_now current_avg
Thu May 3 09:33:06 CEST 2018
-51000
-209879
user at devuan:/sys/class/power_supply/battery$ date; cat current_now current_avg
Thu May 3 09:33:07 CEST 2018
-56000
-72308
user at devuan:/sys/class/power_supply/battery$ date; cat current_now current_avg
Thu May 3 09:33:08 CEST 2018
-37000
-211362
Quoted 9 lines
Hmm oh and the
POWER_SUPPLY_CHARGE_COUNTERvalue should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes toPOWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved onPOWER_SUPPLY_CAPACITY_LEVEL_FULL.Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and
POWER_SUPPLY_POWER_AVG.
I'll look into that... but probably will do experiments with python, first.
Best regards,
Pavel
Signature · 9 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/5bccc8c0/attachment.sig>
Quoted 21 lines · Pavel Machek
I'd like
current_avgmore, but if I cat it manually, it changes on order of seconds, and quite significantly... which suggest shorter polling interval would be needed.user at devuan:/sys/class/power_supply/battery$ date; cat
current_nowcurrent_avg
Thu May 3 09:33:05 CEST 2018
-71000
-218408
user at devuan:/sys/class/power_supply/battery$ date; catcurrent_nowcurrent_avg
Thu May 3 09:33:06 CEST 2018
-61000
-200238
user at devuan:/sys/class/power_supply/battery$ date; catcurrent_nowcurrent_avg
Thu May 3 09:33:06 CEST 2018
-51000
-209879
user at devuan:/sys/class/power_supply/battery$ date; catcurrent_nowcurrent_avg
Quoted 8 lines
Thu May 3 09:33:07 CEST 2018
-56000
-72308
user at devuan:/sys/class/power_supply/battery$ date; catcurrent_nowcurrent_avg
Thu May 3 09:33:08 CEST 2018
-37000
-211362
I recall it just being calculated based on the time between the reads. Hard to say what it does, -ENODOCS.. Maybe the mc13783 PMIC docs have something similar.
Quoted 6 lines
Quoted 6 lines
Hmm oh and the
POWER_SUPPLY_CHARGE_COUNTERvalue should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes toPOWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved onPOWER_SUPPLY_CAPACITY_LEVEL_FULL.
Quoted 6 lines
Quoted 3 lines
Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and
POWER_SUPPLY_POWER_AVG.I'll look into that... but probably will do experiments with python, first.
Sure. The reason why I think we should not do it in the kernel in addition to the earlier reasoning is that we don't have a place to store the min and max values across reboot. I think there's some flash on the battery over 1w bus, but it probably just contains battery serial number or something and is not intended for writing much to it. I guess the min and max values should be really keyd based on this battery id in case the battery gets changed.
Regards,
Tony
Hi!
Quoted 11 lines
Quoted 10 lines
user at devuan:/sys/class/power_supply/battery$ date; cat
current_nowcurrent_avg
Thu May 3 09:33:07 CEST 2018
-56000
-72308
user at devuan:/sys/class/power_supply/battery$ date; catcurrent_nowcurrent_avg
Thu May 3 09:33:08 CEST 2018
-37000
-211362
Quoted 3 lines
I recall it just being calculated based on the time between the reads. Hard to say what it does,
-ENODOCS.. Maybe the mc13783 PMIC docs have something similar.
Hmm. current_avg is world readable; if it does changes to the hardware, that's somehow bad.
But I guess I can sample charge_counter every minute or so and get what I need?
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
Hmm oh and the
POWER_SUPPLY_CHARGE_COUNTERvalue should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes toPOWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved onPOWER_SUPPLY_CAPACITY_LEVEL_FULL.Quoted 6 lines
Quoted 3 lines
Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and
POWER_SUPPLY_POWER_AVG.I'll look into that... but probably will do experiments with python, first.
Quoted 8 lines
Sure. The reason why I think we should not do it in the kernel in addition to the earlier reasoning is that we don't have a place to store the min and max values across reboot. I think there's some flash on the battery over 1w bus, but it probably just contains battery serial number or something and is not intended for writing much to it. I guess the min and max values should be really keyd based on this battery id in case the battery gets changed.
I agree this should not be done in kernel as it requires persistent storage.
Battery is not user-replacable (and this will recalibrate itself on charge/discharge cycle) so.. I don't think keying is strictly neccessary for D4.
Best regards,
Pavel
Signature · 9 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/1468df3d/attachment.sig>
Quoted 13 lines · Pavel Machek
Hi!
Quoted 11 lines
Quoted 10 lines
user at devuan:/sys/class/power_supply/battery$ date; cat
current_nowcurrent_avg
Thu May 3 09:33:07 CEST 2018
-56000
-72308
user at devuan:/sys/class/power_supply/battery$ date; catcurrent_nowcurrent_avg
Thu May 3 09:33:08 CEST 2018
-37000
-211362
Quoted 6 lines
Quoted 3 lines
I recall it just being calculated based on the time between the reads. Hard to say what it does,
-ENODOCS.. Maybe the mc13783 PMIC docs have something similar.Hmm.
current_avgis world readable; if it does changes to the hardware, that's somehow bad.
No it just calls cpcap_battery_cc_get_avg_current() that calculates the average from last time it got sampled based on number of samples collected between the two reads. Seems to match what I see on my power supply here.
Quoted 2 lines
But I guess I can sample
charge_counterevery minute or so and get what I need?
Not sure what the max time range is for the PMIC, but yeah I'd assume once a minute is duoable. Maybe compare it to the chart you already have?
Quoted 22 lines
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
Hmm oh and the
POWER_SUPPLY_CHARGE_COUNTERvalue should be monitored by your libbattery and it's low value and high value should be saved to a file. Low should be saved when we get the battery low interrupt and battery state changes toPOWER_SUPPLY_CAPACITY_LEVEL_CRITICAL. High value should be saved onPOWER_SUPPLY_CAPACITY_LEVEL_FULL.Quoted 6 lines
Quoted 3 lines
Then when you know the high value and low value, you can calculate the remaining capacity based on the current value and
POWER_SUPPLY_POWER_AVG.I'll look into that... but probably will do experiments with python, first.
Quoted 8 lines
Sure. The reason why I think we should not do it in the kernel in addition to the earlier reasoning is that we don't have a place to store the min and max values across reboot. I think there's some flash on the battery over 1w bus, but it probably just contains battery serial number or something and is not intended for writing much to it. I guess the min and max values should be really keyd based on this battery id in case the battery gets changed.
Quoted 6 lines
I agree this should not be done in kernel as it requires persistent storage.
Battery is not user-replacable (and this will recalibrate itself on charge/discharge cycle) so.. I don't think keying is strictly neccessary for D4.
Yeah right, that can be added later on if needed if you just plan accordingly. It's replaceable with a T5 after you peel off the sticker from the corners :)
Regards,
Tony
Hi!
Quoted 6 lines
Quoted 2 lines
But I guess I can sample
charge_counterevery minute or so and get what I need?Not sure what the max time range is for the PMIC, but yeah I'd assume once a minute is duoable. Maybe compare it to the chart you already have?
Yes, I can try some more graph painting.
OTOH... battery life is "good enough" and I can already tell when the battery is full :-). So this part is not critical.
Quoted 10 lines
Quoted 6 lines
I agree this should not be done in kernel as it requires persistent storage.
Battery is not user-replacable (and this will recalibrate itself on charge/discharge cycle) so.. I don't think keying is strictly neccessary for D4.
Yeah right, that can be added later on if needed if you just plan accordingly. It's replaceable with a T5 after you peel off the sticker from the corners :)
Aha, I wanted to ask what kind of phone T5 is, and T5 is probably torx 5 screwdriver, right? Well, I don't have second battery, so these experiments will have to wait.
Best regards,
Pavel
Signature · 9 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180504/43e08e08/attachment.sig>
Quoted 11 lines · Pavel Machek
Quoted 7 lines
Quoted 3 lines
Battery is not user-replacable (and this will recalibrate itself on charge/discharge cycle) so.. I don't think keying is strictly neccessary for D4.
Yeah right, that can be added later on if needed if you just plan accordingly. It's replaceable with a T5 after you peel off the sticker from the corners :)
Aha, I wanted to ask what kind of phone T5 is, and T5 is probably torx 5 screwdriver, right? Well, I don't have second battery, so these experiments will have to wait.
Yes torx 5 is needed to swap the battery.
Regards,
Tony