networkimprov / arch-packages

1 stars 0 forks source link

battery gauge driver #31

Open networkimprov opened 9 years ago

networkimprov commented 9 years ago

Source: https://github.com/networkimprov/linux/blob/anvl-v4.7/drivers/power/bq27xxx_battery.c https://github.com/networkimprov/linux/blob/anvl-v4.7/drivers/power/bq27xxx_battery_i2c.c

1) verify driver with our gauge. Current_now is negative. Does it reflect measured current draw? Status is charging when really discharging.

2) what uevents (e.g. power_supply_changed()) does this emit, on what conditions? We probably want a sequence of events on low battery, e.g. 15, 10, 8, 6, 4, 2, 1% A udev rule will alert user, (alt-)suspend, or power off. Alt-suspend: https://github.com/networkimprov/arch-packages/issues/42

3) skip poll_interval_param_set if interval is unchanged.

let PMIC turn off itself from alt-suspend state? probably not.

mranostay commented 8 years ago

Can confirm power_supply_changed() is the only visible uevent from the driver. Need to check the effort for battery percentage calculations.

mranostay commented 8 years ago

@networkimprov @tmlind Reviewing the other battery drivers in drivers/power and none use uevents to report battery levels. Are we sure that we want to rely on uevents + udev?

Seems an daemon service polling the battery capacity property would be a better solution?

networkimprov commented 8 years ago

Under what conditions does the driver call power_supply_changed()? I imagined catching one of those events...

Does the driver already support sysfs_notify?

mranostay commented 8 years ago

On Tue, Sep 13, 2016 at 4:13 PM, Liam notifications@github.com wrote:

Under what conditions does the driver call power_supply_changed()? I imagined catching one of those events...

Actually it is reporting battery percentage left in 3% steps.. so nothing to do here kernel wise.

$ udevadm monitor --kernel --property .... ACTION=change DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 POWER_SUPPLY_CAPACITY=85 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_CHARGE_FULL=1127000 POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000 POWER_SUPPLY_CHARGE_NOW=996000 POWER_SUPPLY_CURRENT_NOW=-340000 POWER_SUPPLY_MANUFACTURER=Texas Instruments POWER_SUPPLY_NAME=bq27425-0 POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_TEMP=457 POWER_SUPPLY_VOLTAGE_NOW=3841000 SEQNUM=1430 SUBSYSTEM=power_supply ...

Does the driver already support sysfs_notify?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-246855574, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOcyXJQuzq1pICfdVug2WSZL68GOgks5qpy4GgaJpZM4DSnCg .

networkimprov commented 8 years ago

OK, but maybe it should report more often under 10%...

mranostay commented 8 years ago

Ah it is a poll interval of 6 minutes, not anything with 3% discharge. Do you want to decrease the poll_interval?
..... static unsigned int poll_interval = 360;
module_param(poll_interval, uint, 0644);
MODULE_PARM_DESC(poll_interval,
"battery poll interval in seconds - 0 disables polling");
.....

networkimprov commented 8 years ago

Ya, let's reduce that under 10% to 3min, and maybe again to 1min.

mranostay commented 8 years ago

Ok will add this functionality today.

mranostay commented 8 years ago

@tmlind @networkimprov Patchset to enable configurable poll_interval rates for battery level

https://github.com/networkimprov/linux/commit/524bf5b08794abb354432996d55d1e0d4258d576.patch https://github.com/networkimprov/linux/commit/cc51ae388ff936ce4647d691c5cadc88232ee0b6.patch

networkimprov commented 8 years ago

Is OK/preferable to make a new branch (off anvl-v4.7) for patches to a diff component :-)

networkimprov commented 8 years ago

I don't think we need to emit uevent if the battery level hasn't changed since last poll.

Can you draft a sample udev rule for the gauge? I gather it can adjust the poll_interval depending on battery capacity?

mranostay commented 8 years ago

Ok I'll look into the udev rule... not sure you can have conditionals greater or less than for battery capacity rule

networkimprov commented 8 years ago

I'll add a couple rules with wildcards to adjust down the poll_interval, just need to know how to set it, e.g.

KERNEL=="bq..." ACTION=="change" ATTR{voltage}=="3.[65]*" ATTR{poll_interval}="180" RUN+="/bin/sh -c 'echo DING > /dev/console'"
networkimprov commented 8 years ago

Can you test this rule idea...

KERNEL=="bq..." ACTION=="change" ATTR{voltage}=="3.[65]*" ATTR{poll_interval}="180" RUN+="/bin/sh -c 'echo DING > /dev/console'"
mranostay commented 8 years ago

