two port PD will keep interrupt low, and cause
EC.PDCMD task stuck with exchange status loop before
entering task-while-loop
BUG=chrome-os-partner:48232
BRANCH=lars
TEST=`make BOARD=lars -j`, OS can boot up normally
Change-Id: I493c6d02170c731af430f28abf8ade38b47aff0f
Signed-off-by: Ryan Zhang <Ryan.Zhang@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/315362
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Add 2 bytes into the TX byte count register used in
TCPC interface.
BUG=chrome-os-partner:48256
BRANCH=none
TEST=load on glados and attach zinger, make sure
PD negotiation successful.
Change-Id: Ie57d79f20def861c22f6e2e023545a65825ab3b4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315879
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previous HW didn't correctly support 20V charging. The HW has been
corrected and now there is no need to keep 20V mode disabled in FW.
BUG=chrome-os-partner:48217
BRANCH=none
TEST=Tested in the lab by jguerin@ against Samus
Change-Id: I952872affb302c7aa2ddb97466cd5ce459d2ac54
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315219
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow boards to customize both the PWM frequency / period and the
enabling of complementary output signals.
BUG=chrome-os-partner:48044
TEST=Manual with snoball w/ subsequent commit. Run `pwm <ch> 50` for
each channel, verify with `adc` that each PD output voltage is
approximately VBUCK / 2.
BRANCH=None
Change-Id: I61cbb4a5b656f41ec7cec59339f5247902256295
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315141
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rather than having various PWM module groups initialized from various
HOOK_INIT functions, group them all into a single module and initialize
them all from a common function in pwm.c.
BUG=chromium:563708
TEST=Manual on samus / samus_pd (with CONFIG_ADC enabled). Verify that
samus fan + KB backlight control is functional and samus_pd correctly
sets PWM output.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9f9b09bfa544cd9bc6b7a867e77757dff0505941
Reviewed-on: https://chromium-review.googlesource.com/314882
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we're still in DISCONNECTED or DISCONNECTED_DEBOUNCE state, don't check
CC lines to detect a disconnect since CC polarity has not yet been
established.
BUG=chrome-os-partner:48220
BRANCH=None
TEST=Verify PD contact can be negotiated on Snoball with either polarity.
Change-Id: Iacde14446c0ff5d2170936b650f56668038f613e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315780
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
A new extended subcommand code (1) is being added to handle hash
testing.
The new subcommand handler keeps track of multiple sha1 and sha256
contexts the host might want to exercise. The number of available
contexts is limited by the amount of available free memory.
One of four hash operations could be requested by the host: 'Start',
'Continue', 'Finish' - when hashing a single stream over multiple
extended command messages, and 'Single' when the entire message to be
hashed is included in one extended command payload.
The command payload had the following format:
* field | size | note
* ===================================================================
* mode | 1 | 0 - start, 1 - cont., 2 - finish, 3 - single
* hash_mode | 1 | 0 - sha1, 1 - sha256
* handle | 1 | seassion handle, ignored in 'single' mode
* text_len | 2 | size of the text to process, big endian
* text | text_len | text to hash
As soon as the first 'Start' message is encountered, the handler tries
to allocate shared memory to keep track of the test contexts, the
amount of available memory determines how many contexts the handler
can support concurrently.
As soon as the last 'Finish' command is encountered, the handler
returns the shared memory to the 'heap'.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=after adding the host side implementation and fixing a couple of
bugs, hash tests pass (see upcoming patches).
Change-Id: Iae18552d6220d670d1c6f32294f0af1a8d0d5c90
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314692
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently the EC waits until it reads a battery status with the flag
STATUS_INITIALIZED set, but the EC does not use this flag for charging
or any other battery operation. If this flag is not set, it does not
mean that the battery is unusable, it just means that its values may not
be trustworthy.
This change will remove the check for STATUS_INITIALIZED and just check
that the battery responds. The battery response shows that the battery
is connected and can be used by the EC.
BRANCH=none
BUG=chromium:564893
TEST=see that device without STATUS_INITIALIZED set will exit
battery_wait_for_stable() without timing out.
Change-Id: I07778e8570b6d9400b61beec6b2e222984a40692
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315200
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When none of temp sensors' temp/fan speed profile is not set(zero),
thermal control will set 0% duty over initial fan speed setting.
This patch allows fan under EC control at inital max speed
till host's DPTF sets proper fan speed.
BRANCH=master
BUG=none
TEST=1. check if fan is running at max speed until ChromeOS UI comes up.
2. check if fan is running when system is in recovery mode.
Change-Id: I1b3e69b003ba1045779e263b25ac35b103fe457e
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314363
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Stack space is pretty tight on cr50, and since there is no need to
support SHA digest sizes in excess of 256 bits, the digest buffer size
should be reduced.
This patch makes the maximum expected digest size dependent on the set
of configured hash algorithms, moves hash size related asserts from
run time to compile time, and passes compile time definition to the
TPM2 library to increase its hash state container (it became too small
when SHA384 was disabled).
The sw context requirements should be reduced, but this is a task for
another day. We also do not have to store a local digest copy if the
API allowed reading a partial digest.
CQ-DEPEND=CL:314883
BRANCH=none
BUG=chrome-os-partner:43025, chromium:564862
TEST=all tests pass:
$ ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
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
SUCCESS: sha1:single 0
SUCCESS: sha256:single 0
/New max timeout: 1 s
SUCCESS: sha256:finish 1
SUCCESS: sha1:finish 3
SUCCESS: sha256:finish 2
Change-Id: Iaef3a230469de129e72418814e1d113b447c0137
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314695
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Set alternative pin from GPIO to CLKRUN if SERIRQ is under quiet mode
Once we need LCLK, CLKRUN will pull low automatically.
Modified drivers:
1. lpc.c.: enable CLKRUN functionality for SERIRQ no matter continuous or
quiet mode.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I58b11340833b26bc64bfe499272fd3b319b33202
Signed-off-by: CHLin <chlin56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/314971
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The new module generates hash test extension subcommands, driven by
the 'test_inputs' table.
Each table entry is a tuple, including the test name and the data to
be hashed. The test name determines the hash type (sha1 or sha256) and
the test mode (single or spread over several messages). The last
element of the name is the context number (ignored in single message
mode).
The hash extended command payload looks as follows:
field | size | note
===================================================================
hash_cmd | 1 | 0 - start, 1 - cont., 2 - finish, 4 - single
hash_mode | 1 | 0 - sha1, 1 - sha256
handle | 1 | session handle, ignored in 'single' mode
text_len | 2 | size of the text to process, big endian
text | text_len | text to hash
BRANCH=none
BUG=chrome-os-partner:43025
TEST=currently failing, a couple of hash code tweaks needed, see
upcoming patches.
Change-Id: Ie992bf01cae3c5278110357b482370b2fc11c70f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314693
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a no-op change moving some common code out of tpmtest.py,
preparing it to support different testing modes.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the AES test still succeeds:
$ test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
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
Change-Id: Ia6e0e3e89f99875297da0a4f6137de5901c8ca08
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314691
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If pulled up the backlight will be at 100% brightness instead of off.
BUG=chrome-os-partner:48130
BRANCH=none
TEST=hibernate on chell, see keyboard backlight stay off
Change-Id: I30cd289b9492356407aa54e6a84b04add647bd9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314936
Reviewed-by: Shawn N <shawnn@chromium.org>
The extended command code is fixed, there is no need to pass it as a
parameter when calling functions wrapping and unwrapping extended
commands.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=AES tests still pass:
$ ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
SUCCESS: AES:ECB common
SUCCESS: AES:ECB128 1
SUCCESS: AES:ECB192 1
SUCCESS: AES:ECB256 1
SUCCESS: AES:ECB256 2
SUCCESS: AES:CTR128I 1
-New max timeout: 1 s
SUCCESS: AES:CTR256I 1
Change-Id: Ic0c9d7983755de8380b57e841891fd638ef2c62a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314690
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Stack of PDCMD task may be overflow during plug/unplug stree test
with Apple's AV Multiport Adapter. Enlarge the stack size to avoid
system reboot.
BUG=chrome-os-partner:47728
BRANCH=none
TEST=Manual
1.Connect DUT to sink monitor via HDMI dongle.
2.Unplug HDMI USB from DUT side.
3.Plug HDMI USB cable to DUT USB socket.
4.Repeat (Plug and unplug) USB from DUT for 10 times.
Change-Id: Ib6a1fbd0a552b2c6d4656c12554e1306c21adb8a
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/315020
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This just replaces a few manually created macros in
chip/g/registers.h with a more programmatic version based on
names in chip/g/hw_regdefs.h.
BUG=chrome-os-partner:34893
BRANCH=none
TEST=make buildall; run it
No new functionality, just refactoring.
Change-Id: I73ee2ee1ee3f53a0939000822c552deace46f154
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314937
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
Use some meaningful macro names instead of just raw numbers when
selecting the correct USB phy port. Also we only need to do this
once, since it should be sticky through anything short of a
complete power down.
BUG=chrome-os-partner:34893
BRANCH=none
TEST=make buildall; run it
No new functionality, just refactoring.
Change-Id: If6ea2b9d9a62bf6ce4adaed1c5aac1f66013ebeb
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314938
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
When Link Time Optimization is turned on, functions that set
task_waiting multiple times have one of the sets removed
by the linker leading to undesired results.
Marking task_waiting volatile alleviates this issue.
BUG=chrome-os-partner:46063
TEST=Manually tested on Kunimitsu.
Console command adc shows correct value of approx
20000 mV for VBUS.
BRANCH=none
Change-Id: I85a6e5c9688ae72c45d90fb58296f94b74a301aa
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314233
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
From the "Device Class Definition for Human Interface Devices" spec:
When a Get_Descriptor(Configuration) request is issued, it
returns the Configuration descriptor, all Interface
descriptors, all Endpoint descriptors, and the HID descriptor
for each interface. It shall not return the String descriptor,
HID Report descriptor or any of the optional HID class
descriptors. The HID descriptor shall be interleaved between
the Interface and Endpoint descriptors for HID Interfaces. That
is, the order shall be:
Configuration descriptor
Interface descriptor (specifying HID Class)
HID descriptor (associated with above Interface)
Endpoint descriptor (for HID Interrupt In Endpoint)
Optional Endpoint descriptor (for HID Interrupt Out Endpoint)
This makes that happen.
BUG=chrome-os-partner:34893
BRANCH=none
TEST=manual
"make buildall" works, this image seems to work on the Cr50.
Also, before this CL, I see this:
0x00060f5c 0x00000000 .rodata g NOTYPE __usb_desc
0x00060f5c 0x00000009 .rodata g OBJECT usb_desc_conf
0x00060f65 0x00000009 .rodata g OBJECT usb_desc_iface0_0iface
0x00060f6e 0x00000007 .rodata g OBJECT usb_desc_iface0_1ep0
0x00060f75 0x00000007 .rodata g OBJECT usb_desc_iface0_1ep1
0x00060f7c 0x00000009 .rodata g OBJECT usb_desc_iface1_0iface
0x00060f85 0x00000007 .rodata g OBJECT usb_desc_iface1_1ep81
0x00060f8c 0x00000009 .rodata g OBJECT usb_desc_iface1_2hid
0x00060f95 0x00000000 .rodata g NOTYPE __usb_desc_end
and after, this:
0x00060f5c 0x00000000 .rodata g NOTYPE __usb_desc
0x00060f5c 0x00000009 .rodata g OBJECT usb_desc_conf
0x00060f65 0x00000009 .rodata g OBJECT usb_desc_iface0_0iface
0x00060f6e 0x00000007 .rodata g OBJECT usb_desc_iface0_2ep0
0x00060f75 0x00000007 .rodata g OBJECT usb_desc_iface0_2ep1
0x00060f7c 0x00000009 .rodata g OBJECT usb_desc_iface1_0iface
0x00060f85 0x00000009 .rodata g OBJECT usb_desc_iface1_1hid
0x00060f8e 0x00000007 .rodata g OBJECT usb_desc_iface1_2ep81
0x00060f95 0x00000000 .rodata g NOTYPE __usb_desc_end
The HID descriptor comes before the endpoint.
Change-Id: I8035a4cc884d8bb900bc1eb25fd3e4e9aba05bf8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314832
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
refer to commit 75f740fa, enabling the option on oak too.
BUG=none
BRANCH=none
TEST=plug in CDP, SDP, DCP, type-C, and PD charger. Make sure
we ramp to a reasonable value for the correct suppliers.
Make sure we don't ramp for type-C and PD chargers.
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Change-Id: I9c6a0726e9cb23af59d5841c63a81897ae624998
Reviewed-on: https://chromium-review.googlesource.com/314436
Reviewed-by: Alec Berg <alecaberg@chromium.org>
It is possible for the ALS state machine and the chip to not
agree: The EC thinks the device is busy making a measurement,
while the chip is waiting for the IRQ status register to be written.
It is not clear how it happened, an IRQ must have been lost.
Reinitiliazed the chip is stuck for 10s.
BRANCH=smaug
BUG=chrome-os-partner:45627
TEST=With an extra patch that force the IRQ handler to not do anything
every 100th, check the device recovers.
Use andro sensor to monitor light/proximity outputs.
Change-Id: I80d50bf92af127f85f82dc5c0ae318d4cfe06812
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313668
Add i2cscan and kbpress commands for FAFT.
Remove unnecessary i2c reading since there is no race condition.
Bugs fixed:
Fixed i2c_read_string bug since we shouldn't enable NACK if flag doesn't
contain I2C_XFER_STOP.
Fixed i2c_unwedge bug since the parameter should be port not controller.
Fixed state machine bug since we should restore bus state back to idle
if bus encountered timeout.
Modified drivers:
1. board.h: Add i2cscan and kbpress commands for FAFT.
2. i2c.c: Remove unnecessary reading since there is no race condition.
3. i2c.c: Fixed i2c_read_string and i2c_unwedge bugs.
4. i2c.c: Restore to idle state if bus encountered timeout.
5. board.h: Add CONFIG_LOW_POWER_IDLE for better power consumption.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I98974f852cbbaec270c697feb8016b52550005bc
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/313393
Reviewed-by: Randall Spangler <rspangler@chromium.org>
cl/301134 has a bug. If the AP wants a forced sensor (i.e. light) at
100Hz but a sampling frequency at 1s, we would still wake it up every
.1s instead of 1s.
Take in account force mode only when calculating the sampling frequency
not the interrupt interval.
BRANCH=smaug
BUG=b:25425420
TEST=Check the device goes to suspend even with 40Hz light sampling
rate:
echo 0 > /sys/bus/iio/devices/iio:device0/frequency
echo 40000 > /sys/bus/iio/devices/iio:device3/frequency
echo mem >/sys/power/state
Before it would resume just after suspend/while suspending.
Change-Id: Ie4fe36268cb1b04bc8f01ec885af84fad9e8b282
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314315
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If proximity overflow (daylight), we would still assume the data was valid
and consider there is an object very very close.
That would prevent the light to be measured. (cl/312982)
Leave the value as max range for the HAL to handle.
BRANCH=smaug
BUG=b:25573958
TEST=Check in daylight that light is still measured
Change-Id: I684e6f4a9aecd3fd6b338a9939f7ede26752ecb8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314921
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We support two FPGA images with the same firmware. To meet
timing, one image has support for USB but at the cost of reducing
the crypto multiplier to 8x8. The other image has full crypto but
no USB support.
This change displays the FPGA configuration at boot, in addition
to the FPGA image version.
BUG=b:25350751
BRANCH=none
TEST=make buildall, manual
Boot it and watch the console. You should see something like
this:
cr50 bootloader, 20151118_73026@80895, +USB, 8x8 crypto
Valid image found at 0x00044000, jumping
Change-Id: I0e5de453fcd1714fcbb170bf4364747b1e7ba894
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314824
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When sensor_shutdown() is called, the sensors may already been powered
off, or will be soon.
In that case, do not attempts to access them.
Check their state before setting range or disabling activities.
BRANCH=smaug
BUG=chromium:557966
TEST=compile
Change-Id: I60640b120a23f9aab393a93c4c67ef17222ced4e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314382
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Since two port may cause some unexpected problem in a
one port board.
I've cloned this from glados_pd without any code changes
and I'll remove the second port settings at another CL.
BUG=None
BRANCH=lars
TEST=`make BOARD=lars_pd -j`
Change-Id: I84b3d2fa705ff089aabd52ab71d9fb59eecdd027
Signed-off-by: Ryan Zhang <Ryan.Zhang@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/314637
Reviewed-by: Shawn N <shawnn@chromium.org>
Depending on timing, additional important messages may reside on our RX
FIFO at the time we process GoodCRC. Therefore, rather than flushing the
RX FIFO, simply read and discard the GoodCRC message.
BUG=chrome-os-partner:314492
BRANCH=None
TEST=Manual on Snoball with subsequent PWM changes. Verify PD contact
can be established with samus.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I4f4fab1bc318d1bce1effffad9a792c5b4a43761
Reviewed-on: https://chromium-review.googlesource.com/314871
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Send power change event to AP whenever input power is changed,
ensure that AP gets the latest power charging info.
BUG=chrome-os-partner:47677
BRANCH=none
TEST=tested on Oak by plug/unplug AC adapter to type-C ports and
verifying the UI battery icon shows the correct status instantly.
Change-Id: I7465afcd8bc9b1c56ecf70fc74446866a8ab1b9a
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/313926
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we're doing a read transaction without a write and asked to send a
start condition, assume that the slave has already been addressed and
make a repeated start.
BUG=chromium:561143
TEST=Verify "ectool i2cxfer 1 0x25 1 2" succeeds on glados
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic60a5c0f0fa32d5541b3cc6dce48cac28f26cd06
Reviewed-on: https://chromium-review.googlesource.com/314313
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a hard timeout to wait_for_interrupt() so that we won't wait
forever, even if we get into a state where interrupts fire yet our
status is not as expected.
BUG=chromium:561143
TEST=Verify "ectool i2cxfer 1 0x25 1 2" doesn't watchdog on glados
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I39773370bb7e45a8f0c0cdb4a463904643f72587
Reviewed-on: https://chromium-review.googlesource.com/314253
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On mutex contention, call task_wait_event_mask(), which will wait for
a mutex event without clearing other pending events.
BUG=chrome-os-partner:47918,chromium:435611,chromium:435612
BRANCH=None
TEST=Manual on snoball. Verify samus can successfully negotiate PD power
contract when attached to snoball.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I85cd32f2670246da9e4787025390aba2c93f9c36
Reviewed-on: https://chromium-review.googlesource.com/314492
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The EC-3PO console and interpreter could be used to talk to EC images
which do not have the necessary changes to support the new enhancements.
If this was the case, the interpreter would be very confused and the
user wouldn't be able to use the console. This commit adds
compatibility support for talking to both non-enhanced and enhanced EC
images.
When the console and interpreter are instantiated, they assume by
default that the EC image they are talking to is non-enhanced. When the
user presses the carriage return key, the console initiates an
interrogation with the EC image. The interrogation is a simple
EC_SYN(0xEC) and waits EC_INTERROGATION_TIMEOUT for the correct
EC_ACK(0xC0). Enhanced EC images will try to reply immediately to a
EC_SYN. Non-enhanced EC images will just ignore the EC_SYN as it's not a
printable character. Once the interrogation is complete, the console
will either simply pass everything forwards to the EC or provide the
console interface itself.
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Enabled CONFIG_EXPERIMENTAL_CONSOLE on GLaDOS. Entered some
commands and verified console was working. Disabled
CONFIG_EXPERIMENTAL_CONSOLE on GLaDOS, reflashed, and verified console
was still working without restarting the EC-3PO console.
TEST=./util/ec3po/console_unittest.py -b
TEST=./util/ec3po/interpreter_unittest.py -b
TEST=cros lint --debug util/ec3po/console.py
TEST=cros lint --debug util/ec3po/console_unittest.py
TEST=cros lint --debug util/ec3po/interpreter.py
TEST=cros lint --debug util/ec3po/interpreter_unittest.py
Change-Id: I4f472afbdd7e898bee308c239b68ace0f4049842
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/313002
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
