Motorola Droid 4 progress, power consumption

Motorola Droid 4 progress, power consumption

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 657 bytes --]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: foo.png --]
[-- Type: image/png, Size: 110021 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [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

Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [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

Re: Motorola Droid 4 progress, power consumption

[Pavel Machek]

Hi!

> > 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.

> > 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

Motorola Droid 4 progress, power consumption

[Pavel Machek]

Hi!

> > 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.

> > 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

Re: Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180502 19:12]:
> Hi!
> 
> > > 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 :)

> > 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

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

Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180502 19:12]:
> Hi!
> 
> > > 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 :)

> > 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

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

Re: Motorola Droid 4 progress, power consumption

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Hi!

> > 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Motorola Droid 4 progress, power consumption

[Pavel Machek]

Hi!

> > 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
-- 
(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>

Re: Motorola Droid 4 progress, power consumption

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2442 bytes --]

Hi!

> > 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.

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@devuan:/sys/class/power_supply/battery$ date; cat current_now
current_avg
Thu May  3 09:33:05 CEST 2018
-71000
-218408
user@devuan:/sys/class/power_supply/battery$ date; cat current_now
current_avg
Thu May  3 09:33:06 CEST 2018
-61000
-200238
user@devuan:/sys/class/power_supply/battery$ date; cat current_now
current_avg
Thu May  3 09:33:06 CEST 2018
-51000
-209879
user@devuan:/sys/class/power_supply/battery$ date; cat current_now
current_avg
Thu May  3 09:33:07 CEST 2018
-56000
-72308
user@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.

I'll look into that... but probably will do experiments with python,
first.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Motorola Droid 4 progress, power consumption

[Pavel Machek]

Hi!

> > 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.

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.

I'll look into that... but probably will do experiments with python,
first.

Best regards,
									Pavel
-- 
(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>

Re: Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [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@devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May  3 09:33:05 CEST 2018
> -71000
> -218408
> user@devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May  3 09:33:06 CEST 2018
> -61000
> -200238
> user@devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May  3 09:33:06 CEST 2018
> -51000
> -209879
> user@devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May  3 09:33:07 CEST 2018
> -56000
> -72308
> user@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 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

Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [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.

> > 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

Re: Motorola Droid 4 progress, power consumption

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

Hi!

> > user@devuan:/sys/class/power_supply/battery$ date; cat current_now
> > current_avg
> > Thu May  3 09:33:07 CEST 2018
> > -56000
> > -72308
> > user@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?

> > > 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.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Motorola Droid 4 progress, power consumption

[Pavel Machek]

Hi!

> > 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?

> > > 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.

Best regards,
									Pavel
-- 
(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>

Re: Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180504 20:22]:
> Hi!
> 
> > > user@devuan:/sys/class/power_supply/battery$ date; cat current_now
> > > current_avg
> > > Thu May  3 09:33:07 CEST 2018
> > > -56000
> > > -72308
> > > user@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?

> > > > 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

Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180504 20:22]:
> Hi!
> 
> > > 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?

> > > > 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

Re: Motorola Droid 4 progress, power consumption

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Hi!

> > 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.

> > 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Motorola Droid 4 progress, power consumption

[Pavel Machek]

Hi!

> > 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.

> > 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
-- 
(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>

Re: Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180504 21:49]:
> > > 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

Motorola Droid 4 progress, power consumption

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [180504 21:49]:
> > > 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