If multiple TCPCs are present on a system then we may have multiple
alert signals, each of which alerts us to the status of a different
TCPC. Make boards with external non cros-ec TCPCs define
tcpc_get_alert_status, which returns alert status based upon any alert
GPIOs present, and then service only ports which are alerting.
BUG=chromium:551683,chrome-os-partner:47851
TEST=Verify snoball PDCMD task sleeps appropriately when no devices are
inserted, and verify ports go to PD_DISCOVERY state when we attach
samus. Also verify that glados / glados_pd can still negotiate PD.
BRANCH=None
Change-Id: Iae6c4e1ef4d6685cb5bf7feef713505925a07c8c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313209
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
These functions are mostly no-ops it turns out, maybe something will
be needed to be done for RSA and ECC initialization, for now leaving
those functions commented out as a reminder.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=tests passing before this change still pass.
Change-Id: Iee9aaf133a55a6197c9896ed48efb34a4b3340c6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314096
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Let's increase it to 4K, this seems to be adequate for tests so far,
but with the enabled stack size monitoring we should find out quickly
if in certain cases this is not enough.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the test involving the use of SHA hardware does not fail in
mysterious ways any more.
Change-Id: I86da89ccca42d1a60ce7c1dfef08d21bf44f1eee
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314095
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The main cr50 application is pretty stack use intensive, let's enable
stack overflow monitoring while project is in development.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=none
Change-Id: Iac9404b585664b891b63e9df058cdeb2654fc323
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314094
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change includes hardware and software support for SHA1/256 on
CR50. When running in the RO image, only hardware sha256 support is
included. When running in the RW image, the code auto-selects between
the software and hardware implementation. Software implementation path
is taken if the hardware is currently in use by some other context.
Refactor the CR50 loader to use this abstraction.
The existing software implementation for SHA1 and SHA256 is used for
the software path.
CQ-DEPEND=CL:*239385
BRANCH=none
TEST=EC shell boots fine (implies that SHA256 works)
BUG=chrome-os-partner:43025
Change-Id: I7bcefc12fcef869dac2e48793bd0cb5ce8e80d5b
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313011
When flashing the STM32 chip, the flash_ec script stops the processes
which occupy the EC UART in order to avoid their interference. After
flashing, it asks these process to continue.
However, when running FAFT in the lab, the EC UART may be occupied by
servod for sending some EC commands per test requirements. The
flash_ec should not stop the servod; otherwise, all the following
dut-control commands will be failed.
So this change blacklists the process servod and init.
BRANCH=none
BUG=chromium:552073
TEST=Manual
Ran a FAFT test, e.g. firmware_FAFTSetup, which occupies EC UART.
Ran another process, e.g. minicom, which also occupies EC UART.
Ran the flash_ec: flash_ec --chip stm32 --image /tmp/ec.bin
Its output:
INFO: Using ec image : /tmp/ec.bin
INFO: ec UART pty : /dev/ttyO1
INFO: Flashing chip stm32.
INFO: Using serial flasher : /usr/bin/stm32mon
INFO: Sending SIGSTOP to process 2369!
INFO: Sending SIGSTOP to process 7949!
INFO: Skip stopping servod or init: process 1.
INFO: Skip stopping servod or init: process 639.
...
INFO: Restoring servo settings...
INFO: Sending SIGCONT to process 2369!
INFO: Sending SIGCONT to process 7949!
Change-Id: I4d72b7e2caf0ca2963bb9dee51764869e829c569
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313581
Commit-Ready: Wai-Hong Tam <waihong@chromium.org>
Tested-by: Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Apply the recommended USB EQ settings for Tx and Rx channel
loss compensation to the PS8740 USB mux chip. This is called
after the driver is initialized and sets up the chip for the
first time.
BUG=chrome-os-partner:47074
BRANCH=none
TEST=build and boot on chell, read back registers to verify
> i2cxfer r 1 0x34 0x32
0x60 [96]
> i2cxfer r 1 0x34 0x3b
0x60 [96]
> i2cxfer r 1 0x20 0x32
0x60 [96]
> i2cxfer r 1 0x20 0x3b
0x60 [96]
Change-Id: I95334be9eed2858864787500a7483fa043947148
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313748
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds a new function that can be use to apply USB EQ settings
to the mux. It currently only exposes the Tx and Rx channel
loss compensation.
BUG=chrome-os-partner:47074
BRANCH=none
TEST=build and boot on chell
Change-Id: I1ec83cdcbb17da8e7289e6633509b64f01b14348
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313747
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds a callback for board specific initialization that is called
after the driver init function. This will allow a board to apply
port-specific tuning (such as USB EQ settings) to the mux chip.
BUG=chrome-os-partner:47074
BRANCH=none
TEST=build and boot on chell
Change-Id: Ib162f9a2c5239678c46b80e5517823b336f6b66c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313746
Reviewed-by: Shawn N <shawnn@chromium.org>
- Disable SLP_S0 as interrupt source for proto boards
- Remove pull-up on PLATFORM_EC_PROCHOT for EVT boards
BUG=chrome-os-partner:47346
BRANCH=none
TEST=build and boot on chell proto
Change-Id: I3196e9fe1c921d66fd841c6ca1c3d8df131db9eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313663
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Dcrypto support is a hardware property, it belongs with the chip
sub-tree, not with the board.
This patch just moves the files and modifies the makefiles to pick up
the files at the right spot.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the image still builds, the devices still boots, the
test/tmp_test/tpmtest.py still succeeds.
Change-Id: Ie321ac738c11a9f403a7943524c56ec4366db297
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313655
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This is required to be able to consolidate hardware and software hash
implementations.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the device still boots up.
Change-Id: If420541427bb316b97bc20a21fd3fd8a57708244
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313654
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This regulator must be enabled in order to power snoball through the
VBUS path.
BUG=chrome-os-partner:47851
BRANCH=None
TEST=Boot snoball with 12V supply on VBUS, verify that EC is stable
and not resetting constantly.
Change-Id: Id1b79b69f641e0c80160b161fe177aeb9c3de733
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313811
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
__assert_func() is modified to match prototype defined in the global
include file. TPM2 library handling of asserts will have to be
modified later.
BRANCH=none
BUG=chrome-os-partner:43025, chromium:559344
TEST=assert message now include valid pertinent information about the
point of failure.
Change-Id: I8050c018c36d5d98b879daa2b600fc7c76ef9126
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312868
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The utility builds on the extended command protocol recently
introduced in the EC and allows to test implementation of various
cryptographic primitives available on CR50.
This patch brings in the ftdi_spi_tpm.c and mpsse.c from the AOSP
trunksd package. mpsse.c has been modified to limit its feature set
(no i2c or bigbang support, only SPI0 mode), and ftdit_spi_tpm.c has
been modified to properly present binary strings to the Python swig
wrapper.
The crypro_test.xml file includes descriptions of the tests to perform
on the target. Most of its contents other than the first crypto_test
element are borrowed from NIST AES test vectors set. See file header
for description of the contents format.
The actual test command is the tpmtest.py. When started it establishes
connection with the device, and then reads test vectors from
crypto_test.xml and executes them one at a time.
Starting the test program with the -d command line argument enables
debug output sent to the console.
There are some other programs in ./extras which use the mpsse.c from
AOSP, they will have to be modified to use the local copy.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=ran the following in the directory:
$ make # output suppressed
$ ./tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
\New max timeout: 1 s
SUCCESS: AES:ECB common
SUCCESS: AES:ECB128 1
SUCCESS: AES:ECB192 1
SUCCESS: AES:ECB256 1
SUCCESS: AES:ECB256 2
SUCCESS: AES:CTR128I 1
SUCCESS: AES:CTR256I 1
- temporarily corrupted the contents of the clear_text element of 'AES:ECB common':
$ ./tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
|
Out text mismatch in node AES:ECB common, operation 1:
In text:
74 68 69 73 20 20 69 73 20 74 68 65 20 74 65 78
74 20 77 68 69 63 68 20 77 69 6c 6c 20 62 65 20
65 6e 63 72 79 70 74 65 64 20 69 66 20 65 76 65
72 79 74 68 69 6e 67 20 69 73 20 67 6f 69 6e 67
20 66 69 6e 65 2e 20
Expected out text:
3d e2 0f f9 ee d9 62 ce f0 8a 17 57 c6 04 86 d0
3d ec 44 72 d8 79 18 87 3f 31 81 6d 66 4c bb 10
da 8d e0 9f 63 67 b3 cc 64 b4 e8 bd 12 b0 a9 c9
09 6d f0 9f a4 e2 ae fb 0d fe 1c 90 6c e2 fe f0
68 8f b5 34 07 76 e2 a9 72 8e dd 7b 8b 52 2b 8b
Real out text:
f9 50 fe 93 c9 3f cb e5 9e e0 a4 7e 51 1a bb a0
36 2f d1 d6 5f a8 1d 22 5a 1a bb f7 e6 65 89 55
ad e8 f5 8f 1a 20 ff a5 c4 de 76 3e b8 ef cc 8d
9d 94 b8 89 22 1c c9 2a 43 58 c3 8c 75 9f 9f 56
ab 2f 89 1a f6 a0 36 8b 95 23 91 d6 23 47 77 36
Change-Id: I2687ac03236b528e71b92df7cb35606e473ab2c5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313443
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This common for all g based boards file should not be associated with
a single board.
BRANCH=none
BUG=none
TEST=the device still builds and boots.
Change-Id: I34c49a095abd8e49b492c318823dd8f56609fdc8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313631
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
A few minor changes, this is still a USB image, no dcrypto support.
BRANCH=none
BUG=none
TEST=built an image using the new description and signer files, booted
it on an fpga board:
> vers
Chip: g cr50 B1 20151118_11218
Board: 0
RO: cr50_v1.1.4081-c06cf49-dirty
RW:
Build: cr50_v1.1.4081-c06cf49-dirty 2015-11-20 09:56:03 vbendeb@eskimo.mtv.corp.google.com
>
Change-Id: I29bbaaa512ff604beb209a606acf19282331c96f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313630
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
It is way to chatty because the host is often polls the device for
extended periods of time.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=booted the device, observed calmer console.
Change-Id: Id318b57b274ed6c327a05dcd2bcb09ac2b89cb5c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312867
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In case the actual ODR rate is way higher that the AP asked for,
we don't have to settle to a slower EC rate if
EC rate == AP requested ODR rate.
BRANCH=smaug
BUG=none
TEST=Run android.hardware.cts.SingleSensorTests
Change-Id: I437f47bd942a16694c7efcdbc00201352f0480a6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313641
Reviewed-by: Alec Berg <alecaberg@chromium.org>
AP could collect samples while motion task was still adding timestamp.
A data stream not ending with a timestamp can lead to timestamp error in
the kernel.
This is espcially true if the motion task interrupt the AP back to back,
when sensor ODR changes for instance.
BRANCH=smaug
BUG=b:24367625
TEST=Run android.hardware.cts.SingleSensorTests
Change-Id: I5820216a2cfc0a869db7dc5ef75d4be126a53b4f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313640
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When task creating, input_current will be set as condition.
But there is no more handling for this value. so it will remain
even if condition is changed.
This will put input current decision int the loop so that we can
proper input current as battery existence.
BUG=chrome-os-partner:47546
TEST=make buildall, command 'charger' with/without battery.
and see it is changed dynamically
BRANCH=None
(cherry picked from commit d2ac89d58c34d7cc0a2a3fb591fcdcddbe2e9feb)
Change-Id: Ib72e20faf7c7f302a4e39d43b23176247e5176fa
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/312950
Commit-Ready: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On assertion of SLP_S0, EC goes to S0ix while system is in Lucid sleep
and EC is eligable to enter heavy sleep idle task.
Wakeup from S0ix by lid open, any key press, power button or track pad
will be done by PCH block by asserting SLP_S0.
At S0ix, 1 msec pulse will be generated every 8sec and this signal
should be ignored since this is NOT S0ix entry/exit related and defered
interrupt for SLP_S0 were added.
BRANCH=master
BUG=none
TEST=in OS shell, run following commands.
Following command is valid with coreboot with S0ix patches.
"echo freeze > /sys/power/state"
then,
Measure EC power consumption and compare it with one in S0.
And on EC console, there should be NO periodic message, "power
state 4 = S0ix, in 0x001d" every 8 sec.
Change-Id: Ia9cf5256b1ad7234815d4b6dbe2b45788aaf49dd
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/307947
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Snoball uses DMA2 + DMA3 for UART1 debug console. No changes are needed
to STM32_SYSCFG_CFGR1 since this is the register default config.
BUG=chrome-os-partner:47851
BRANCH=None
TEST=Boot snoball, verify EC console works in both directions.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id984b63f8c0c2d5c042265fd86b3d0c71fd68e6f
Reviewed-on: https://chromium-review.googlesource.com/313168
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, using flash_ec for mec1322 chips only
supports flashing from servo v2. Updated to work from
v3 as well. This is a resubmission.
BUG=chromium:554230
BRANCH=None
TEST=tested locally with beaglebone/cyan setup at my desk
Ran flash_ec --board=cyan --chip=mec1322
--image=/tmp/image.bin. Also ran with servov2.
Change-Id: Ia2a7edb577350cd4aa1c9835f24f4e3df2e508e2
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313053
Reviewed-by: Wai-Hong Tam <waihong@chromium.org>
TIM14 can't be used in our existing master / slave system clock config
due to lacking master mode control / TRGO.
BUG=chrome-os-partner:47851
TEST=Manual on snobal. Verify that timer interrupts function, HOOK_SECOND
hooks are called and watchdog doesn't fire.
BRANCH=None
Change-Id: I659b3cc46cf350fc58d88853fcc3d436b5f37d52
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313189
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Our system timer uses capture compare mode, so the TIM1_CC interrupt
should be used.
BUG=chrome-os-partner:47851
TEST=Set TIM_CLOCK_LSB to 1 on snoball (TIM1), verify that timer
interrupts function, HOOK_SECOND hooks are called and watchdog doesn't
fire.
BRANCH=None
Change-Id: Id5cc18d0cd216b5b448e11cf0bae9696db74eb02
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313188
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
SLP_S0 can reside at an intermediate voltage even with the internal
pull-down. Eliminate interrupt storms by making this pin a
non-interrupt, which also necessitates making the pin a non-power
signal. This change will inhibit us from enabling S0ix later on glados.
BUG=chrome-os-partner:47617
BRANCH=None
TEST=Successfully power sequence on glados.
Change-Id: Ic8644ace136a984be300c6d7ac96be4cd1be40d0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313346
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Throughout the code, there are comparison between frequency (in mHz) and
period (in us). To improve readability, append units (_mhz, _us) after
variable names.
BRANCH=smaug
BUG=none
TEST=compile.
Change-Id: Icc9c66d9f06c526fc3b74fd85ca9759b702ee416
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313221
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We need to wake up the main task, even if we disable a sensor. It will
force sending the sensors samples in the FIFO and put a timestamp behind
them.
Also, reduce the interrupt period by 10us to be sure we fire interrupt
to the AP even if there are some variation in the timing calculation.
BUG=b:24367625
BRANCH=smaug
TEST=Run ts.SingleSensorTests overnight.
Change-Id: I6d966d52b5cbb72ba5eb936bc2fad6c06c7d8605
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312986
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If EC sampling rate is close to sensor rate, decrease sampling frequency
by 5% to prevent samples by the EC without data.
It can happen when the clocks are slightly different and get
unsynchronized.
BRANCH=smaug
BUG=b:24367625
TEST=Ran cts.SingleSensorTests overnight without error.
Change-Id: Iab5e578763171411eb474e1e717167c8e1ef7ecf
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312985
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some SPI slave devices need a delay to digest write commands. (BMI160).
Add a 1ms delay in the write command.
BRANCH=smaug
BUG=none
TEST=Check on the logic analyzer that there is ~1.5ms delay between back
to back spixfer w ... commands.
Change-Id: I7cc6ed0da9ae39550e58457b9431eb01b5ab36d8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305379
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The format of the payload the handler expects is as follows:
field | size | note
================================================================
mode | 1 | 0 - decrypt, 1 - encrypt
cipher_mode | 1 | ECB = 0, CTR = 1, CBC = 2, GCM = 3
key_len | 1 | key size in bytes (16, 24 or 32)
key | key len | key to use
iv_len | 1 | either 0 or 16
iv | 0 or 16 | as defined by iv_len
text_len | 2 | size of the text to process, big endian
text | text_len | text to encrypt/decrypt
Current limitations are such that actual size of the payload should
not exceed 2036 bytes and only ECB and CTR cipher modes are supported.
If necessary, input data is padded to the closest size divisible by
16.
The response generated by the handler consists of the result of the
encrypt/decrypt operation, it is always an integer amount of 16 byte
blocks.
The test code is compiled in if CRYPTO_TEST_SETUP is defined, which it
presently is.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=Using the python utility on the host, exercised several NIST test
vectors for ECB and CTR, with key sizes of 128, 192 and 256 bytes
for both AES types. Both cipher text and decryption result match
the vector values.
Change-Id: I148f286d614f0212192a95b5518cddd32935f43d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312720
Reviewed-by: Nagendra Modadugu <ngm@google.com>
In handle_interrupt(), "|= 1 << 29" will clears all status bits, not
just bit 29. Fix this to make it only clear specified status bit and
keep R/W bits intact.
BUG=None
BRANCH=None
TEST=Verified on Kunimitus system
1. In configure_controller() write R/W bits in completion register
2. In handle_interrupt() print the value of completion register and
status bits is cleared, R/W bits are kept.
Change-Id: I6a9cc17b3dfc1e163af5e56a80600afb8ac23247
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/312701
Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
To ease finer calculation of ec rate change units from
ms to us.
BRANCH=smaug
BUG=b:24367625
TEST=compile
Change-Id: I52057c8ca1b1180a64b58d1ba0af9ec53f40b026
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312984
Fix a cut and paste error: Gyro should be disabled until the AP asks for
it. It is not used in lid angle calculation.
BUG=none
BRANCH=kunimitsu
TEST=compile
Change-Id: Id70058d76382434cb83b014b1c7439234167406c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312983
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If the proximity sensor indicates there is an object very close
(<= 5cm), ignore light sensor readings.
Otherwise, when someone put their finger on the sensor, the light
sensor would most likely report dark condition and the screen brightness
will be lowered unexpectedly.
BUG=b:25573958
BRANCH=smaug
TEST=check light report does not change when proximity sensor reports
< 5cm, using androsensor apps.
Change-Id: I16db40766a71a7925e28372ebb54ae43f60a4989
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312982
Many architectures do not mind accessing unaligned data, but many do.
Defining special packed accessor structure makes sure that the
compiler takes care of generating proper code.
Decreased performance is the price paid for improved robustness.
Should the performance hit prove too high, we might have to copy keys,
vectors and data into aligned buffers before processing them.
BRANCH=none
BUG=chrome-os-partner:43025, chrome-os-partner:47524
TEST=attempts to use AES driver with unaligned data do not cause
exceptions any more.
Change-Id: I22e8e049ac74d0d1b6e455dca4430a5147b6d711
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312589
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The receive buffer needs to be able to accommodate the largest
commands. Even though the spec sets the size limit at 4096, let's keep
it at 2K for now and see if this needs to be increased.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches applied, the AES test vectors pass
through without a problem.
Change-Id: I1cd6979fdaa343f0ddfddb58c552368b3f54db95
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312588
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This code allows to send extension commands over TPM protocol, no
callbacks have been registered yet.
The same buffer is used as input and output data. The header is
stripped off before the callback is called and then re-added after
processing.
This could be used for testing, for proprietary firmware update
protocol, etc.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=none yet
Change-Id: I91f692cc6e20abe774ee4ef001be28e5af102b2a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312587
Always initialize TCPC when TCPM boots. This guarantees
that our TCPM driver is synced up with the TCPC reg values.
BUG=chrome-os-partner:47608
BRANCH=none
TEST=test on glados. reboot EC and PD MCUs independently
with and without external power.
Change-Id: I2d989e8a85ba8a72fe1a8edaef8da9c51651d240
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312951
Reviewed-by: Shawn N <shawnn@chromium.org>
The git author date usually reflects the time a CL was first pushed to
gerrit, not the time it lands to the tree. Therefore, the author date is
misleading when used as a timestamp. Use the git commit date instead.
BUG=chromium:554675
BRANCH=None
TEST=Cherry-pick CL:293345 and verify date stamp is today, not last
August.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I4fb042d7a706fbb86897b3e383b3242602af242b
Reviewed-on: https://chromium-review.googlesource.com/313022
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch introduces a facility which would allow to compile in
callbacks for arbitrary commands passed over various communication
protocols.
Typically this will be used for testing, when various test commands
are multiplexed over an existing protocol.
The callbacks are associated with 16 bit command codes. On input the
callback receives a buffer, containing the command's argument, the
size of the command argument and the maximum size of the buffer. On
output the callback stores processing result in the same buffer and
updates the size to the actual amount of returned data.
Callback descriptors are stored in a dedicated read only section which
is scanned by extension_route_command() to find a callback associated
with a certain command code.
A console channel is also being introduced to allow controlling
console output generated by extension commands handlers.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=none yet
Change-Id: I8ae16a78ca7d72176a5e7f74dd7a232078e7c06c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312586
Reviewed-by: Randall Spangler <rspangler@chromium.org>
