At normal AP shutdown, Haswell systems skip S5 entirely and go directly to
G3. It's sometimes handy to pause in S5 as the other systems do, for things
like power-cycle tests that use the RTC to do a delayed wake from S5.
This CL adds a console command and a host command to enable/disable that
pause in S5.
The default is to skip S5, and the override value is not persistent across
EC reboots, so whenever the EC hibernates or reboots (Refresh + Power, software
sync), you'll have to re-enable it again.
BUG=chrome-os-partner:22346
BRANCH=falco,ToT
TEST=manual
On Haswell systems only.
To enable the pause in S5 at shutdown, do either of these:
EC console: gsv s5 1
root shell: ectool pause_in_s5 on
Shut the AP down politely, and it should pause in S5 for 10 seconds before
continuing to G3. You can see this by watching the EC console.
To disable the pause in S5 at shutdown, do any of these:
EC console: gsv s5 0
root shell: ectool pause_in_s5 off
or
press Refresh + POWER
Boot the system, then politely shut down. This time it should go directly to
G3 without pausing in S5.
Change-Id: I324e6e2373bc20b61a731b4ef443d7bb8edb6b83
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that we have battery and charger drivers, let's enable charging.
BUG=chrome-os-partner:22055
TEST=Test charging/discharging on Kirby
TEST=Unplug battery and see 'error' state
TEST=Plug battery and doesn't see error anymore
BRANCH=None
Change-Id: Idff513b38c9f5bb90700877750f3d2e2154d4b23
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168007
The charger stops charging when charging current is smaller than this
value. To maximize battery life, let's set this value to its minimum so
that the battery is charged to as full as possible.
BUG=chrome-os-partner:22238
TEST=Test charging on Kirby with the next CL
BRANCH=None
Change-Id: I528dd0668244cba480538b825fff1cf28d7748ec
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168006
This checks boot key combination like Power-F3-ESC and Power-F3-Down can
be properly detected.
BUG=chrome-os-partner:19236
TEST=Pass kb_scan test
BRANCH=None
Change-Id: I180918977299219a8421798dac2ab9fed84ef9a2
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167802
We already have a multi-step test. Let's move it to test_util.c so that
upcoming tests can also use it.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: I6b7a036297f3b4b2778687488d1dc5b5bb4fe255
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167950
Currently only x86 platform uses charge_state.c, and it's been tailored
to fit smart battery and bq247xx charger family.
For Kirby, we have different types of battery and charger, and thus need
to make some change to accommodate them. This includes:
- Abstract out smart battery specific bit mask
- Implement missing functions required by GAIA chipset module
- Add config flags for charging-enabled GPIO pin
- Allow battery that doesn't report desired voltage and current
BUG=chrome-os-partner:22055
TEST=Build all boards
TEST=Boot Link and check it charges/discharges battery
TEST=Test charging/discharging on Kirby along with the next two CLs
BRANCH=None
Change-Id: I910c030a45b4f775afffec0127cdc31e89b9dd55
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168005
This is only for initial bringup that requires OTG to boot kernel. Note
that we are expecting firmware for USB ID detection and hardware change
to charger chip, so this is likely going to be thrown away.
BUG=chrome-os-partner:21964
TEST=Plug in OTG dongle and check VBUS voltage is ~5V
TEST=Unplug and check it's ~0V.
BRANCH=None
Change-Id: Iee66bef117188fea14a76459945be3bf5afef0dd
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167832
When the AP is powered on, turn on backlight. Also turn off backlight
when going into S3/S5.
BUG=chrome-os-partner:21964
TEST=Power on and see backlight lit. Power off and see it turned off.
BRANCH=None
Change-Id: I77141848466db3209aa0eba2613057002bd3432a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167800
BQ27541 is not a smart battery IC, and thus we cannot use existing smart
battery driver. Let's add a driver that implements a smart-battery-like
interface.
The 'battery' console command is also moved to battery.c so that it can
be reused by different battery driver.
BUG=chrome-os-partner:22048
TEST=Type 'battery' and check the reported values are sane.
TEST=Check 'battery' command works fine on Spring.
BRANCH=None
Change-Id: I5d1eaeb3f801478f3b9473fd43c1f2a2eda75859
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66340
This adds EC_CMD_GET_SET_VALUE to the list of host commands. We have a bunch
of single-value getter/setter commands, which is wasteful. This is a start
towards unifying them into a simpler command.
BUG=chromium:285358
BRANCH=ToT,falco
TEST=none
There's nothing to test just yet. This just adds the command and some basic
interfaces. A future commit will make use of it.
Change-Id: Iee986b9d273b422bb06f3a0c9b7af50617f03d7f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168083
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This signal is active low (1=no AC, 0=AC good.) Renaming it to
AC_PRESENT_L so that it's not confusing.
BUG=chrome-os-partner:21964
TEST=Build kirby
BRANCH=None
Change-Id: I17b555945c647f4a24b1920cdb8992b3a5767462
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167458
Kirby has the same ADC channels as Spring, but with different scales and
pin assignments.
BUG=chrome-os-partner:22055
TEST=Read ADC channel voltage
BRANCH=None
Change-Id: Ibb618a77647c0477eeb0e8d983df07a258fdb75a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167460
ADC module on STM32L is clocked by HSI oscillator, and thus we need to
switch to HSI if using MSI. After the conversion, if the system is not
in S0, clock is switched back to MSI again.
There are several register bits that can only be written when ADC is
powered down. For now, let's just power down the ADC after each
conversion.
Currently ADC watchdog is not working and is disabled on STM32L.
BUG=chrome-os-partner:22242
TEST=Try multiple all-channel and single-channel reads in S0 and S5.
BRANCH=None
Change-Id: I769dda8a9c69ac9de1eb22d6d259034eef8c1ac4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167454
A delay between enabling PMIC_PWRON and 3.3V rail is needed so as to
prevent leakage.
BUG=chrome-os-partner:22101
TEST=Power cycle the AP.
BRANCH=None
Change-Id: I2dd1c7ebc71565fc64dacaeb5caa46b2d3801d50
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167582
When running an unit test, the emulator is sitting in idle task for most
of the time. Since we don't have interrupt support now, the emulator is
just waiting for the next wake-up timer to fire. To save time, we can
actually just figure out which task is the next to wake up, and then
fast-forward the system clock to that time.
With this, all tests run faster and we can remove time-scaling for all
current tests. This improves not only run time but also stability.
If one day we have interrupt support, then we will have to modify this
to take into account the fact that an interrupt might wake a task before
any wake-up timer fires.
BUG=chrome-os-partner:19235
TEST=Run all tests in parallel for 1000 times.
BRANCH=None
Change-Id: I4cd33b041230267c110af015d425dd78d124f963
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167801
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Temperature sensor read is delegated to functions defined in board.c.
Let's mock that function instead of the one in temp_sensor module.
BUG=chrome-os-partner:19236
TEST=Pass thermal test.
BRANCH=None
Change-Id: Ic0387bd6a49e3f032e593c11c6f80bd36f8474e7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167761
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If we reboots the emulator without flushing test coverage information,
the test coverage report will be incorrect. Let's fix this by flushing
it before every reboot.
BUG=chrome-os-partner:19235
TEST=Generate test coverage report and check correctness.
BRANCH=None
Change-Id: I1eb060e419b767f382325bed841366c491ba56b7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167770
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This includes:
- Charge mode control host command
- Low battery shutdown/hibernate
Also, speed up the test by 20x since we now need to wait for more than
30 seconds for low battery state test.
BUG=chrome-os-partner:19236
TEST=Pass the test
BRANCH=None
Change-Id: If2e91a33f3a80f58da01a6c3da128cb603101dea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167613
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
GPIO_INPUT is defined as 0, and any GPIO flag cannot be examined against
GPIO_INPUT. Change GPIO_INPUT to non-zero value to avoid this.
BUG=chrome-os-partner:22275
TEST=On Kirby, set a GPIO to output and pull it low, and then set it back to
input. Check it can be pull high externally.
TEST=Build all boards.
TEST=Boot link and spring.
BRANCH=None (unless this bug hits some other boards.)
Change-Id: I84b9936c24af538ac59c36129fda27ca879bf9d1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167190
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On Kirby, the EC has no direct control over several power rails. To shut
down the AP, we need to pull low XPSHOLD from the EC so that PMIC would
turn off AP power.
BUG=chrome-os-partner:22101
TEST=Repeatedly do 'power on' and 'power off'.
TEST=Reboot the EC and see AP booted.
BRANCH=None
Change-Id: I21d04e46a6cfb455ced073389a928f2549d5212d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167201
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Most systems don't have a lightbar. Those that do need a way to detect that
one exists. That's easily done by just sending a EC_CMD_LIGHTBAR_CMD command
to the EC and checking the result. If the response is
EC_RES_INVALID_COMMAND, there isn't a lightbar.
But what .cmd value should we use in struct ec_params_lightbar? Future
lightbar implementations (if any), could remove existing functions or add
new ones, so there isn't a safe choice.
This change adds a LIGHTBAR_CMD_VERSION operation to determine if any new
implementation exists. Future systems should return some useful information
in response to this command. Existing systems will return
EC_RES_INVALID_PARAM, which is enough to distinguish them.
BUG=chromium:239205
BRANCH=none
TEST=manual
make BOARD=link
make BOARD=link runtests
There are no user-visible changes in functionality to anything.
Change-Id: Ibe37f74a4dcbf68dd6bfd1963530aec907e67534
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167549
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is just a simple driver that provides a function to set LED color
and also a console command for testing.
BUG=chrome-os-partner:22056
TEST=Change LED color and brightness with the console command.
BRANCH=None
Change-Id: I66ece63310a0547127698d1b242a5a1c130abff6
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167450
Instead of checking for BOARD_<board> to determine whether the board has
control over a power rail or not, use config option for this. Boards
without control over some power rails can then undefine the option in
board.h.
BUG=chrome-os-partner:21964
TEST=Build all boards.
BRANCH=None
Change-Id: I7ee4ebdb3ea595e182845e40db165623ee271997
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167200
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is the initial version of BQ24192 charger driver. For now, it only
probes for BQ24192 chip on initialization and get BQ24192 into host
mode.
Also, charger_closest_current() is identical across all charger drivers.
Let's move it to charger_common.c.
BUG=chrome-os-partner:22238
TEST=Build all boards. Boot Kirby and see BQ24192 initialized.
BRANCH=None
Change-Id: I5291362ff0e69b281bffd6d609ce6dc48eb10898
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167457
and when the bus seems wedged at i2c_init().
BUG=chrome-os-partner:19286
TEST=Manual test on peach pit. Tried the following wedged cases:
(1) Bit bang a transaction but only read part of the response.
(Refer to https://chromium-review.googlesource.com/#/c/66389)
Command to wedge: i2cwedge 0x90 0 2 2
(2) Bit bang a transaction to do a "write" and stop while the other side is
acking. (Refer to https://chromium-review.googlesource.com/#/c/66389)
Command to wedge: i2cwedge 0x90 0 1
(3) Same as (1) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
(Refer to https://chromium-review.googlesource.com/#/c/66389)
Command to wedge: i2cwedge 0x90 0 6 2
(4) Same as (2) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
(Refer to https://chromium-review.googlesource.com/#/c/66389)
Command to wedge: i2cwedge 0x90 0 5
(5) Manually pull down on SCL.
(Refer to https://chromium-review.googlesource.com/#/c/66063)
All five cases successfully wedged the bus and were recovered by this change.
BRANCH=pit
[dianders: made sure we don't change SCL after SCL high, misc other bits]
Change-Id: I23f16fcaa2a76ea37025f8204ab1cdb27e9ef6d1
Signed-off-by: Hung-ying Tyan <tyanh@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66915
Previously we could get into some pretty bad situtation around
frequency changes. Specifically:
* If the freq change code exectued during a transaction then it would
get all messed up.
* If the freq change notifier executed during a transaction then we'd
reset the bus midway through transaction. Badness.
BRANCH=pit
BUG=chrome-os-partner:22093
TEST=With all patches together:
- on AP: suspend_stress_test
- on EC: battery 10000 50
Change-Id: I24be29d459fe229a6278829a7c03c1e102358e8c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/167102
(cherry picked from commit deab2433c13bc3b3bb75cd33c12dad633ba6a42a)
Reviewed-on: https://chromium-review.googlesource.com/167149
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the AP is suspended, it consumes little enough power that just
shutting its rails off doesn't cause it to reset to a known state.
This caused a problem where suspending the AP then rebooting the EC
would wedge the system; the EC would think the AP was on (since
XPSHOLD was asserted), but wouldn't be able to figure out how to turn
it back off. Silego reset wouldn't help, because that again just
reset the EC. Even setting PMIC_RESET to brown out the system
wouldn't drop power for long enough.
Simply pulsing AP_RESET_L low for 1 ms at EC boot (when not sysjump)
or AP force-shutdown forces the AP into a good state.
BUG=chrome-os-partner:22233
BRANCH=pit
TEST=from root shell, 'powerd_dbus_suspend'
from ec console 'reboot' - or just power+refresh
system should power on normally
Change-Id: I65f1239b5f6766f1c093c3064bce323df4acaf7d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167355
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Before this change drivers had no way of knowing that a frequency
change was coming. This could cause problems for some drivers (like
i2c) that need to make sure that a transaction isn't happening while a
frequency change is happening.
The PRE_FREQ_CHANGE archiecture is very simple here and we don't allow
any way to cancel it.
At the moment, we guarantee:
- We won't call PRE_FREQ_CHANGE with interrupts disabled, so acquiring
locks / sleeping is OK.
- We'll call the actual HOOK_FREQ_CHANGE after the PRE_FREQ_CHANGE.
PRE_FREQ_CHANGE and HOOK_FREQ_CHANGE should not use deferred function
calls.
BRANCH=pit
BUG=chrome-os-partner:22093
TEST=With all patches together:
- on AP: suspend_stress_test
- on EC: battery 10000 50
Change-Id: I2731a3e85d41e749fa571fdb74b5c9b12043cda6
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/167101
(cherry picked from commit d84c0dbbf7c5a72917a820e292ecfdfa698d0fb9)
Reviewed-on: https://chromium-review.googlesource.com/167148
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Putting the suspend/resume hook callbacks on a deferred task allows
frequency change notifications to lock mutexes. This is useful in a
future change which locks the i2c bus around frequency changes.
BRANCH=pit
BUG=chrome-os-partner:22093
TEST=With all patches together:
- on AP: suspend_stress_test
- on EC: battery 10000 50
Change-Id: If5e31040cdc7c95a4c8ba62ee72512cb79617cc9
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/167100
(cherry picked from commit ce31fda8695f4db1fa91f5bb224c781cf17f91c0)
Reviewed-on: https://chromium-review.googlesource.com/167147
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This fixes some jank in how the power LED works when going into
suspend. Previously the power LED could turn off for up to three
seconds before flashing amber when entering suspend.
BUG=chrome-os-partner:21622
BRANCH=peppy
TEST=Manual. Enter suspend and observe that LED goes from blue
to amber without turning off first.
Change-Id: Ib0bf9e998d250b0731405394d3ebb50d90de7cda
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167388
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If you're running the battery command in a loop:
* You may need a sleep so you don't trigger watchdog resets, at least
if you're running at a low clock frequency.
* You probably want to break on an error.
Make the sleep delay come from a parameter since you might want to
avoid it if you just want to pound on the bus as fast as possible.
BRANCH=pit
BUG=chrome-os-partner:22093
TEST=With all patches together:
- on AP: suspend_stress_test
- on EC: battery 10000 50
Change-Id: I6ae6d818c06f59064e90bd6d23d6d4c782544849
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/167103
(cherry picked from commit 703ce2abf2e38b0f1434224534c1be505e1244f7)
Reviewed-on: https://chromium-review.googlesource.com/167160
Reviewed-by: Hung-ying Tyan <tyanh@google.com>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ID detection and charging circuits on Spring are very different from
that on Kirby. PWM current limit is no longer used. The ID detection
sequence is also different. Also, there is no boost circuit on Kirby.
Given those hardware issues that we had to work around on Spring, it's
unlikely that we will have another board that shares the same/similar
ID detection design with Spring. Let's rename extpower_usb to
extpower_spring to better reflect this.
BUG=None
TEST=Build and boot Spring.
BRANCH=None
Change-Id: I7c212a121eed55665593cb7e1b2b672891819940
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/67031
Until we can properly detect power source type, always assume adaptor
power source to allow more input current.
BUG=chrome-os-partner:22055
TEST=Plug in adaptor and see 0x84 from BQ24192's register 0x8.
BRANCH=None
Change-Id: Ic6adc0d459f9cc038870e3dd2b680549c4b5df39
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66934
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, the STM32L I2C driver queues the stop condition, but
doesn't actually wait for it to take effect before returning. If
another back-to-back transfer is started, this may attempt to send a
start condition before the stop condition completes. If this happens
after a slave read, this can look to the slave like just another pulse
on SCL, causing it to clock out another bit - potentially driving SDA
low and hanging the bus.
Instead, wait for the bus to go idle, then wait another clock period
(10 us) to give the slaves plenty of time to detect bus-idle before
the next start condition.
BUG=chrome-os-partner:22093
BRANCH=pit
TEST=repeatedly run the battery i2c command from the EC console while
running 'ectool i2cxfer 0 0x48 1' from a root shell. Should not hang
the I2C bus.
Change-Id: I5e65ee242537dbc801fba4ae57847a5af5104186
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66997
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Dumping before the ADDR bit is cleared also has the effect of clearing the ADDR
bit.
BUG=chrome-os-partner:22235
TEST=Manual test on peach pit.
Keep executing the "battery" command on the EC console while busy running
flashrom on the host to read back the EC. See that there's no error produced.
BRANCH=pit
Signed-off-by: Hung-ying Tyan <tyanh@chromium.org>
Change-Id: I10e88a8512f4e9eb90267ef1aca1df5dd214318d
Reviewed-on: https://chromium-review.googlesource.com/66930
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Hung-ying Tyan <tyanh@chromium.org>
Tested-by: Hung-ying Tyan <tyanh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This unifies the PWM module interface for LM4 and STM32. Now PWM
channels are defined in board.h/board.c. Instead of calling functions
named pwm_set_fan_duty(x), one can now use pwm_set_duty(PWM_CH_FAN, x),
which prevents additional functions added when we have a new PWM
channel.
BUG=chrome-os-partner:18343
TEST=Limit input current on Spring.
TEST=Check power LED in S0/S3/S5 on Snow.
TEST=Check keyboard backlight functionality on Link.
TEST=Check fan speed control/detecting on Link.
BRANCH=None
Change-Id: Ibac4d79f72e65c94776d503558a7592f7db859dc
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/64450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Test config is now in test/test_config.h. Let's remove the unused config
lines in board/host/board.h.
BUG=chrome-os-partner:19235
TEST=Pass all tests.
BRANCH=None
Change-Id: Ic8f7f4dcf8e0ad5f8800fe8ad2ae89b604a239f4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66742
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With CONFIG_HOST_COMMAND_STATUS, the EC can respond to a command
with EC_RES_IN_PROGRESS, indicating to the AP that it should poll
for completion of the command with EC_CMD_GET_COMMS_STATUS. The
kernel, however, only guarantees the atomicity of single commands.
As a result, i2c passtrough or keyboard commands could be issued
while the AP is polling for completion of a flashrom command. By
disabling CONFIG_HOST_COMMAND_STATUS, we eliminate polling of the
EC status by the AP so that there is no interleaving of commands.
BUG=chrome-os-partner:20978
TEST=flashrom on Pit
BRANCH=pit
Original-Change-Id: I48b29a0dbbcc56fc55f72ca64b8aff51036740e3
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66703
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2db4fcfb267b938fcc35af2a0d2e374f99551743)
Change-Id: Iac7c15ec337d618cd6d95439d4b922bf3ec43916
Reviewed-on: https://gerrit.chromium.org/gerrit/66828
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
If the EC responds to the AP with IN_PROGRESS, the AP will then use
GET_COMMS_STATUS to poll for completion of the previous command.
If the EC doesn't support GET_COMMS_STATUS, it will return an error,
confusing the AP.
BUG=chrome-os-partner:20978
TEST=flashrom on Pit
BRANCH=pit
Original-Change-Id: I7c911ebc047042450b1eefc992ba2250d35fa078
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66702
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 67efd2c100f9de6fe34d381f6145e2d795d8549f)
Change-Id: If102710d30cbc53670bb5652b473734c7d9251be
Reviewed-on: https://gerrit.chromium.org/gerrit/66827
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
