1. Modify voltage_max
2. Set CP point
BUG=chrome-os-partner:27859
BRANCH=Big
TEST=Plug in AC and battery, use UART command "charger" to check
v_batt and I_in and the values are correct.
Change-Id: If83a444338e8d520e6c2f4d04ca6016c14cea8bd
Reviewed-on: https://chromium-review.googlesource.com/193584
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
This improves some of the smart battery mocks, and adds some more tests for
the new change state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make coverage
Line coverage of this file jumps from 53% to 93%.
Change-Id: I4a9b8818cefaffd3022cebe08a36d592b0611295
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193690
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Samus' power sequence is not in common/power, so it was overlooked when
enabling deep sleep support. Fix it.
BUG=chrome-os-partner:27705
BRANCH=ToT
TEST=manual
Verify that the EC is not going into deep sleep while the AP is on by
looking at the EC console:
With the AP on:
> idlestat
Num idle calls that sleep: 1518647
Num idle calls that deep-sleep: 414
Time spent in deep-sleep: 0.000000s
Total time on: 316.642174s
Deep-sleep closest to wake deadline: 698us
> sleepmask
sleep mask: 00020001
>
With the AP off (or in S3):
> idlestat
Num idle calls that sleep: 1846586
Num idle calls that deep-sleep: 831
Time spent in deep-sleep: 11.089183s
Total time on: 388.695558s
Deep-sleep closest to wake deadline: 698us
> sleepmask
sleep mask: 00020000
>
Change-Id: Iba708b6d53f96ef6d49d42bcf6d21db4732399b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193223
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This GPIO was configured as TTL. It should be open drain instead.
BUG=chrome-os-partner:27280
BRANCH=ToT
TEST=manual
Hard reboot, lightbar still works.
Try turning it off and on from the EC console:
> gpioset LIGHTBAR_RESET_L 0
lightbar goes dark.
> gpioset LIGHTBAR_RESET_L 1
> lightbar init
> lightbar on
lightbar comes on again.
Change-Id: If4d4beade8c95f3f231eeed435e35350ce866cea
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These are not currently checked by gerrit, but will be at some point
in the not-too-distant future.
The board/ directory gets additional owners to make it easier for
partner eng to make changes in ToT.
BUG=chrome-os-partner:27404
BRANCH=none
TEST=none (since gerrit doesn't check owners yet)
Change-Id: Ie21b9530fcc6d708ab987d9de80676f91faa72b9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191947
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a complete rewrite of the charge_state task used by x86 platforms.
Rather than having a bunch of state-specific functions, each with their own
error handling and special cases, this is organized like so:
Forever:
1. Read everything we can from the battery and charger.
2. Figure out what we'd like to do (including error handling).
3. Allow for customization to override that.
4. Do it.
Things I need to file bugs for are marked with "TODO(wfrichar)". I'll file
the bugs after this CL goes in, so that they'll have something relevant to
refer to.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
make buildall -j
Try it on Samus, watch it charge from nearly empty to full, both with and
without fastcharge enabled.
Also undefine CONFIG_BATTERY_PRESENT_CUSTOM, plug and unplug the battery to
be sure the trickle charging logic is correct when it can't tell if the
battery is present.
Change-Id: I3935cd3b87f322eb52178f8a675a886c16b75d58
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vic points out a corner case that the battery LED could be off by
the followng steps:
1. charge the battery to very full
2. disconnact the AC so that the LED is off for discharge.
3. plug AC again, then charger enters INIT state -->
IDLE0 --> IDLE where those states don't toggle LED.
BUG=none
BRANCH=big
TEST=Reproduced this bug on big. Verified this has been fixed by this CL.
Change-Id: I7125acd6b11953675ac6d4085e31e0560b384015
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189757
This returns all the parameters of the charger that must be monitored
frequently. While some of the fields are charger-specific, all of the
parameters are present in all supported chargers.
Nothing uses this yet.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
All targets build; all tests pass.
Change-Id: Id3e00532469b193aeab3acf93e94afe3ffb8c6b6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191985
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In most cases we can't actually know whether a battery is present until
we've been able to talk to it. This adds that NOT_SURE case.
BUG=none
BRANCH=ToT
TEST=none
Nothing uses this case yet, and the only time that battery_is_present() is
called is when we have hardware to detect the battery (which always returns
YES or NO). This is just preparation for charge_state_v2, which will need
the NOT_SURE case for trickle charging.
Change-Id: Ic5793de080529d50c98860450a021a1abae168db
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191782
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Using minimal runtime to fit the charger flash and RAM size.
It is currently more an experiment than the final layout written in the
stone.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run on STM32F051 Discovery with
limited RAM and Flash to mimic STM32F031.
Change-Id: I10ee1decfd1f1448edbc909f0e997367921c4b53
Reviewed-on: https://chromium-review.googlesource.com/189405
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Looks like this board just missed a change to temporarily fork the
charger code while it is being refactored.
BUG=None
BRANCH=nyan,blaze
TEST=make -j BOARD=blaze
Change-Id: I4ca630cc5210486928fbeda9af3e9c11ddbc8daa
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191214
once firmware branch exists, this commit need go into it and
doesn't need to be carried in master forever
BRANCH=blaze
BUG=chrome-os-partner:27120
TEST=USE="nyan_blaze" emerge-nyan_blaze chromeos-ec;flash nyan
board, verify ec is alive and version is reported as blaze
Change-Id: I115890a7122440a25c3d1f5e4b94248099a1de99
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/190610
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Enable low power idle for Samus.
BUG=none
BRANCH=none
TEST=tested on samus. made sure EC comes up with no obvious
problems and that the EC goes into deep sleep a minute after
no console activity.
Change-Id: I00e196560759dfd62915e645319de606f2f29df3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190791
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After Alex's CL 8a9817a, the i2c driver no longer hardcodes the
I2C port pin (Ya!). Remove the conflict pin setting in board files.
BRANCH=nyan,big
BUG=chrome-os-partner:26620
TEST=build and run on nyan board. Everything looks good.
Change-Id: Iee2c5f10f642da7ad00f503b6e615cb6aa472459
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189245
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove power_led_task and add the big-specific LED logic
BRANCH=big
BUG=None
TEST=manually
>> ectool led power blue: PWR LED blue
>> ectool led power yellow: PWR LED orange
>> ectool led power off: PWR LED off
>> ectool led power auto: PWR LED auto control
>> ectool led battery blue: BAT LED blue
>> ectool led battery yellow: BAT LED orange
>> ectool led battery off: BAT LED off
>> ectool led battery auto: BAT LED auto control
Signed-off-by: Cloud Lin <cloud_lin@compal.com>
Change-Id: I5ded361a46c627e4e4e6fcb6bddea9b487a46768
Reviewed-on: https://chromium-review.googlesource.com/188631
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Until we have real hardware, use the STM32F072B Discovery board as a
test vehicle and do a configuration compatible with both boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run EC console on STM32F072B Discovery board,
and pass all available unit-tests on target.
Change-Id: Ica691f9fc915d2873761025e7c019f8a6484b9b1
Reviewed-on: https://chromium-review.googlesource.com/188984
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Big can't be powered on by using 4s LGC AC14B8K battery.
Thus, add 4s battery definition to ec.
BRANCH=big
BUG=chrome-os-partner:26533
TEST=flash ec to big device and confirm battery works
Change-Id: I32d2eb2fabc70f3fc075a49a67c1fd4d30975981
Signed-off-by: MilesDY_Chen <MilesDY_Chen@compal.com>
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188651
The charger task was holding this either on or off in S3, no matter what we
wanted. We really only need to set it at S3->S0 or S3->S5, or when the
lid opens or closes. The rest of the time we should be able to turn it off
and on with gpioset, for testing purposes.
BUG=chrome-os-partner:26502
BRANCH=ToT
TEST=manual
Check the state with
gpioget TOUCHSCREEN_RESET_L
Open and close the lid, suspend the AP with powerd_dbus_suspend, etc. The
touchscreen should be on when the lid is open and the AP is in either S3 or
S0, off when the lid is closed or the AP is off.
Then
gpioset TOUCHSCREEN_RESET_L 1
gpioget TOUCHSCREEN_RESET_L
gpioset TOUCHSCREEN_RESET_L 0
gpioget TOUCHSCREEN_RESET_L
The change should persist as long as nothing else changes.
Change-Id: If7b6f809b1b28ae2699d0fbc6c9b2305fc57cbff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188869
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Refactored the i2c unwedge code to place it in the common directory
so that any EC chip can use it.
Added to the STM32F and LM4 boards, code to automatically detect and
unwedge the i2c bus at the start of an i2c transaction. Note that STM32L
already had this ability.
To enable unwedging of the i2c port though, the gpio pins for SDA and
SCL must be defined in the i2c_ports[] array in the board.c file. This
allows the i2c module to bit bang the unwedging for the given port. If
SDA and SCL are not defined for the port, then the unwedge code will
not run.
BUG=chrome-os-partner:26315, chrome-os-partner:23802
BRANCH=none
TEST=Manual testing on machines with different EC chips.
Testing made extensive use of https://chromium-review.googlesource.com/66389
in order to force wedging of the i2c bus so that we can attempt to unwedge
it. Note that you can easily test if the bus is wedged by running i2cscan.
On pit and spring:
On pit, after each of the following, I verified that the bus was automatically
unwedged.
On spring, the unwedge only runs at reboot, so, for the non-reboot wedge
commands, I manually ran console command unwedge, and verified that the bus
became unwedged.
(1) Bit bang a transaction but only read part of the response.
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. 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.
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.
Command to wedge: i2cwedge 0x90 0 5
On glimmer:
Added code to call i2c_unwedge in accel_init(). Then tested unwedging the
accelerometer with the following. One extra difficulty testing this with
the accelerometer is that sometimes the bit you stop on is high, which
means it won't be wedged at all, the next start transaction will reset
the bus. So, sometimes running i2cwedge won't wedge the bus and sometimes
it will depending on the acceleration data.
(1) Big bang transaction to do a "read" of accelerometer and stop partway:
i2cwedge 0x1c 0x0f 2 2
i2cscan to make sure bus is actually wedged
i2cunwedge
i2cscan to make sure bus is now unwedged.
(2) Bit bang transaction to do a "read" and stop partway, then reboot:
i2cwedge 0x1c 0x0f 6 2.
i2cscan to verify that the bus is working after the reboot.
Change-Id: Ie3328e843ffb40f5001c96626fea131c0f9ad9b1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188422
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The EC had inputs with internal pullups on SUS_STAT#, SUSPWRDNACK, and
SLP_SX#. But we never used those signals for anything. The pullups
cost 1.5 mW power in S3. So, remove those signals and their pullups.
They can be turned back on via CONFIG_CHIPSET_DEBUG.
BUG=chrome-os-partner:25568
BRANCH=rambi
TEST=build with and without CONFIG_CHIPSET_DEBUG. Verify gpioget and
powerindebug show the signals only when it's defined.
Change-Id: I0851243615c91a3aa8aa1b28df70809b578d2e74
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188389
Reviewed-by: Dave Parker <dparker@chromium.org>
Added rotation of accelerometer data into a standard reference frame
so that the host does not have to know about the orientation of the
sensors.
Also added a calibration routine to calibrate the rotation matrix to
get to the standard reference frame. Cleanup up calibration in the
process to make it more user friendly.
Changed the default accelerometer sampling rate to 100Hz.
BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=Tested the full calibration routine on a glimmer at my desk.
Used 'taskinfo' and verified that the higher sampling rate does not
bog down the EC. I found that the motion sense task is running for
about 200ms every 10 seconds, so about 2% CPU load.
Change-Id: I9ca1a4252f62a54016009c7d5e43b4cb1adf7e1d
Original-Change-Id: Id554511f7cc9549dfc9ed2d6337216bfa639359d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187172
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188385
This was always supposed to be open drain.
BUG=chrome-os-partner:22870
BRANCH=ToT,samus
TEST=manual
Try turning it off and back on again. ;-)
gpioset TOUCHSCREEN_RESET_L 0
gpioset TOUCHSCREEN_RESET_L 1
gpioset TOUCHSCREEN_RESET_L 0
Change-Id: I5e2a49c979294f68b86e2c91d2ccee5f6128ef5a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188045
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, the AP could only set the current wireless power state.
It couldn't determine what the EC would do in S3, nor could it get the
current wireless power state. Extend the wireless command to do so,
and add an EC console command to aid in debugging.
BUG=chrome-os-partner:25655
BRANCH=rambi
TEST=manual; expected numbers are from EC 'wireless' command
AP off -> 0x0, 0x9
AP on -> 0xd 0x9
AP suspended -> 0x9 0x9
AP on -> 0xd 0x9
ectool wireless 0x1 -> 0x1 0x9
ectool wireless 0xd -> 0xd 0x9
ectool wireless 0 0 0 0 -> 0xd 0x9 (and prints 0xd 0x9 to root shell)
ectool wireless 5 -1 -1 0 -> 0x5 0x9
AP suspended -> 0x1 0x9 (doesn't turn on 0x8, just turns off 0x4)
AP on -> 0xd 0x9
ectool wireless 0 0 0 -1 -> 0xd 0x0
AP suspended -> 0x0 0x0
AP on -> 0xd 0x9
Change-Id: I8ead2d4a4423b51ec4f638bf94c62de98726b25c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187273
Nyan uses common/charge_state instead. So, fix the dependence.
Since snow/spring/pit are using common/pmu_tps65090_charger, keep them.
BUG=None
BRANCH=Nyan
TEST=build and works fine on Nyan 3.2
Change-Id: I985f7980578ac22602b1fbffa51edf039078bc05
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Samsung change the temperature range in battery discharing state from (0
<=temp < 100) to (-20 <= temp < 70) from this year. That's why we have to
change the battery_temperature_range structure value as soon as possible
so that our reliability team check the battery.
BUG=chrome-os-partner:25731
TEST=Boot on the pit / pi and then check the battery is working or
not in the oven.
BRANCH=pit
Change-Id: I3289d22176af043e80a881f1626da386e823d857
Signed-off-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/186040
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This gives the AP a way to see that temperature for DPTF. Alarm
thresholds were defined on a per-sensor basis, so they come along for
free.
BUG=chrome-os-partner:25585
BRANCH=rambi
TEST=temps command shows same temp for battery as battery command (other
than rounding error; battery command shows with 0.1C accuracy).
'ectool temps all' shows the battery temp as the last temperature.
Unplug battery and temps command shows error for the battery temp,
as does 'ectool temps all'.
Change-Id: I1bce72f164d9fb1be631e7241a4ea24ddf409d7a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185444
Reviewed-by: Dave Parker <dparker@chromium.org>
This is experimental for now; the capsense chip simply reports its buttons
as the number keys on the keyboard (1-8).
BUG=chrome-os-partner:23382
BRANCH=samus,ToT
TEST=manual
To test, you'll need a reworked and correctly programmed capsense module.
Boot the system, and switch to VT2. Touch the capsense bar and you'll see
the input appear on the console as though you were typing numbers.
Note that the capsense hardware is still buggy. Refer to the bug for
workarounds.
Change-Id: I4c3a8b70b8197ffd538c38c59c9336383365afa7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185434
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Green when charged and ext. power plugged in.
Orange when charging.
Blinking orange if there is a charging/battery related error.
Blinking green if in "charge force idle mode" in the factory.
Off otherwise.
BUG=chrome-os-partner:23634
BRANCH=rambi
TEST=test each of the states above
To fake battery error, unplug battery and wait 30 secs
To force idle, 'ectool chargecontrol idle'
Change-Id: I85fff72d1df85bbbaa1da66572f44f58a960244e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185240
Reviewed-by: Dave Parker <dparker@chromium.org>
From DV2 board of pit, we'll use 3 color-LED instead of power LED on keyboard.
So, we have to add the function to control 3 color-LED in pmu driver.
BUG=chrome-os-partner:24855
TEST=Tested on the pi and pit board about all power status.
BRANCH=pit
Change-Id: I7b1df39de8fa56eab73779abfa52cf8f72427b44
Signed-off-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/181588
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