On Fri, Sep 16, 2016 at 12:18 PM, Liam notifications@github.com wrote:

Can you test this rule idea...

Ok will do.. I think the voltage needs to be voltage_now and it isn't a floating point but in microvolts

KERNEL=="bq..." ACTION=="change" ATTR{voltage}=="3.[65]*" ATTR{poll_interval}="180" RUN+="/bin/sh -c 'echo DING > /dev/console'"

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-247684554, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOXdSnzHXUH35ASL1JVLQzDXJpoHFks5qquuYgaJpZM4DSnCg .

networkimprov commented 8 years ago

Should match uV: {voltage_now}=="3[654]?????"

mranostay commented 8 years ago

KERNEL=="bq27425-0" ACTION=="change" ATTRS{voltage_now}=="3[56]*" RUN+="/bin/sh -c 'echo DING > /dev/console'"

Works. However dropped the ATTRS{poll_interval} because that will not exist because /sys/module/bq27xxx_battery/parameters/poll_interval is the correct place since it already exists

@tmlind Please review. https://github.com/networkimprov/linux/commit/cba20bc11b8a3c6a469e2401a3670201f8d12e15.patch

networkimprov commented 8 years ago

We need to write poll_interval from the rule. Can we move the existing sysfs entity, or add a sysfs entity which is an alias for it?

mranostay commented 8 years ago

Can't do?

KERNEL=="bq27425-0" ACTION=="change" ATTRS{voltage_now}=="3[56]*" RUN+="/bin/sh -c 'echo 10 > /sys/module/bq27xxx_battery/parameters/poll_interval'"

networkimprov commented 8 years ago

Well, ya, but that's not what users expect; voltage_now is available; why not poll_interval?

mranostay commented 8 years ago

On Fri, Sep 16, 2016 at 6:41 PM, Liam notifications@github.com wrote:

Well, ya, but that's not what users expect; voltage_now is available; why not poll_interval?

voltage_now is an actual device related to a changing quantity.

poll_interval is a kernel parameter isn't going to change without userspace doing it, and I don't see anyone basing rules on what a ATTR{poll_interval} is set too (and really shouldn't). And much more importantly the sysfs way will not be accepted upstream (at least I suspect so, maybe Tony has thoughts on that) because a kernel parameter already exists.

You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-247741868, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOUIheAn6tdmabjo2vXKjEN1xrbSlks5qq0U3gaJpZM4DSnCg .

networkimprov commented 8 years ago

I need it accessible in udev to assign to it, not read it; lots of rules do ATTR{thing}="x"

mranostay commented 8 years ago

On Fri, Sep 16, 2016 at 7:31 PM, Liam notifications@github.com wrote:

I need it accessible in udev to assign to it, not read it; lots of rules do ATTR{thing}="x"

Ah of course... ok so the previous patchset is good enough for that then. Having that use case maybe upstream will be okay... be nice to avoid any technical debt though

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-247744214, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOT1kxqrAKG49Vn0_Xdd6KNiL9N0aks5qq1EFgaJpZM4DSnCg .

networkimprov commented 8 years ago

Can you post patch you sent upstream to your bq27xxx branch (after reverting https://github.com/networkimprov/linux/commit/2aeea223) ?

The power-supply fix, if allowed upstream, can also go on this branch.

mranostay commented 8 years ago

Ok will do.

On Tue, Sep 20, 2016 at 11:12 AM, Liam notifications@github.com wrote:

Can you post patch you sent upstream to your bq27xxx branch (after reverting networkimprov/linux@2aeea22 https://github.com/networkimprov/linux/commit/2aeea223) ?

The power-supply fix, if allowed upstream, can also go on this branch.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248384942, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXORIblAm8vr2sJjygYvfJP7ztZfLkks5qsCH4gaJpZM4DSnCg .

networkimprov commented 8 years ago

Re property UPDATE_INTERVAL when I apply these two https://github.com/networkimprov/linux/commit/2626f43c (accepted upstream) https://github.com/networkimprov/linux/compare/b2cc66eb...7bf8c2ef (new patches)

I get: error: patch failed: drivers/power/bq27xxx_battery.c:1026 error: drivers/power/bq27xxx_battery.c: patch does not apply

mranostay commented 8 years ago

On Tue, Sep 20, 2016 at 8:16 PM, Liam notifications@github.com wrote:

Re property UPDATE_INTERVAL when I apply these two networkimprov/linux@2626f43 https://github.com/networkimprov/linux/commit/2626f43c (accepted upstream) networkimprov/linux@b2cc66e...7bf8c2e https://github.com/networkimprov/linux/compare/b2cc66eb...7bf8c2ef (new patches)

I get: error: patch failed: drivers/power/bq27xxx_battery.c:1026 error: drivers/power/bq27xxx_battery.c: patch does not apply

Probably since I reverted that sysfs way in that branch as well.. we probably want rebase interactive and drop the reverts and original patches at some point.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248500032, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOQT6gqDJxl5QQTG3ZcwNapt6ji0uks5qsKGcgaJpZM4DSnCg .

networkimprov commented 8 years ago

Would you want to call the new poll_interval_param_set() in new set_property()?

mranostay commented 8 years ago

On Tue, Sep 20, 2016 at 8:33 PM, Liam notifications@github.com wrote:

Would you want to call the new poll_interval_param_set() in net set_property()?

I don't, and this has nothing to do with that other method. What I am saying is a simple cherry-pick to the anvl-4.7 branch isn't going to work.

Note the revert here of the sysfs way of updating https://github.com/networkimprov/linux/commit/b2cc66eb60dbd4f78cffaf857e1ea7c4e1c61a10

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248502190, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOemKIF3RnwassoThZXc8VbbfyucAks5qsKVxgaJpZM4DSnCg .

networkimprov commented 8 years ago

You can fix the patch-apply issue when sending upstream; not important for me now.

Aren't poll_interval_param_set() and set_property() updating the same field?

mranostay commented 8 years ago

On Tue, Sep 20, 2016 at 8:49 PM, Liam notifications@github.com wrote:

You can fix the patch-apply issue when sending upstream; not important for me now.

Aren't poll_interval_param_set() and set_property() updating the same field?

Yes there are. Shouldn't need locking on the global... ideally it would be in the data struct for the driver, but can't break the ABI.

Maybe Tony can comment on if this is the best way.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248504204, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOa90KYBy0zezc-UhM4QkQfpydMEwks5qsKlQgaJpZM4DSnCg .

networkimprov commented 8 years ago

Ah, setting module param updates every instance of the driver, and new patch updates one instance. Why didncha say so! :-)

networkimprov commented 8 years ago

This file needs a description of the new param: https://github.com/networkimprov/linux/blob/anvl-v4.7-bq27xxx/Documentation/power/power_supply_class.txt

There are two existing time parameters; maybe we should use "TIME_TO_UPDATE"?

TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load)
TIME_TO_FULL - seconds left for battery to be considered full (i.e. while battery is charging)
networkimprov commented 8 years ago

Besides docs, looks good to go upstream :-)

