Rather than implementing board version only for Link, implement for each
board which has version strapping.
BUG=chrome-os-partner:20295.
TEST=Manual. Run "ver" command on Peppy, verify correct board version is
returned.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I57656a645c6bcd1fdb2e7e4aba91b4ec4b8ad8ec
Reviewed-on: https://gerrit.chromium.org/gerrit/61186
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
BUG=chrome-os-partner:20720
BRANCH=peppy
TEST=Run 'ectool batterycutoff' on the DUT, shut it down, and unplug
AC power. Verify the only way to turn it on is by plugging the AC power
back in.
Change-Id: Ia6a93249843b72f4396d083cfe15a263d0a1836d
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61047
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
STM32L erases flash to 0, not 1, so we need a config value to indicate
that. This speeds up flash erase on STM32L by not re-erasing
already-erased blocks.
BUG=chrome-os-partner:13066
BRANCH=none
TEST=manual - hack flash_physical_erase() to print something just after
flash_is_erased() check.
1. flasherase 0x1f800 0x800
2. flashwrite 0x1fa00 0x100
3. flasherase 0x1f800 0x800 -> only re-erases 0x1fa00
Change-Id: I4d726caf0605e7815b9360bb2d44bdfdd757b4a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61110
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some chargers recover in about 1100 ms on overcurrent events. Let's
extend this delay to support more chargers.
BUG=chrome-os-partner:20408
TEST=Manual. Check we can reach a steady current with a charger that was
not supported before.
BRANCH=Spring
Original-Change-Id: I7db0f98110dcb225ea5f123400c539e6a1260156
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60316
Reviewed-by: Todd Broch <tbroch@chromium.org>
(cherry picked from commit 732f5130f1f7523ec18fb04d49ddeb1646389a2c)
Change-Id: I884f8008158bf57c7d18109fb7860432095923ae
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60624
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When we are redetecting, if ID_MUX is 1, we need to switch it back.
Otherwise, no one is there to switch it and we are stuck in this state.
BUG=None
TEST=Check the EC detects device type after redetecting from device type
0x60400.
BRANCH=Spring
Original-Change-Id: I42378e2ea9177962524af7316d76c54b2518e614
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60041
(cherry picked from commit 7ebc1b269360f54dde29e3ec75f44e1976a15992)
Change-Id: I89ec974030712dea6157405a3b1bc819dc130e94
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60623
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We've seen CABLE_DET being asserted hundreds of milliseconds after
ID_MUX is switched. To ensure video dongle is detected, let's poll
CABLE_DET for a second before declaring it an USB host.
BUG=chrome-os-partner:20405
TEST=Manual
BRANCH=Spring
Original-Change-Id: I1858f4075f526ee198b7b5f7ad2bb06cf6e3512c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59887
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
(cherry picked from commit 2d37619a934264cf4f902078b081b76d607ddce1)
Change-Id: I55fba167780fb7e04157655dc5b3a2e76b8999c5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If we are overloading the charger and it browns out, the kernel reacts
to this event as if the charger is disconnected. This may confuses the
user as the backlight brightness might change. Let's delay this until
the device type has stabilized.
BUG=None
TEST=Plug in a charger and observe backlight brightened. Check the
backlight brightness doesn't change while the charger is overloaded.
BRANCH=Spring
Original-Change-Id: Ie89ed4261912bfd8cd75a70e5058411f1c929aa9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59878
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit af770935938c99e17f99eea38bc1c0f34cc862fe)
Change-Id: I9c88d08100ba54f313506d495bc8e8dba5766dc7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This gets rid of mystery files like "ir357x" and "lp5562". All chip
names are now prefixed with their module type (e.g. "chipset_",
"led_driver_", etc.)
No functional changes; renaming files and CONFIG constants only.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I3227fb0f6b0243bb08a13577cdb0f6def0e15d54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60922
Note that the PP3300_LTE_EN signal does different things on
different boards. On peppy/slippy it controls both LTE power
and gates a wake interrupt to the PCH. On falco it just gates
the wake interrupt; module power is tied to the DX rail.
On all boards there is a separate DISABLE_L signal from the PCH.
BUG=chrome-os-partner:20513
BRANCH=falco,peppy
TEST=Manual. Verify module detectable via lsusb in S0. Verify power
to module is disabled in S3.
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I4984081009e4a1ce8ad8996e97f779c545829ce5
Reviewed-on: https://gerrit.chromium.org/gerrit/60941
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
These constants are scattered around the various interface
implementations and should be in one place. This will also clean up
the u-boot side when ec_commands.h is copied there.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link, spring, pit; test 'ectool hello'
Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for the TI BQ24715 smart battery charger.
It provides the system power while limiting the battery
charge limit based system power needs.
This code is based off of the bq24725 code, however there
is one change (aside from the min/max) to fit into the
current charging state machine. The charging voltage
setting is cached to provide the illusion of it being 0V
which the hardware does not allow.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=Used on a board containing this charger.
Change-Id: I59af88fba6bf740e7caff72c9ed27eaf721758c4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60804
It's still unclear why the PL6 pin which is used
for RCIN_L does not behave properly when configured
as open drain. Work around the misbehavior by
configuring the PL6 pin as an input. When it is
required to be driven low the pin is reconfigured to
an output and subsequently made an input again.
This provides the open drain semantics that are
required to eliminate leakage.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20054
BUG=chrome-os-partner:20173
BUG=chrome-os-partner:20175
BRANCH=None
TEST=manual
'apreset warm' causes reset as expected. The pin is
configured as an input by default without open drain
or a pullup resistor:
> rw 0x40062400 (GPIODIR)
read 0x40062400 = 0x00000000
> rw 0x4006250c (GPIOODR)
read 0x4006250c = 0x00000000
> rw 0x40062510 (GPIOPUR)
read 0x40062510 = 0x00000000
Change-Id: Ia3ad6fa7fec06be1cbff6854d9341722d8617408
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60780
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Also moves low-battery condition check to discharge state for Falco.
BUG=chrome-os-partner:20649
BRANCH=falco,peppy
TEST=Use ec 'battfake' comamnd to verify charger LED shows the battery
is charged when it hits 97%. On Falco, verify the charger LED flashes
while while not on AC power when the battery is under 10% charged.
Change-Id: I58e1312775a2780945643d47c9364ca0959553ed
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60704
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the EC receives a second host command with the same command code
within 50ms, it prints '+' instead of the full command debug output.
This reduces debug output during software sync by a factor of 20.
This is the default mode, also settable via 'hcdebug normal'.
The previous behavior is available via 'hcdebug every'.
What used to be 'hcdebug on' is now 'hcdebug params'.
'hcdebug off' turns off printing received host commands entirely,
though error result codes will still be printed.
BUG=chrome-os-partner:20647
BRANCH=none
TEST=manual
From a root shell, 'ectool hello && ectool hello' generates debug output
'[48.498943 HC 0x01]+'.
Then 'hcdebug every' and repeat. See both 0x01 commands.
Then 'hcdebug params' and repeat. See params for request/response.
Then 'hcdebug off' and repeat. No output.
Change-Id: If02baf39435c2a6183e0772a491225ebc5a0b7a6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60666
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Version 1 of EC_CMD_FLASH_WRITE will use as big a write as possible given
the available command parameter space. Falls back to 64 byte writes on old
platforms.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=Copy burn_my_ec onto a link and run it. Write size should be 64 bytes
for the first half of the update (since the old EC doesn't support ver.1
of the write command) and 240 bytes for the second half of the update.
Change-Id: I5900de3a5700d7c82a2e0c3cf9921b7ced1c0343
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60511
Previously it padded out the entire response buffer with null, which
caused an EC capable of returning large responses to overflow the AP's
input buffer.
BUG=chrome-os-partner:20525
BRANCH=none
TEST=from EC console, 'hcdebug on'
from U-boot console, 'crosec version'
HC resp for HC 0x04 should have only a single 00 byte at the end
Change-Id: I65826c1ccda15f18a59a6c34db61ee67e90511b8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60133
Reviewed-by: Simon Glass <sjg@chromium.org>
Previously, code which needed to work on all STM32F platforms needed
to specify them by name (CHIP_VARIANT_stm32f100 ||
CHIP_VARIANT_stm32f10x), and we needed extra symlinks in the
chip/stm32/ directory to allow the build system to find
family-specific files.
Add a CHIP_FAMILY level of abstraction, so that things which are
common across all STM32F platforms don't need to specify every STM32F
variant. Make the chip build look for family-specific filenames
instead of variant-specific filenames (except for config*.h, which is
actually variant specific).
In the few places where things actually are variant-specific, keep
using the existing CHIP_VARIANT defines.
Code refactoring only; no functional changes.
BUG=chrome-os-partner:20567
BRANCH=none
TEST=build all platforms
Change-Id: I1da831aadabf8b8dd9dfde423cac13c9f43eb953
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60247
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Preserve the state of keystroke_enabled to prevent keystrokes from being
initially disabled on RO --> RW transition. This will allow us to use
the keyboard on EC cold boot.
BUG=chrome-os-partner:20430.
TEST=Manual. Verify keyboard works on EC cold boot on Peppy.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I603a73ee0f8435c91d430a64803add345c92f025
Reviewed-on: https://gerrit.chromium.org/gerrit/59798
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=chrome-os-partner:19949
BRANCH=peppy
TEST=Manual. Observe output from "battery" and "charger" on EC console.
No smoke or fire observed (yet).
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: Ibac55bb58ebfc25de5cb625d4f503cf6e3ecec62
Reviewed-on: https://gerrit.chromium.org/gerrit/59624
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
From our measurement, it takes ~80ms for CABLE_DET to be asserted. Let's
wait for that long before giving up and declare it an USB host.
BUG=chrome-os-partner:20405
TEST=Manual
BRANCH=Spring
Original-Change-Id: I71568ed8011f9b3f2c9c2ee67aea3c771a5dbf37
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59566
(cherry picked from commit 3c1b2b757546c022d0ae0eb22e3db9feb41055c4)
Change-Id: Id2329d477f17f1db0309960ee9faeb770b2c50a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59667
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The device type reported by TSU6721 changed rapidly in some cases, and
we miss the change after the first one. We need to check device type
change periodically.
BUG=chrome-os-partner:20336
TEST=Plug and unplug DCP charger in suspend. Check device type is
detected correctly.
BRANCH=Spring
Original-Change-Id: Iaab4168f99637b736b8ba42f4313e248b84bdd44
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59535
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 69b18e5fb9890f3a638c1587968b110dc1110ba1)
Change-Id: I3cb86b0bfeb7bb02d750197405ffe385b06808e9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59666
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When the device suspends with video dongle plugged in, the EC tries to
turn off VFET output. However, the I2C command issued in interrupt
context causes an assertion error.
BUG=chrome-os-partner:20351
TEST=Plug in video dongle, and suspend. Wake the device up successfully.
BRANCH=spring
Change-Id: I135075e83ad0c40ecfdc9a1d8d7c2585a583a916
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59406
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The ec driver does not yet pass the command version properly from app
to the EC. This causes a failure when trying to read flashrom write
protect status (command 0x15).
The thing is that the command version is not even important for this
command, as it was never implemented differently.
As a quick fix - mark the command descriptor as supporting both
versions.
BRANCH=none
BUG=chromium:239197
TEST=manual
. on peach_pit (with fixed flashrom, coming under a separate fix):
# flashrom -p ec --wp-status
flashrom v0.9.4 : : on Linux 3.8.11 (armv7l), built with libpci 3.1.10, GCC 4.7.x-google 20130114 (prerelease), little endian
WP: status: 0x00
WP: status.srp0: 0
WP: write protect is disabled.
WP: write protect range: start=0x00000000, len=0x00000000
#
Change-Id: I8302457cc2afdfe3bdcb50cfa2bea29969d0c107
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59462
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This lets us force the EC to return various error codes, so that we can be
sure we're seeing them.
BUG=chromium:242706
BRANCH=none
TEST=none
Trigger various errors like so:
ectool test 0 14
ectool test 1 14
ectool test 5 14
ectool test 8 14
ectool test 0 33
Change-Id: Ia951cd7afacdcce6c8ec7d35d3bfb5b113dea694
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59327
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ec driver does not yet pass the command version properly from app
to the EC. This causes a failure when trying to use the vbnvram
context command (23). The thing is that the command version is not
even important for this command, as it was never implemented
differently.
As a quick fix - mark the command descriptor as supporting both
versions. I wonder if we should implement a "don't care" option for
situations like this.
BRANCH=none
BUG=chromium:239197
TEST=manual
. on peach_pit:
localhost ~ # mosys nvram vboot read
70000000000000000000000000000020
localhost ~ #
Change-Id: I16fcc0d6752d9e778a026717208d8d6487d5dc77
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59348
This will fix EC flash commands on pit, once the host side (u-boot and
cros_ec driver) are upgraded to match.
This change is backwards-compatible the EC still supports the existing
version 2 protocols for talking to existing AP/kernel/ectool.
Once the AP-side supports version 3 for SPI (and existing systems are
upgraded), we will remove older SPI support since we haven't shipped a
product which uses SPI.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link
And with an old ectool which predates this CL, 'ectool hello' also works.
On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and
keyboard works.
Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58908
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Add code to print out command version and command mask.
BRANCH=none
BUG=none
TEST=manual
. see this in on the EC console when hcdebug is on
[1022.289347 HC V:0 VM:3 0x17:00000000]
[1022.289728 HC resp:70000000000000000000000000000020]
Change-Id: I443401966b81349f41246d3a118f5f145ed4b160
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59347
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The Toad cable is browning out from time to time. Let's limit its
current in aggressive mode.
Also fix a bug in hard current limit calculation.
BUG=None
TEST=Plug-in Toad cable and see PWM duty cycle starts higher.
BRANCH=Spring
Change-Id: I06d64418989aa32a99545986fe841914f054acde
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59161
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
I just noticed that we've not been using the falco battery on falco. Not
sure how this slipped by.
BUG=chrome-os-partner:18788,chrome-os-partner:20213
BRANCH=none
TEST=none
Change-Id: Ia1d0f322ce8e296db49f91a3bf8eab593db97638
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59085
This will be used often, so let's move it to test_util.c.
BUG=chrome-os-partner:19235
TEST=Pass flash test.
BRANCH=None
Change-Id: I2f685f657f8742c2b29e3b9c88ba01daacf982f8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58793
If the device type is non-standard charger, it could be the user
plugging in the connector too slowly and TSU6721 BCD timer expired
before the connector is fully plugged in.
Extending TSU6721 BCD timer causes a big delay in Apple charger
detection, and breaks how we detect over-current. Let's do this by
a re-detection instead. If we see a different device type, just
update the device type we have. Otherwise, we reset TSU6721 to force a
re-detection.
BUG=chrome-os-partner:19765
TEST=Plug in a charger half way in. Wait for a second, plug it in all
the way. See device type changed after few seconds.
TEST=Plug in a charger half way in and leave it there. Only see
redetection once.
TEST=Plug in a charger all the way in. See correct device type.
TEST=Plug in an Apple charger. See correct device type within a second.
TEST=Plug in a Nexus 10 charger. See correct device type after 5
seconds.
BRANCH=spring
Change-Id: Ia7733972842e6040b545670df043058c55ae3c01
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58799
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This reverts commit 6759fdc3e6.
Extending TSU6721 BCD timer causes problems on Apple charger detection.
BUG=chrome-os-partner:19765
TEST=Check Apple charger detection and over-current handling work
properly.
BRANCH=spring
Change-Id: Ie3111477e3614410bd96d65ad2a0b430bd240835
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58798
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
By 'make coverage', lcov is used to generate test coverage report in
HTML format stored in coverage_rpt folder.
BUG=chrome-os-partner:19235
TEST=Generate a report.
BRANCH=None
Change-Id: I44142eaaeb897cf09179764781120370920144cd
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58203
It was found that PL6 behaves in an inverted way when it is
configured as open drain. Add notes about determining why this
is. Apparently PL6 is an oddity w.r.t. the other pins.
BUG=chrome-os-partner:19811
BRANCH=None
TEST=built
Change-Id: I2d5b27f49c4e51ba4eb75cda9c798b9a5793f767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58679
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
For Spring, we cannot rely on the battery current to decide if it's
fully charged. Therefore, we just use the battery charge level as the
sole indicator. The battery spec says it might stop charging when charge
level is 95%+, so we should show green LED when it reaches 94%.
Otherwise, show yellow LED.
BUG=chrome-os-partner:20017
TEST=Manual. Monitor the battery level and see LED turns green when it
goes from 93% to 94%.
BRANCH=spring
Change-Id: Ia525b2e89ebe36cc2ccce1ea0b798ba03be258a7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58059
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Now that when ID_MUX=1, DP_SNS can be connected to either ID_OUT or
CABLE_DET, we need to handle the case where a video dongle is not
reflected by DP_SNS going low. This is done by leaving ID_MUX=1 for USB
host and monitor its detachment by sensing VBUS. As for unpowered
dongle, we just ignore it when it's not recognized.
Note that due to the polarity of CABLE_DET, we now sense dongle
detachement by DP_SNS < 0.25V. To support older boards with ID_OUT
connected, we also disconnect video dongle on system suspend and
shutdown.
BUG=chrome-os-partner:19911
TEST=Powered/unpowered video dongle detected correctly.
TEST=Add a console command to simulate CABLE_DET being high. With that,
check battery charges with powered video dongle. Check nothing happens
with unpowered video dongle.
TEST=Check video dongle considered disconnected when OTG dongle plugged
in or system shutdown.
BRANCH=spring
Change-Id: If7b530b67c98c85017ca663d43c5148f0eb9163c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58070
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Partners are adamant that this needs doing. Whatever...
BUG=chrome-os-partner:19868
BRANCH=none
TEST=none
You can run the "charger" command on the EC console to see that the option
bits have been changed. I couldn't reproduce the original complaint, so I
don't know if this solves it.
Change-Id: I428697f69a7ba1b360e2acb123b42ed41244ebc5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58576
We've been providing the battery's max voltage and the charger's minimum
current to try to awaken a deep-discharged battery. For some batteries, that
doesn't appear to be enough. This change will use the battery's
preconfigured precharge_current value instead.
BUG=chrome-os-partner:20142
BRANCH=none
TEST=manual
I don't have a deep-discharged battery to try it on. I've been using these
values manually in order to get the battery away. With no battery connected,
you can run the "charger" command on the EC console to see what values it's
using. They should match what the battery wants.
Change-Id: I16d06011103ba70682397859d9844a37938d3e90
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58575
We've been asked to disable the IFAULT_HI protection for the Falco battery
charger, with no explanation. This change adds the code to do that, but
leaves it ifdef'd out. If/when we get confirmation that we really want to do
that, we can.
BUG=chrome-os-partner:19868
BRANCH=none
TEST=none
No functional change yet, nothing to test.
Change-Id: I02a71461f55849a2fdb5ec220fe00e3c812ddf0b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58467
This adds the BQ24738 smart battery charger, and a placeholder for the Falco
battery pack. I don't have either documentation or a battery to use to test,
so the battery pack stuff is just a guess (see crosbug.com/p/20142).
BUG=chrome-os-partner:20098
BRANCH=none
TEST=none
Well, if you like, from the EC console, run "charger". It should say
something like this:
> charger
Name : bq24738
Option: 1111100100010010 (0xf912)
Man id: 0x0040
Dev id: 0x000f
V_batt: 0 (1024 - 19200, 16)
I_batt: 0 ( 128 - 8128, 64)
I_in : 3968 ( 128 - 8064, 128)
>
But since I don't have either a battery or a spec, I had to guess at the
battery configuration. To test the charger, we kind of need a battery.
Change-Id: I6e63d6b5aa8be4ba15e2c427d2e86364ef6251b3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58466
I'm still not convinced that the Slippy battery voltages are right for all
cases, but these are closer to what seems to be working. It matches what the
battery we've tested with seems to want.
BUG=chrome-os-partner:18825
BRANCH=none
TEST=none
Change-Id: I2d86c5ef39a70d3826fec31207250617596baa33
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58415
The new constants used to convert PWM duty cycle to input current,
based on a linear regression done on Aaron's characterization data
measured on DVT1 PCB.
The data points are linear enough to use the linear relationship
to set the current limitation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=spring
BUG=chrome-os-partner:19281
TEST=none
Original-Change-Id: I8378aaea21d5b3229d505caf4849257ded77e1ad
Reviewed-on: https://gerrit.chromium.org/gerrit/58143
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit d7b9b2a088dcf129739c7a6b8a30bc292ea7234d)
Change-Id: I11962991d6d7ba7b9d437fc56eb23974d30930a8
Reviewed-on: https://gerrit.chromium.org/gerrit/58198
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
If the I2C transaction fails, we shouldn't cache the status because that
status is not set correctly in LP5562.
BUG=chrome-os-partner:20020
TEST=Boot and check battery LED still works.
BRANCH=spring
Change-Id: I3f40c2d5c85db41e4ba4b80dc5252e5d86100823
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58072
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sometimes initialization may fail due to bad I2C bus status. Let's allow
for maximum 3 tries of initialization 500ms apart from previous attempt.
BUG=chrome-os-partner:20020
TEST=Boot and check device type detection still works.
BRANCH=spring
Change-Id: I6ccedf77c92c4b6014ca24c7a63534316eaa7b6a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58071
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This reverts commit c848e32161.
Too noisy. It was supposed to only show it once, but it spews constantly
instead. Debug it later - just remove it for now.
BUG=chrome-os-partner:20057
BRANCH=none
TEST=none
Change-Id: Ie6dfd4ccb84a612bb72a0d2b758361a13644e4d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58111
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
