Currently we are assuming batt_mode would never be zero, but that is not
always true. Some battery do report zero for batt_mode(bob for example).
So everytime the batt_mode_cache been set to zero, the virtual_battery
would consider it uninited, and tries to refresh the next time.
Use -1 as uninited batt_mode_cache to avoid that.
BUG=b:66555246
BRANCH=gru
TEST=Check on bob, the battery level is correct.
Change-Id: Ieb7ec9403f69a6b5bca93c6682ec6117fe95fe1e
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/678135
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Virtual battery implements a smart battery interface, but the actual
battery on the system may speak a different protocol. Support such
batteries by removing direct i2c access from the virtual battery driver.
Fetch data from storage when available, and call generic battery
routines when not.
BUG=chromium:717753
BRANCH=None
TEST=Manual on kevin, boot and verify "Unhandled VB reg" prints are not
seen. Verify by-eye that all regs in cros 4.4 kernel sbs-battery.c are
handled (except REG_MANUFACTURER_DATA). Verify that sysfs manufacturer,
model name, time_to_full_avg and time_to_empty_avg values are all sane.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia8fc0a80ac7576fa8bdcc3b7dac0609d9d754234
Reviewed-on: https://chromium-review.googlesource.com/547004
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The virtual battery "energy" readings were totally broken. Rather
than reporting things in units of "10 mW" they were reporting things
in units of "10 uW". That's because they were doing this math:
result = mV * mA / 10
Said another way:
result = (V / 1000) * (A / 1000) / 10
result = (V * A) / (100000) / 10
result = W / 1000000 / 10
result = uW / 10
Aside from the fact that clients were expecting things in "10 mW"
instead of "10 uW", we got even more random results. That's because
we return to the client in a 16-bit variable, so we were kinda
randomly truncating things.
Doh.
BRANCH=ToT
BUG=chromium:717304
TEST=power_supply_info
Unfortunately when you try to report sane values for "10 uA" in a
16-bit result, it doesn't work too well (
Change-Id: I8075dffd7ab6b372be5b8fdf293acc96c5878036
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/492546
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 01ceab68cd6b542f8c6355425e6ac6da698e0ebf)
Reviewed-on: https://chromium-review.googlesource.com/492568
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
In some cases, the virtual battery code creates
transactions that violate SB spec.
One example:
If the host command is structured as two messages -
a write to 0x03 (reg addr), followed by two bytes of write data,
the first byte of the second message (write data) will be sent to
virtual_battery_read(), as if it were a reg read request.
Let's do the following change for virtual battery:
1. Parse the command more carefully with state machines.
2. Support write caching for some critical registers.
3. Cache more attributes (0x03 and 0x0f).
BUG=chrome-os-partner:59239, chromium:659819
BRANCH=none
TEST='power_supply_info' works on kevin
Change-Id: Icdeb12b21f0dc3c329f29b206b7b9395ca4c9998
Reviewed-on: https://chromium-review.googlesource.com/407987
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