If they complain that we are the only client for this option, I'm sure we can find other drivers that are the sole clients of different options!

mranostay commented 8 years ago

On Wed, Sep 21, 2016 at 11:50 AM, Liam notifications@github.com wrote:

This file needs a description of the new param: https://github.com/networkimprov/linux/blob/anvl- v4.7-bq27xxx/Documentation/power/power_supply_class.txt

There are two existing time parameters; maybe we should use "TIME_TO_UPDATE"?

Yeah only issue with using that is that assumes it is a countdown till the next update...

TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load) TIME_TO_FULL - seconds left for battery to be considered full (i.e. while battery is charging)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248706529, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOdz4dkMof2047APAYZrDWvaPdb4gks5qsXxegaJpZM4DSnCg .

networkimprov commented 8 years ago

True, and time_between_updates is a lil verbose. Perhaps stick with poll_interval since that's the module param?

networkimprov commented 8 years ago

fyi, I pushed patch already accepted upstream to anvl-v4.7

networkimprov commented 8 years ago

What do you think about reposting this patchset with a Documentation rev, and CC'ing Sebastian? http://lkml.iu.edu/hypermail/linux/kernel/1609.2/04064.html

mranostay commented 8 years ago

Ok needs to be done. Better than poking him I guess :)

On Mon, Sep 26, 2016 at 2:09 PM, Liam notifications@github.com wrote:

What do you think about reposting this patchset with a Documentation rev, and CC'ing Sebastian? http://lkml.iu.edu/hypermail/linux/kernel/1609.2/04064.html

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249698182, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOZ0xV7vBllCAttRmhpY0bINW3a9uks5quDRtgaJpZM4DSnCg .

networkimprov commented 8 years ago

Yes :) Post docs commit on https://github.com/networkimprov/linux/commits/anvl-v4.7-bq27xxx

networkimprov commented 8 years ago

Proposed param docs:

TIME_TO_FULL - seconds left for battery ...
POLL_INTERVAL - seconds between I2C requests to retrieve battery
stats from chip.

