From: Tony Lindgren <tony@atomide.com> Date: 2018-05-02 14:42:03
* Pavel Machek [off-list ref] [180501 18:33]:
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
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? :)
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
From: Pavel Machek <hidden> Date: 2018-05-02 19:10:52
Hi!
quoted
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? :)
Plus some other patches, yes.
quoted
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.
Aha, I was looking in the wrong directory. Yes, these look useful.
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.
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.
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Tony Lindgren <tony@atomide.com> Date: 2018-05-02 19:42:36
* Pavel Machek [off-list ref] [180502 19:12]:
Hi!
quoted
quoted
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? :)
Plus some other patches, yes.
Cool :)
quoted
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
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.
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.
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.
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 :)
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
From: Pavel Machek <hidden> Date: 2018-05-02 21:32:16
Hi!
quoted
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.
From: Pavel Machek <hidden> Date: 2018-05-03 09:06:15
Hi!
quoted
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
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.
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
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.
From: Tony Lindgren <tony@atomide.com> Date: 2018-05-03 14:22:45
* Pavel Machek [off-list ref] [180503 09:08]:
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
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
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.
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
From: Pavel Machek <hidden> Date: 2018-05-04 20:20:47
Hi!
quoted
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
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
quoted
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.
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.
From: Tony Lindgren <tony@atomide.com> Date: 2018-05-04 20:38:24
* Pavel Machek [off-list ref] [180504 20:22]:
Hi!
quoted
quoted
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
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.
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.
But I guess I can sample charge_counter every 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
quoted
quoted
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.
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.
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
From: Pavel Machek <hidden> Date: 2018-05-04 21:47:26
Hi!
quoted
But I guess I can sample charge_counter every 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
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 :)
From: Tony Lindgren <tony@atomide.com> Date: 2018-05-05 19:44:52
* Pavel Machek [off-list ref] [180504 21:49]:
quoted
quoted
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