Changes somewhere in the recent past have caused I2C operations to
consume more stack space. The current failure mode is that after some
debug command or infrequent battery operation, the system fails.
Clean up and enable stack overflow detection by default, and add a
debug command (disabled by default) to verify overflow detection
works.
This adds several instructions to each context switch, but it's still
fairly inexpensive, and represents only a few percent increase in the
size of svc_handler(). That's better than silent failures.
BUG=chrome-os-partner:23938
BRANCH=none
TEST=Enable CONFIG_CMD_STACKOVERFLOW, then run the 'stackoverflow' command.
This should cause a stack overflow to be detected in the CONSOLE task.
Change-Id: I9303aee5bd9318f1d92838b399d15fb8f6a2bbf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176113
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Bolt uses Link's battery, but doesn't override the smart battery charge
profile with CONFIG_BATTERY_VENDOR_PARAMS. But the image still compiles and
includes the battery_vendor_params() function, although it's never called.
This CL stops doing that.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Build all targets.
Confirm that Link still has battery_vendor_params():
$ make BOARD=link
$ nm build/link/common/charge_state.o | grep vendor
U battery_vendor_params
$ nm build/link/driver/battery/link.o | grep vendor
00000009 T battery_vendor_params
$
Confirm that Bolt does not have battery_vendor_params():
$ make BOARD=bolt
$ nm build/bolt/common/charge_state.o | grep vendor
$ nm build/bolt/driver/battery/link.o | grep vendor
$
Change-Id: I48a535208bdcfd3d2cb26f6f15a28a728dbe4d0b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175731
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The smart battery status register holds some useful info. This displays it
along with all the other stuff.
This decodes the alarm and status bits, but not the error code, since that
field is only valid immediately after a failed i2c transaction (that's how
the battery indicates error). Since we do all sorts of automatic battery
probing in other threads, that value will never be reliable when we run the
"battery" console command.
BUG=none
BRANCH=none
TEST=manual
Run "battery". You should see a new line amongst the output:
Status: 0x00c0 DCHG INIT
Change-Id: I5e684198af2cf7767f89786c91a7d946ad95d4c2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175659
Temporary fix to the bug in which we miss wake events when in deep
sleep with the LFIOSC (32kHz) clock and the EC is cold. This fix
involves simply using a faster clock, 250kHz, when in low speed
deep sleep. This fix consumes more power but solves the bug.
Renamed EC console command dsleepmask to dsleep.
BRANCH=none
BUG=chrome-os-partner:23678
TEST=Go in to low speed deep sleep by going into either S3 or G3
and letting the EC console timeout. Then freeze-spray the EC chip.
Wake up the EC via the console and make sure that the idlestats
show that we have not missed a deadline.
Change-Id: I4f9844f1937bc8c95cf1540502f7d8fb4cbc097e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175614
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rambi has a 65W adapter, so shouldn't be asking for 4A @ 19V.
BUG=chrome-os-partner:23597
BRANCH=none
TEST=charger command shows I_in = 3392 mA (which is the closest step below
3.42A that the charger can set).
Change-Id: I4b044b594566a6abcb94c3f674a0d287c8fc2b30
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175611
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
That way all the users of jump tags don't need to know about the
padding requirements.
BUG=chrome-os-partner:23851
BRANCH=none
TEST=enable CONFIG_CMD_JUMPTAGS, then 'jumptags'. Output should be
something like this:
20007fbc: 0x5550 UP.1 2
20007fc4: 0x4b42 KB.2 3
20007fcc: 0x4c50 LP.1 12
20007fdc: 0x4d54 MT.1 8
All the addresses in the first column should be word-aligned. The
sizes in the last column don't need to be a multiple of 4.
Change-Id: I91f9c29701a007ef8a56b5b7e0ea09930dfbea31
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175591
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Fan no longer needs a special priority to wait for the host memmap to
become available, since LPC inits earlier.
I2C and PECI don't need explicit ordering on freq change.
Thermal now uses the explicit prio for temp sensors done.
Commented hook test.
BUG=chromium:314768
BRANCH=none
TEST=boot link; enable/disable PLL; verify fanset and temps commands work afterwards.
Change-Id: I71766614dff2950dd307acd0635405e6b59e330a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175601
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Refine the GPIO list according to the schematic. Comment out the XPSHOLD in
power/tegra.c for compiling. Will fix later.
BUG=None
BRANCH=None
TEST=emerge-nyan chromeos-ec &&
make runtests -j 32 && make BOARD=nyan tests -j 32
Change-Id: Id0d682fd5d48e8a8a07785e86c07f45f07d866ab
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175534
Modify board.h and board.c to describe both fans.
BUG=chrome-os-partner:23530
BRANCH=samus
TEST=manual
Power things up, poke at the fans through the EC console. Observe that
they're both working and controllable:
faninfo
fanset 0 2000
faninfo
fanduty 1 30
faninfo
fanauto 0
faninfo
fanauto 1
faninfo
Change-Id: I2ba9356f084be12dab0fe0b9a004f66feace1878
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175369
Cortex-M3 and Cortex-M4 are not using exactly the same instruction set.
Cortex-M3 is using ARMv7-M ISA which is a subset of the ARMv7E-M used by
the Cortex-M4 core (even though the delta is small).
Let's restrict each core to the right subset of instruction by pushing
the -mcpu/-march configuration in the chip specific area.
Note: GCC 4.8 is now using the full ARMv7E-M instruction set and will emit
"undefined instruction" on Cortex-M3 without this patch.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:314194
TEST=build *and* run on Spring and Link.
Change-Id: I2f9b87fec689e8d1097809cab437a2bd32dfa194
Reviewed-on: https://chromium-review.googlesource.com/175487
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This adds explicit "int fan" args to the exported functions from
common/fan.c: fan_set_percent_needed() and fan_percent_to_rpm(). Within that
file, multiple fans are handled independently.
This is not complete, though. Host commands and sysjump support still only
handle a single fan, so at the moment multiple fans are treated identically
in those cases.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
All boards build, "make runtests" passes.
On a multi-fan system, the EC command "faninfo" displays multiple results:
> faninfo
Fan 0 Actual: 0 rpm
Fan 0 Target: 0 rpm
Fan 0 Duty: 0%
Fan 0 Status: 0 (not spinning)
Fan 0 Mode: rpm
Fan 0 Auto: yes
Fan 0 Enable: yes
Fan 1 Actual: 0 rpm
Fan 1 Target: 0 rpm
Fan 1 Duty: 0%
Fan 1 Status: 0 (not spinning)
Fan 1 Mode: rpm
Fan 1 Auto: no
Fan 1 Enable: no
>
and the "fanduty", "fanset", and "fanauto" all require the fan number as the
first arg:
> fanduty 0 30
Setting fan 0 duty cycle to 30%
> fanset 1 2000
Setting fan 1 rpm target to 2000
> fanauto 0
> fanauto 1
On single-fan systems, there is no visible change.
Change-Id: Idb8b818122e157960d56779b2a86e5ba433bee1b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175368
Reviewed-by: Randall Spangler <rspangler@chromium.org>
All the current data buffers *are* aligned, but we should check anyway
just to avoid unpleasant surprises in the future. This matches what
we do on STM32L. On STM32F, we copy a byte at a time so alignment of
the source data doesn't matter.
BUG=chrome-os-partner:9526
BRANCH=none
TEST=manual
flasherase 0x20000 0x1000
flashwrite 0x20000 0x200 -> succeeds
flashwrite 0x20201 0x200 -> fails
Change-Id: Id1a0fd8f6871e1fcdc3f55ec25eea40f33b5214c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175532
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Fixed bug in which two different tasks reading two different ADC
channels could interfere and cause the ADC clock to get disabled
when a read is still in progress, thus causing a reboot.
Added a runtime assert to verify that developers don't sample the
same ADC channel from multiple different tasks, which could cause
hard to trace reboots.
BRANCH=none
BUG=chromium:313872
TEST=1) Added console command to continuously read an ADC channel not
read anywhere else. Verified that when running this console command
I could reproduce the bug every few minutes.
2) Wrote code in adc.c to protect the ADC clock resource.
3) Ran console command from step 1 for ~2 hours with no reboots.
Change-Id: Ic1905dde12871a4b93957702f7f31a25a2762bb4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175404
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Update comments with more info, or remove if no longer applicable.
No code changes.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: I5b56eeb500bc0f00e84e91ef99684f4b1b310972
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175418
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add bug links, reword, or remove as applicable.
No code changes, just comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: Id55dd530c10091d7ab9d0f942f750168fca793b4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175326
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add bug references. Remove one assert that can no longer be triggered.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I3f4d2e4f2f3343a8d0531cb0715d151eaa4d0b50
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175293
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
- disable PP1800_PGOOD internal pullup
- add PP3300_DSW_EN control on PF6, turned on in S5 and off in G3
- change PCH_WAKE_L and PCH_PWRBTN_L to open drain signals
- add PCH_BL_EN interrupt on PM3 for rising edge to put backlight
controller into PWM mode, remove 1 second hook
- add samus-specific extpower handler for AC_PRESENT to buffer the
AC_PRESENT input to the new PCH_ACOK output on PM6. this is driven
high in S5/S3/S0 when AC_PRESENT is high, otherwise driven low.
BUG=chrome-os-partner:23752
BRANCH=samus
TEST=emerge-samus chromeos-ec
Change-Id: Ie8ab538610e41914212ee1f3a6287b63474fb85b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175281
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Right now, firmware changes are rejected if the HWTest or VMTest
stages fail. This is unnecessary as firmware changes are very unlikely
to break these stages.
BUG=chromium:285940
BRANCH=none
TEST=none, this is just copied from the coreboot repository
Change-Id: Id7ccff542b8abada41072ef26cd2b7d3ae179fd3
Signed-off-by: David James <davidjames@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175410
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The current chroot toolchain properly compiles the SVC instruction, so
there's no need to hard-code the opcode. That was a workaround for
binutils < 2.22 (that is, binutils versions more than 2 years old).
BUG=chrome-os-partner:23721
BRANCH=none
TEST=compare EC binaries before/after this change; only the
datestamp should be different
Change-Id: I9c6282768c4562926397866ac3be218c393e3865
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175172
No code changes, just comment fixes. Added config #ifdefs for the
debug commands as requested; they're enabled for Spring, so
functionality is unchanged.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build spring; see that ilim and batdebug commands still exist
Change-Id: I7c9f12281afa7ec68aa7e62dcfcd51682d88a16a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175216
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds a 'xrefs' target to create various cross-reference files from the
EC sources. In particular, it generates these files in the target build
directory:
cscope.files - for the cscope browsing tool
TAGS - for emacs
tags - for vi
It parses the dependency files generated by a build, so that only those
source files actually used to create the EC binary are scanned.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Inside the chroot:
make BOARD=link xrefs
ls -l build/link/cscope.files
If you install the ctags and etags programs in the chroot, you should also
see build/$BOARD/tags or build/$BOARD/TAGS, respectively. If those programs
don't exist, those steps will be silently skipped.
Note: You can install ctags with "sudo emerge ctags". AFAICT, installing
etags requires the entire emacs suite, so it's probably simpler to just copy
the etags binary from your build host into the chroot's /opt/bin/
If you don't have ctags or etags in the chroot, you can still run
make BOARD=link CROSS_COMPILE= xrefs
outside the chroot, provided you've built the EC image first.
Change-Id: I8e16ef19b0f4e79aba887c308e58982fef8fa21f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175224
Remove comments if no longer applicable, or assign bug numbers if they
still are. Tidy some debug output. No code changes other than the
debug output.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms, pass unit tests
Change-Id: I2277e73fbf8cc93f3b1b35ee115e0f2f52eb8cf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175215
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Rather than compile it by default for host-based tests, only compile
it for the few tests that actually use it. Since those (and all
boards) now only use if if they also have a keyscan task, we can get
rid of the #ifdefs in keyboard_mkbp.c as well.
And remove a TODO we'll never do...
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests. These pass:
util/make_all.sh
make BOARD=pit tests
Change-Id: I44d1806cfb375027a7ed0b33a5e9bdbbed8ccddc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174513
There is a logical difference between PWM controls for things like
backlights and fan controls for actual fans. This change separates them into
two different data structures, for better abstraction.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, make all boards, test on Link and Falco.
Change-Id: Ib63f2d1518fcc2ee367f81bf5d803360c1aa5c76
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175151
Instead of just configuring fan support as yes/no, we'll use it to specify
the number of fans on the board. Undefined (not zero!) means no fan support
at all.
Syntax change only. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: Iff65efa69e05f3e1a54fdc2a8da9001b4e8487ca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175150
This looks like a lot, but it's really just moving the non-board-specific
stuff from chip/lm4/fan.c into common/fan.c, updating the appropriate
headers, and renaming functions to better match the new location.
This is entirely code refactoring and renaming. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: I7dc03d6732bad83cf838a86600b42a7cff5aa7aa
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175012
All hibernate register writes must wait for the WC bit. When we're
enabling the RTC alarm, it's important to wait for the WC bit
afterwards, too, or else we could go into deep sleep before the write
to HIBIM is committed.
Also make sure that the normal hibernate() path enables the RTC alarm
if it has a timeout. This bug wasn't noticed until the low-power idle
code called system_reset_rtc_alarm(), since before then HIBIM was
initialized to 1 and just stayed there.
BUG=chrome-os-partner:23678
BRANCH=anywhere we use low power idle (wolf/leon, too)
TEST=with hacked firmware, note that HIBIM=1 just before the wfi
instruction in chip/lm4/clock.c
Change-Id: Ie01b106ac6a6c5894811f9a333715b22ef896f82
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175013
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This chip returns ver/family/partno = 0x10de, as indicated by the
datasheet. Also switch the identification code to use a switch
statement rather than re-reading the DID1 register in if-then-else.
BUG=chrome-os-partner:23679
BRANCH=none (maybe haswell branches, but it's largely cosmetic)
TEST=version command on rambi identifies the chip as ti tm4e1g31h6zrb B1
Change-Id: I4a3748413de65d3116feb7c444f5a2af5953eecd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175008
Reviewed-by: Vic Yang <victoryang@chromium.org>
If the input current limit is too high the EC sees the AC_PRESENT signal
toggle rapidly, probably due to the adapter browning out. By
trial-and-error, we found a value that seems to stop that happening.
BUG=chrome-os-partner:23449
BRANCH=samus
TEST=emerge-samus chromeos-ec
Let the battery run down a bit, plug the adapter in, watch the EC console to
see what happens. Make sure it doesn't go nuts.
Change-Id: I812685efd312fce82eb117bb722425ae6276fdd1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175037
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Due to power topology, PP5000 needs to be enabled as soon after
PP3300_DSW as possible. Since PP3300_DSW is what powers the EC, the
EC needs to turn on PP5000 by default and leave it on.
BUG=chrome-os-partner:23673
BRANCH=none
TEST=reboot ap-off (this boots the EC without doing AP power sequencing)
gpioget -> shows PP5000_EN=1, PP5000_GOOD=1
Change-Id: I5d493877d330b2543a493f8a2f3411003d5964ca
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174989
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On the LM4, all pwm functions are implemented through hardware "fan"
modules. This change abstracts the hardware fan stuff from the higher level
pwm and fan control logic. Those are still chip-specific at the moment, but
may be moved into common with a future CL.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
Code refactoring only, no new behavior. All tests build and pass, and I
tested on Link with some manual pwm and fan commands on the EC console.
> fanduty 30
> faninfo
Should report ~4500 RPM
> fanset 7000
> faninfo
Should report ~48% duty cycle.
> fanauto
Back to automatic control.
> kblight 0
> kblight 10
> kblight 50
> kblight 100
Keyboard backlight should glow appropriately.
Change-Id: I7558f36b2626e555fc8dabdd12660fa484a93b7f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174991
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This fixes a bug in which after a sysjump, the sleep_mask is
reset, and the EC is allowed to go into a low power mode even
though the AP is still running. This causes numerous problems,
must notable of which is that a flashrom write fails with an
EC protocol mismatch error.
BUG=chrome-os-partner:23645
BRANCH=none
TEST=Execute a flashrom write and make sure the system does not
use the low power code immediately after.
Change-Id: I4d50282da0c5ba5b6488ed14a267a4d8cafe09a7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174943
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
These were being driven push-pull, causing leakage.
BUG=chrome-os-partner:23639
BRANCH=none
TEST=rambi still boots main processor out of reset
Change-Id: I39a18e48307b66fc767ce2c8256d828d4e6962e0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174897
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
QEMU tests served us well, but it has been more and more difficult to
maintain as we now have more chips and use more functionality from each
EC chip. With emulator tests in place to test common code and hardware
test to test per-chip/per-board drivers, it's time to remove QEMU tests
to simplify our code base.
QEMU tests that are covered by other emulator tests are removed
completely; tests that are not covered are left alone for now to
preserve the test logic.
BUG=chrome-os-partner:18343
TEST=util/make_all.sh
BRANCH=None
Change-Id: I5a4dd2f5ac42f7f66f86fdce0b62dbd2c65bf66a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174669
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
To conform to our mutating naming conventions, let's rename the
chip-specific PWM header file to have the string "_chip" in it.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: I6584be8e54fd24c8638559817e150c707bc0edb5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174884
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Needed for shipping systems. Puts battery into shutdown mode until AC
reapplied.
BUG=chrome-os-partner:23634
BRANCH=none
TEST=With system on battery power, 'battcutoff'. System will shut off
after a few seconds. Power button will not turn it on. Plugging
AC power in will turn system back on.
Change-Id: I10a28c3c21623508dc8e4dee1cc5dc8d6fb9a6af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174888
Reviewed-by: Dave Parker <dparker@chromium.org>
Update the comments in several board.c files to accurately describe which
pwm control circuit is being used for what purpose.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=none
No code changes, comments only.
Change-Id: I29cef5a2bfee4d7d44bedd092783d9f1d2ea5ef3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174901
Picked some reasonable values. Subject to later tweaking.
BUG=chrome-os-partner:23634
BRANCH=none
TEST=On AC power, charging = yellow
On AC power, done charging = green
No battery = blinking red
On battery, AP on = dim green
On battery, AP off = off
Change-Id: I2eb901ea4de98fec8cd83e403d6ed8a06a2a9ca9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174778
Reviewed-by: Dave Parker <dparker@chromium.org>
Using best-guess numbers for input current limit. Battery voltage and
temperature limits are set from actual battery spec.
BUG=chrome-os-partner:23597
BRANCH=none
TEST=battery and charger commands print reasonable info
battery charges when system plugged in
Change-Id: I812276cbe46c8463a855c7ba3e0bfec4852e6f97
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174766
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reset the DMA status after the end of the conversions,
else we will exit too early at the next call of the function and the
values before they are actually transfered.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run "adc" command several times and always see proper value for
each ADC.
Change-Id: I7ad335fffa2da34a4b715e9f0c9927bf06baef8f
Reviewed-on: https://chromium-review.googlesource.com/174397
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