https://github.com/networkimprov/linux/blob/anvl-v4.7-bq27xxx/Documentation/power/power_supply_class.txt

mranostay commented 8 years ago

On Mon, Sep 26, 2016 at 8:32 PM, Liam notifications@github.com wrote:

Proposed param docs:

TIME_TO_FULL - seconds left for battery ... POLL_INTERVAL - seconds between I2C requests to retrieve battery stats from chip.

We shouldn't say the interface.. it doesn't have to be I2C there are likely SPI, and other interface fuel gauge parts.

https://github.com/networkimprov/linux/blob/anvl- v4.7-bq27xxx/Documentation/power/power_supply_class.txt

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249757628, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOTuez-P2VHpY6ep3q4ZZ279ANHaMks5quI5MgaJpZM4DSnCg .

networkimprov commented 8 years ago

OK

networkimprov commented 8 years ago

Unrelated to poll_interval... We used to apply this patch. The current code has just one compatible item and no #else section. Do we need this?

+#ifdef CONFIG_OF
+static const struct of_device_id bq27xxx_of_match[] = {
+       { .compatible = "ti,bq27200", },
+       { .compatible = "ti,bq27500", },
+       { .compatible = "ti,bq27425", },
+       { .compatible = "ti,bq27742", },
+       { .compatible = "ti,bq27518", },
+       { },
+};
+MODULE_DEVICE_TABLE(of, bq27xxx_of_match);
+#else
+static const struct of_device_id bq27xxx_of_match[] = {
+       { },
+};
+#endif
mranostay commented 8 years ago

On Tue, Sep 27, 2016 at 1:20 PM, Liam notifications@github.com wrote:

Unrelated to poll_interval... We used to apply this patch. The current code has just one compatible item and no #else section. Do we need this?

Probably not.. but I'll check this afternoon

+#ifdef CONFIG_OF +static const struct of_device_id bq27xxx_of_match[] = {

  • { .compatible = "ti,bq27200", },
  • { .compatible = "ti,bq27500", },
  • { .compatible = "ti,bq27425", },
  • { .compatible = "ti,bq27742", },
  • { .compatible = "ti,bq27518", },
  • { }, +}; +MODULE_DEVICE_TABLE(of, bq27xxx_of_match); +#else +static const struct of_device_id bq27xxx_of_match[] = {
  • { }, +}; +#endif

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249986043, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOWXoWXiG8-qLEXCo3kBn0_XMeQwgks5quXqAgaJpZM4DSnCg .

mranostay commented 8 years ago

On Tue, Sep 27, 2016 at 1:33 PM, Matt Ranostay mranostay@gmail.com wrote:

On Tue, Sep 27, 2016 at 1:20 PM, Liam notifications@github.com wrote:

Unrelated to poll_interval... We used to apply this patch. The current code has just one compatible item and no #else section. Do we need this?

Probably not.. but I'll check this afternoon

We could change the "ti,bq27425" in our device tree to "ti,bq27000" so we don't have to worry about that patchset.

I suspect a) another version got upstreamed b) or the maintainer rathers to keep the match table more generic unless a device needs the data pointer.

+#ifdef CONFIG_OF +static const struct of_device_id bq27xxx_of_match[] = {

  • { .compatible = "ti,bq27200", },
  • { .compatible = "ti,bq27500", },
  • { .compatible = "ti,bq27425", },
  • { .compatible = "ti,bq27742", },
  • { .compatible = "ti,bq27518", },
  • { }, +}; +MODULE_DEVICE_TABLE(of, bq27xxx_of_match); +#else +static const struct of_device_id bq27xxx_of_match[] = {
  • { }, +}; +#endif

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249986043, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOWXoWXiG8-qLEXCo3kBn0_XMeQwgks5quXqAgaJpZM4DSnCg .

networkimprov commented 8 years ago

Please review the same two patchsets from before now on the anvl-v4.7-bq27xxx branch. Only changes is the property name and two patchsets have been squashed. Let me know if anything needs to be updated (maybe docs ?) before sending off v2

There's a grammar flaw in docs. How about:

POLL_INTERVAL - seconds between queries to retrieve stats from hardware.

mranostay commented 8 years ago

Sent from my iPhone

On Sep 27, 2016, at 18:04, Liam notifications@github.com wrote:

Please review the same two patchsets from before now on the anvl-v4.7-bq27xxx branch. Only changes is the property name and two patchsets have been squashed. Let me know if anything needs to be updated (maybe docs ?) before sending off v2

There's a grammar flaw in docs. How about:

POLL_INTERVAL - seconds between queries to retrieve stats from hardware.

