* Motorola Droid 4 progress, power consumption
@ 2018-05-01 18:31 Pavel Machek
2018-05-02 14:41 ` Tony Lindgren
0 siblings, 1 reply; 21+ messages in thread
From: Pavel Machek @ 2018-05-01 18:31 UTC (permalink / raw)
To: kernel list, linux-arm-kernel, linux-omap, tony, sre, nekit1000,
mpartap, merlijn
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-01 18:31 Motorola Droid 4 progress, power consumption Pavel Machek
@ 2018-05-02 14:41 ` Tony Lindgren
0 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-02 14:41 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-02 14:41 ` Tony Lindgren
0 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-02 14:41 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-02 14:41 ` Tony Lindgren
@ 2018-05-02 19:10 ` Pavel Machek
-1 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-02 19:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-02 19:10 ` Pavel Machek
0 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-02 19:10 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-02 19:10 ` Pavel Machek
@ 2018-05-02 19:42 ` Tony Lindgren
-1 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-02 19:42 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-02 19:42 ` Tony Lindgren
0 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-02 19:42 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-02 19:42 ` Tony Lindgren
@ 2018-05-02 21:32 ` Pavel Machek
-1 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-02 21:32 UTC (permalink / raw)
To: Tony Lindgren
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-02 14:41 ` Tony Lindgren
@ 2018-05-03 9:06 ` Pavel Machek
-1 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-03 9:06 UTC (permalink / raw)
To: Tony Lindgren
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-03 9:06 ` Pavel Machek
0 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-03 9:06 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-03 9:06 ` Pavel Machek
@ 2018-05-03 14:22 ` Tony Lindgren
-1 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-03 14:22 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-03 14:22 ` Tony Lindgren
0 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-03 14:22 ` Tony Lindgren
@ 2018-05-04 20:20 ` Pavel Machek
-1 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-04 20:20 UTC (permalink / raw)
To: Tony Lindgren
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-04 20:20 ` Pavel Machek
0 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-04 20:20 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-04 20:20 ` Pavel Machek
@ 2018-05-04 20:38 ` Tony Lindgren
-1 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-04 20:38 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-04 20:38 ` Tony Lindgren
0 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-04 20:38 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-04 20:38 ` Tony Lindgren
@ 2018-05-04 21:47 ` Pavel Machek
-1 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-04 21:47 UTC (permalink / raw)
To: Tony Lindgren
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-04 21:47 ` Pavel Machek
0 siblings, 0 replies; 21+ messages in thread
From: Pavel Machek @ 2018-05-04 21:47 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Motorola Droid 4 progress, power consumption
2018-05-04 21:47 ` Pavel Machek
@ 2018-05-05 19:44 ` Tony Lindgren
-1 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-05 19:44 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, linux-arm-kernel, linux-omap, sre, nekit1000,
mpartap, merlijn
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Motorola Droid 4 progress, power consumption
@ 2018-05-05 19:44 ` Tony Lindgren
0 siblings, 0 replies; 21+ messages in thread
From: Tony Lindgren @ 2018-05-05 19:44 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2018-05-05 19:44 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-01 18:31 Motorola Droid 4 progress, power consumption Pavel Machek
2018-05-02 14:41 ` Tony Lindgren
2018-05-02 14:41 ` Tony Lindgren
2018-05-02 19:10 ` Pavel Machek
2018-05-02 19:10 ` Pavel Machek
2018-05-02 19:42 ` Tony Lindgren
2018-05-02 19:42 ` Tony Lindgren
2018-05-02 21:32 ` Pavel Machek
2018-05-02 21:32 ` Pavel Machek
2018-05-03 9:06 ` Pavel Machek
2018-05-03 9:06 ` Pavel Machek
2018-05-03 14:22 ` Tony Lindgren
2018-05-03 14:22 ` Tony Lindgren
2018-05-04 20:20 ` Pavel Machek
2018-05-04 20:20 ` Pavel Machek
2018-05-04 20:38 ` Tony Lindgren
2018-05-04 20:38 ` Tony Lindgren
2018-05-04 21:47 ` Pavel Machek
2018-05-04 21:47 ` Pavel Machek
2018-05-05 19:44 ` Tony Lindgren
2018-05-05 19:44 ` Tony Lindgren
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.