This is to prevent temperature value being read before the first time we
poll sensors causes unexpected error.
BUG=chrome-os-partner:12614
TEST="sysjump RW" and then "temps" immediately. Check all temperature
readings are near 300 K.
Change-Id: I5c84d9696b4876fdfcf14c3a416cbc09c040d4ee
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30138
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There was an errata issued for the i2c on STMF100xx. It specified that
not all guarantees apply to i2c on these chips if you are not using DMA
to load the data. To prevent problems, I am converting the i2c code on
the EC for Lucas over to DMA.
The master functionality was already converted over in change I2fb80dcb,
this change switches over the slave-mode i2c code to also use dma now,
instead of polling, as per the errata.
BUG=chrome-os-partner:10901
TEST=The slave mode i2c code is used heavily during normal use of the
Chromebook, including boot up and using the keyboard. Start up the cpu
uart console, and boot the system. Then once it's fulling started, make
sure that pressing keys does not cause any errors and that the key presses
are working.
Change-Id: I8d665054bccbd3ca9b8dcc5e0fa74b2fbe49f52d
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30024
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
- Add a special port80 event for LPC reset assertion and use that event
to store the previous post code.
- Add a new command to retrive the last saved post code so I can easily
query it at boot/resume and log unusual codes.
BUG=none
TEST=manual (with additional coreboot/mosys changes)
- interrupt boot process by issuing x86reset on EC console or
by using warm reset button on servo
- read event log with mosys on next boot
78 | 2012-08-13 09:24:04 | System boot | 262
79 | 2012-08-13 09:24:04 | Last post code in previous boot | 0x9e
80 | 2012-08-13 09:24:04 | System Reset
Change-Id: I7b9f10442b9c468d89fde4e75adb94b0c07c2c8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29995
Reviewed-by: Randall Spangler <rspangler@chromium.org>
system_hibernate(0, 0) now hibernates until a wake pin assert, with no
RTC wake.
BUG=none
TEST=manual
command -> expected reset flags from 'sysinfo'
1. reboot -> soft
2. reboot hard -> power-on hard
3. hibernate (and press power button) -> power-on wake-pin
4. hibernate 3 (and wait for timeout) -> power-on rtc-alarm
5. hibernate 10 (and press power button before 10 sec) -> power-on wake-pin
hibdelay 10
then shut system down and run on battery
10 sec later, system should hibernate.
Change-Id: I399413d265f6fcf808adf9ed1db7b812a1b12fc2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29923
Reviewed-by: Vic Yang <victoryang@chromium.org>
There was an errata issues for the i2c on STMF100xx. It specified that
not all guarantees apply to i2c on these chips if you are not using DMA
to load the data. To prevent problems, I am converting the i2c code on
the EC for Lucas over to DMA.
Here the i2c's master functionality is retrofitted to use DMA
instead of polling to fill the i2c buffer. The slave functionality
is still left in the old style for the time being, but will also be
converted soon.
BUG=chrome-os-partner:10901
TEST=From EC console, make sure that "battery" and "pmu" commands work.
They both use i2c, so if i2c had been broken they would fail.
Change-Id: I2fb80dcb68632938df1c9165ebd5a67cb5194451
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29811
Reviewed-by: Simon Glass <sjg@chromium.org>
BUG=chrome-os-partner:12483
TEST=from root shell, 'ectool console', then on the ec console, type
'help list' a few times to generate lots of debug output, then repeat
'ectool console'. Then on EC console, 'syslock', and then 'ectool
console' should fail.
Change-Id: Ie1c74c7e35d6b8228615d20192fd90093977de64
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29825
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When STOP mode is activated, the UART is not able to wakeup the EC when
sleeping, preventing to enter commands on the EC serial console.
Allow to switch the UART RX line as a GPIO connected to EXTINT10 to
wakeup the system on incoming character.
This is just a debug feature since EXTINT10 is normally used to scan the
keyboard.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, enable CONFIG_FORCE_CONSOLE_RESUME at build time and type
"sleepmask 0" on the EC console, see I can get the serial console back
by typing a character on the serial console.
Change-Id: I936cbf13707ef8cde277f1053a4d35d23ff06511
Reviewed-on: https://gerrit.chromium.org/gerrit/29776
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
It was previously only enabled for 1500us during boot, but in a way
that triggered a needless round of notifications to other modules.
This is cleaner.
This also fixes adc_init() not initializing the task IDs to wake when
interrupts come in, and removes some unneeded code from other init
functions.
BUG=chrome-os-partner:12472
TEST=boot system and run adc command. Should still provide reasonable data.
Change-Id: I9ae5857d988c727caf5d53f551a2f12b30974c0f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29806
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This ensures it comes up in a known-good state.
BUG=none
TEST=manual
scratchpad write 0x12345
hibernate 1
scratchpad -> still 0x12345
keyboard reset
scratchpad -> still 0x12345
pull power and battery, then plug back in
scratchpad -> now 0
Change-Id: I2c205f53e03eefe915260b9be39c809ea7d69293
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29500
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the AP is not running and we have enough time go to STOP mode
instead of simple idle.
The EC consumption should drop from 12mW to a few mW.
This is currently not activated by default, you need to type "sleepmask
0" in the EC console to activate it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, check the software is still working properly when STOP
mode is activated and measure power consumption on 3v_alw rail.
Change-Id: I231d76fe6494c07b198c41694755b82d87c00e75
Reviewed-on: https://gerrit.chromium.org/gerrit/29315
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
We have seen instances where the AP has interrupts disabled for a long
period of time (specifically when doing a lot of printk messages to
the console). When this happens the host can't service i2c in < 10ms
(it needs an interrupt per byte) and we were getting a timeout. We'll
increase the timeout to 100ms to avoid these problems. Better to be
safe than sorry.
This timeout runs from the host command task so having the delay
shouldn't be a terrible thing (we're not running from an IRQ handler
or anything).
Only affected the timeout for slave mode specifically so as not to
affect any untested behavior.
BUG=chrome-os-partner:12123
TEST=With serial console enabled, run this in two different ssh
sessions:
a) while true; do flashrom -p internal:bus=i2c -r /tmp/ec.bin; done
b) while true; do /usr/local/lib/flimflam/test/connect-wifi GoogleGuest; done
...if flashrom reports success over and over again then this is good.
Change-Id: I7f32d5f1e4134896c857ee26f449a1fdd579d589
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29621
BUG=chrome-os-partner:12290
TEST=manual
From EC console,
rtcget
(wait a few sec)
rtcget
hibernate 3
(wait for wake)
rtcget
(hold power+refresh; wait for reboot)
rtcget
rtcset 20000
rtcget
(wait a few sec)
rtcget
Each rtcget should be a few seconds after the previous one.
Pull the battery and remove AC power. Then restore AC power and
rtcget
(wait a few sec)
rtcget
Should be close to 0. That is, it should have reset to 0 when power
was lost.
From root shell,
ectool rtcget
should match the time from rtcget, truncated to the nearest second.
ectool rtcset 30000
should set the time (do a rtcget to check).
Change-Id: I535097feb7af8aa6583c8ef50ade66bb19bdff8f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29349
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Superseded by EC software sync (hash-based).
Sig-based vboot was correctly implemented, but ended up being too slow
to be useful given the limited processing power of the EC chips, and
we also couldn't come up with a manageable way to handle A/B
autoupdate of signed EC firmware.
This change and an associated vboot_reference change shrinks the EC
binary by ~2KB.
BUG=chrome-os-partner:11232
TEST=build link,snow; boot link and check that 'hash' command still works.
Change-Id: I3f03ae2d0a4030977826980d6ec5613181e154c2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29496
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
There were a number of problems resulting from i2c crashes,
particularly when trying to access the battery. The problem is that
the stack was overflowing on this particularly deep path, all the way
down to wait_status. This in itself was fine, but if there was a
timeout, debugging information would be printed to the uart, and that
function would cause an exception and restart the EC.
To fix it, I stripped the debugging CPRINTFs from wait_status. This
allows everything to work fine, but looses some information for
debugging. To allow future developers to still see what event the i2c
was waiting for, I added an additional variable to store it in, so that
it can be displayed/handled further up the stack.
BUG=chrome-os-partner:12245
TEST=Boot the machine using a Servo. On the AP's UART, run
"cros_test i2c" to start pounding the i2c bus. Then from the EC, run
"pmu 1000" and then "battery 1000" there should be no error messages,
exceptions, and the EC should not restart. Repeat this process with i2c
arbitration disabled (remove the flag in ./board/snow/board.h). You
should suffer no fatal errors. cros_test may report errors detected,
but the EC will never crash, restart, or throw exceptions. These other
errors are the EC and the AP stepping on each other's toes now that you
have disabled arbitration.
Change-Id: Idd2f017d3557652bf3e8536c4ac776c1f70319cb
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29351
Reviewed-by: Simon Glass <sjg@chromium.org>
- 'port80 intprint' toggles printing port 80 codes in interrupt
handler (turning that off speeds up port 80 capture a bit, if you're
sending port 80 codes very rapidly)
- 'port80 flush' flushes the log buffer
- log buffer expanded to 256 entries
- log buffer tracks S3->S0 power state transitions, so you can tell
where each boot starts
This uses ~500 bytes more RAM on the EC, but we've got piles of RAM
(with this change we're using 17KB out of 32KB).
BUG=none
TEST=manual
- boot system
- port80 -> prints data
- port80 intprint -> now disabled
- reboot; wait for reboot; no port80 debug output during boot
- port80 -> prints data from previous boot AND this one
- port80 flush
- port80 -> nothing in log
Change-Id: I64ee72fb13ab0fdd85d04b9640b5390fdac31400
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29420
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When we wake up from a deep sleep mode, the system timer clock might
have been stopped. We need to be able to set using another time source
(e.g. the RTC).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=make BOARD=snow && make BOARD=link
on Snow, on a software implementing STOP mode, check the system time is
still accurate by comparing it to the wall clock.
Change-Id: Ieddbb423d052c7aceb398470866b25b25a74c0a0
Reviewed-on: https://gerrit.chromium.org/gerrit/29314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The i2c timeout error message is false positive warning. It happened
when wait_status() function got a good result, but took too long to
complete (> 1ms).
This warning message can be removed safely.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:9759,12222
TEST=none
Change-Id: I2a670b76a5d741dc82ea59eacc233c4719eb3263
Reviewed-on: https://gerrit.chromium.org/gerrit/29254
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
If it's pressed, need to track that or we'll ignore the release. And
then we'll leave the power button signal asserted to the PCH, and
it'll shut down 4 seconds after the power button was pressed.
BUG=chrome-os-partner:11971
TEST=hibernate 10, then press power button for ~0.5 sec, then release
system should boot normally
Change-Id: Ibb9b8a8827cca6c81bac06dc9543de1a76fa5aad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28863
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, if you used Esc + Reload + Power to reboot into recovery
mode, you would be stuck in it until you manually rebooted the EC with
"Reload + Power." This was because the button combo set a switch that
was never un-set. To fix it, the keyboard_scan function now sets a host
event, that is serviced once, and then cleared. As a result, the next
time you reboot after triggering recovery mode, it should boot as before
you triggered recovery mode.
BUG=chrome-os-partner:10889
TEST=Boot device in normal mode. Press Esc + Reload + Power, and boot
from usb. Power off the device and remove the usb media. Power on the
device again, and there should be no recovery screens during the boot
process. Next, repeat these same steps, but from starting in developer
mode. After recovery, when you reboot, the device should return to
developer mode.
Change-Id: Idcb8dde6f8ba5f680f4d34e61ae0d12992281cbb
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28710
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ARM EC was being rebooted when both the power and one of several other keys
were pressed. (LCtrl, Tab, Reload, t, [, ], y, Dim Screen and Mute) It should
only do this when the key combo PWR + Reload is pressed.
To fix it, keyboard scanning is disabled whenever the power button is
pressed. It locks a mutex indicating that scanning should be disabled,
and the main keyboard scanning task blocks on the step where it sets up
the keyboard and waits for the mutex to unlock.
BUG=chrome-os-partner:10889
TEST=Pick one of the troublesome keys. First press it, then quickly
press the power button. Then press the power button followed
by the troublesome key. Repeat this process several times for each key,
it should not reset the system.
Press power + reload, this should still reset the system.
Pressing and holding power should initiate a shutdown.
Change-Id: Ib60d2ebbb57eb8a3c135662514ec622c37a7eb07
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28402
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This removes a bunch of unnecessary typecasts, since you can assign
to/from void * without them. This also uncovered a few cases where
const was being cast away for the input params; now fixed.
BUG=none
TEST=mkbp hash from u-boot console, and/or system boots ok
Change-Id: Ic314b9d2ca06226ea8a09703ef5c1a912eb7146d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28500
Otherwise, EC software sync protects the entire firmware except in recovery mode, regardless of the WP pin.
BUG=chrome-os-partner:11847
TEST=boot with WP enabled but RO-at-boot disabled; flashinfo should show
entire flash still writable
CQ-DEPEND=28444
Change-Id: I58d60adfaa952b127e8695213f95f6da0e34821d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28445
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When updating the EC and BIOS, we have to run for some times the new EC
with the old BIOS (after we have upgraded the first half of the EC and
before rebooting the machine), let's handle the ACPI request so the
kernel is not sending them into a loop triggering a reboot of the
machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:11821
TEST=update a Link EVT using "chromeos-firmware --mode=factory" from
current BCS binaries (EC v1.1.104-b8d7d8f / Firmware 2476) to next
candidates ( EC v1.1.301 / Firmware 2657).
Change-Id: I115a42e6c33c143cbdc38341dcf7e0f61a8bd771
Reviewed-on: https://gerrit.chromium.org/gerrit/28409
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
This is a significant rewrite of the flash module, since it turns out
that much less of the flash logic is actually common between stm32 and
lm4.
BUG=chrome-os-partner:11699
TEST=on link,
(enable hardware wp)
flashinfo -> wp_gpio_asserted
flashwp enable
flashinfo -> wp_gpio_asserted ro_at_boot
reboot
flashinfo -> wp_gpio_asserted ro_at_boot ro_now
flashwp disable -> error 7
flashwp now
flashinfo -> wp_gpio_asserted ro_at_boot ro_now rw_now
reboot
flashinfo -> wp_gpio_asserted ro_at_boot ro_now
(disable hardware wp)
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> (no flags)
Change-Id: If22b02373946ce1c080d49ccded4f8fa3e380115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28200
Reviewed-by: Vic Yang <victoryang@chromium.org>
It's a bit odd that the drivers package up a command to be processed
by host_command, but then host_command calls a global function to
pass the response back.
This adds ambiguity in the host_send_response() implementations as to
whether the command being responded to really is using the same
buffers that the driver set up.
Add a function pointer to the command, and have host_command call
that. Add status to the args structure also, which removes some of
the special case logic for error handling.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet)
Check that snow and link still process commands correctly over I2C
from U-Boot. At this stage only the old interface is supported.
SMDK5250 # mkbp test
Old interface:
New interface:
Version 0: ec_command() returned error
Test failed with error -1
SMDK5250 #
Change-Id: I816738150bce3f8d78e7cd32abf361621aa12312
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28154
Reviewed-by: Randall Spangler <rspangler@chromium.org>
And tidy reporting fan/thermal via memmap.
BUG=chrome-os-partner:11628
TEST=manual
ectool pwmgetfanrpm -> should report fan speed
ectool temps N ->
should work for N=0-9
reports error for N=15-23
reports invalid sensor ID for N<0 or N>23
Change-Id: I484f81399f5e9dae9c759401091cc6f5acc733ff
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28032
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently, I2C commands look like this:
Input:
cmd8 [params bytes] checksum
Output:
response8 [response_ptr bytes] checksum
Use a prefix byte of (0xDC + cmd_version) to indicate the command
version. This is compatible with the existing protocol, since there
are no host commands in the range 0xDC-0xFB. If the first byte of
the from-host data is 0x00-0xDB, it's a version 0 command.
There is no change to the output format, since the EC needs to hand
back a response which matches the version requested by the host.
New input:
(0xDC+ver8) cmd8 paramlen8 [params bytes] checksum
New output:
response8 responselen8 [response_ptr bytes] checksum
If the host gets a response of EC_RES_INVALID_COMMAND, it knows it's
talking to an old EC, and at most version 0 of the command is supported.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet, so far only snow is tested)
Check that snow and link still process commands correctly over I2C
from U-Boot.
SMDK5250 # mkbp test
Old interface:
New interface:
Test passed
Change-Id: I1c21f2b036091e9122b4f980ca5f5af34f7fc070
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27470
We are about to add more logic here, so move it this code out of
the event handler and into its own function.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet)
Check that snow and link still process commands correctly over I2C
from U-Boot. At this stage only the old interface is supported.
SMDK5250 # mkbp test
Old interface:
New interface:
Version 0: ec_command() returned error
Test failed with error -1
SMDK5250 #
Change-Id: I5387eb5533ab6faa27769f4cf21075387357371d
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27469
It's a bit odd that the drivers package up a command to be processed
by host_command, but then host_command calls a global function to
pass the response back.
This adds ambiguity in the host_send_response() implementations as to
whether the command being responded to really is using the same
buffers that the driver set up.
Add a function pointer to the command, and have host_command call
that. Add status to the args structure also, which removes some of
the special case logic for error handling.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet)
Check that snow and link still process commands correctly over I2C
from U-Boot. At this stage only the old interface is supported.
SMDK5250 # mkbp test
Old interface:
New interface:
Version 0: ec_command() returned error
Test failed with error -1
SMDK5250 #
Change-Id: Ic4afdcd7689666cc0f6af228abc6cffe41b0fcbf
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27468
Now that we have hibernate ability, we can use this to perform a hard
reset.
BUG=chrome-os-partner:11579
TEST=Build success and working on 'snow':
'reboot' and see reset cause is 'reset-pin soft'.
'reboot hard' and see reset cause is 'hard'.
Build success on 'daisy'.
Change-Id: I18132eee2f0d574d7d1674f7be25249dbe19749d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27930
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds hibernate support to stm32f. Watchdog can wake us but cannot
be stopped unless system resets, so the longest time we can hibernate
for now is about 26s. And wake from wake pin is not working.
Nevertheless, we can use this for hard reset for now, and fix these
problems later.
BUG=chrome-os-partner:11579
TEST='hibernate 1' and see system wakes after 1 second. See reset cause
is 'hibernate'.
Change-Id: Iafa42012b59c12b70e18a7908c5d864c6e8bd2b4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27909
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In theory this should be done by a kernel driver,
but there is already a suspend hook so it is easy
to have the EC turn off the backlight if it is
not done by the host.
BUG=none
TEST=manual
1) boot Link device
2) log in and run 'powerd_suspend'
3) observe that keyboard backlight is turned off
Change-Id: I10b83505d681f5b6d9cb32c1bef62dc21dd038e1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27721
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