Ok thought I recalled a comment about that issue. Will fix

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

networkimprov commented 8 years ago

My gauge claims to be charging when it's discharging. The first check, shortly after boot, is correct. Within an hour it was wrong. Hope this is a driver bug vs hw...

[root@anvl ~]# udevadm info /sys/class/power_supply/bq27425-0
P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: POWER_SUPPLY_CAPACITY=86
E: POWER_SUPPLY_CAPACITY_LEVEL=Normal
E: POWER_SUPPLY_CHARGE_FULL=1178000
E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000
E: POWER_SUPPLY_CHARGE_NOW=1037000
E: POWER_SUPPLY_CURRENT_NOW=-47000
E: POWER_SUPPLY_MANUFACTURER=Texas Instruments
E: POWER_SUPPLY_NAME=bq27425-0
E: POWER_SUPPLY_PRESENT=1
E: POWER_SUPPLY_STATUS=Discharging <========== OK ==========<
E: POWER_SUPPLY_TECHNOLOGY=Li-ion
E: POWER_SUPPLY_TEMP=304
E: POWER_SUPPLY_VOLTAGE_NOW=3979000
E: SUBSYSTEM=power_supply

P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: POWER_SUPPLY_CAPACITY=82
E: POWER_SUPPLY_CAPACITY_LEVEL=Normal
E: POWER_SUPPLY_CHARGE_FULL=1178000
E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000
E: POWER_SUPPLY_CHARGE_NOW=996000
E: POWER_SUPPLY_CURRENT_NOW=-54000
E: POWER_SUPPLY_MANUFACTURER=Texas Instruments
E: POWER_SUPPLY_NAME=bq27425-0
E: POWER_SUPPLY_PRESENT=1
E: POWER_SUPPLY_STATUS=Charging <========== WRONG ==========<
E: POWER_SUPPLY_TECHNOLOGY=Li-ion
E: POWER_SUPPLY_TEMP=264
E: POWER_SUPPLY_VOLTAGE_NOW=3975000
E: SUBSYSTEM=power_supply
mranostay commented 8 years ago

On Tue, Sep 27, 2016 at 11:45 PM, Liam notifications@github.com wrote:

My gauge claims to be charging when it's discharging. The first check, shortly after boot, is correct. Within an hour it was wrong. Hope this is a driver bug vs hw...

Scary but I don't think any kernel changes we have done could cause this.

We need to check how the POWER_SUPPLY_STATUS state is set.... call be naive but battery charging circuits (not the fuel gauge in this case) are rather well validated because of lawsuits from fires.

Fuel gauge reporting charging doesn't exactly mean it is esp if is using a metric like voltage change.. but late will check in the morning :)

[root@anvl ~]# udevadm info /sys/class/power_supply/bq27425-0 P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: POWER_SUPPLY_CAPACITY=86 E: POWER_SUPPLY_CAPACITY_LEVEL=Normal E: POWER_SUPPLY_CHARGE_FULL=1178000 E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000 E: POWER_SUPPLY_CHARGE_NOW=1037000 E: POWER_SUPPLY_CURRENT_NOW=-47000 E: POWER_SUPPLY_MANUFACTURER=Texas Instruments E: POWER_SUPPLY_NAME=bq27425-0 E: POWER_SUPPLY_PRESENT=1 E: POWER_SUPPLY_STATUS=Discharging <========== OK ==========< E: POWER_SUPPLY_TECHNOLOGY=Li-ion E: POWER_SUPPLY_TEMP=304 E: POWER_SUPPLY_VOLTAGE_NOW=3979000 E: SUBSYSTEM=power_supply

P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: POWER_SUPPLY_CAPACITY=82 E: POWER_SUPPLY_CAPACITY_LEVEL=Normal E: POWER_SUPPLY_CHARGE_FULL=1178000 E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000 E: POWER_SUPPLY_CHARGE_NOW=996000 E: POWER_SUPPLY_CURRENT_NOW=-54000 E: POWER_SUPPLY_MANUFACTURER=Texas Instruments E: POWER_SUPPLY_NAME=bq27425-0 E: POWER_SUPPLY_PRESENT=1 E: POWER_SUPPLY_STATUS=Charging <========== WRONG ==========< E: POWER_SUPPLY_TECHNOLOGY=Li-ion E: POWER_SUPPLY_TEMP=264 E: POWER_SUPPLY_VOLTAGE_NOW=3975000 E: SUBSYSTEM=power_supply

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-250085313, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOTRXpf9Llcn-whxDdUKlUFMQ4SUCks5qug0SgaJpZM4DSnCg .