Charger task is overflowing and causing crash.
Increased charger task stack size by 128 bytes.
Also increased console/hook by 128 bytes as these
are also close to its limit.
BRANCH=None
BUG=chrome-os-partner:40766
TEST=1.Program EC image.
2. Run various tests to verify charger stack doesn't
overflow.
Change-Id: I6e350584508fa3a47769982b1e0cf3e3aea9ded6
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/274204
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Divya Jyothi <divya.jyothi@intel.com>
Allow timeout to be set at runtime by controller.
BUG=chrome-os-partner:40780
TEST=Manual on Glados. Verify PD I2C communication is functional.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I582e47c7bebfed7a639789c90064d86ffe1a5401
Reviewed-on: https://chromium-review.googlesource.com/274967
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Clean up pd_tx_disable() so that it doesn't toggle a couple times
when we stop transmitting. Need to first set the CC pin to Hi-Z
and then the TX_DATA line since the CC pin is normally held low
during transmission.
BUG=none
BRANCH=none
TEST=test on glados. use twinkie to capture traffic and note that
without this change, the CC line toggles an extra time at the end
of each transmission. With this change it is a lot cleaner.
Change-Id: If26c7a10bbb08bc55b972bb0145115836579d37b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274884
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Copy task stack sizes from Samus. These can be tuned later if necessary.
BUG=chrome-os-partner:40790,chrome-os-partner:40677
TEST=`make buildall -j`
BRANCH=None
Change-Id: I862c55ca924879ffb08062eaf1466fd3d4a3090c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274415
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Initial support for glados PD. Charging and PD
communication only work on port 0.
BUG=none
BRANCH=none
TEST=make BOARD=glados, make BOARD=glados_pd
Connect hoho to glados and verify power contract successful.
Connect zinger to glados and verify power contract and
charging.
Change-Id: I42e7b8d154a79de2f8502648d9af7d4cfc00a266
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273138
Reviewed-by: Shawn N <shawnn@chromium.org>
Add TCPM on EC side and TCPC on PD side to allow PD
communication. Enable PD communication on port 0.
BUG=none
BRANCH=none
TEST=load on oak. plug in hoho on port 0, and make sure
we successfully negotiate a PD contract. (note: you have
to manually enable 5V VBUS right now)
Change-Id: I0ce7c016545bc56c5e10f66b49b73722187f12dc
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271829
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Commit-Queue: Sheng-liang Song <ssl@chromium.org>
Firmware's original get_info command always returns the same values
for family, chipid, irom & fw despite indeed having different
versions.
Currently its:
family:000e chipid:0001 irom:1.0.0 fw:0.0.0
As we have a new stepping of the chip ('BB') and a corresponding new
firmware (>=0.74) we need a mechanism to verify and log this change.
CL uses the newly hatched appstest command (0x12) message 0x28 to
surface information that properly reflects both hardware and firmware
running.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35939
TEST=manual,
For devices running 0.54 | 0.74 fw see gpio MCDP_READY asserted.
With CONFIG_CMD_MCDP in board/hoho/board.h see the following responses
when executing 'mcdp info'
Stepping | FW | Response
--------------------------------------------------------------------
'BA' 0.53 fails as expected
'BA' 0.54 family:0010 chipid:2850 irom:2.0.0 fw:0.54.0
'BB' 0.73 fails as expected
'BB' 0.74 family:0010 chipid:2850 irom:2.1.0 fw:0.74.0
Change-Id: I2c36393a298c617f903389dab24da631b60ec574
Reviewed-on: https://chromium-review.googlesource.com/274049
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
'muxes' refers to bus 0, port 1, not bus 0, port 0.
BUG=chrome-os-partner:40677
BRANCH=None
TEST=Manual on Glados. Run 'i2cscan', verify that bus "1" is scanned,
and devices respond with ACK.
Change-Id: I734306928a128fea5e70b37735a71a64483f4e88
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change is necessary to ensure power-up of edge-case Skylake parts.
BUG=chrome-os-partner:40677
TEST=Manual on Glados. Boot system to S0, run "i2cxfer r 4 0x60 0x38",
verify that 0x7a is read.
BRANCH=None
Change-Id: Id9e62731aaa75fb2357a05d898ba2d4d28f87d9e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274114
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change refines HPD debounce values into both upstream and downstream
values for packetizing across the type-C link.
For LVL, the upstream type-C device will packetize any HPD transition
>=2ms as either HIGH or LOW. On the downstream side the value is
driven immediately. Additional debouncing should be done by true
upstream device according to specification.
For IRQ, the upstream type-C device will packetize any HPD pulse
>250usec as an IRQ. On the downstream side it will be de-packetized
to create 750usec pulse.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:39717
TEST=samus|macbook(2015) + hoho|dingdong|apple HDMI type-C dongles
still drive screens successfully.
Change-Id: Ide58f3b2d675a82c12ca6afc2be53ca6e2561ace
Reviewed-on: https://chromium-review.googlesource.com/273867
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Always enable these signals to help debug power sequencing. We'll need
to revert this change later.
BUG=chrome-os-partner:40677
BRANCH=none
TEST=sequence to S0 on glados and stay there
Change-Id: Ia845532fe7aed71bcb42b4ca6a9bfa20aa9e3e00
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273900
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add initial support for Oak PD MCU on rev1 boards.
This does not include USB PD communication.
BUG=none
BRANCH=none
TEST=build and load on oak and get console. test we
resond to host commands from EC using "pdcmd 0 0" on
EC console.
Change-Id: I92045cf0fd682279ada6c286f5399f0e258a6305
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271828
Oak's initial commit was merged at same time with CL that changed GPIO
macros. This change fixes oak build by applying new GPIO macros.
BRANCH=none
BUG=none
TEST=make BOARD=oak -j
Change-Id: I1b60a85b83aa46c81c5dd7fea44bb221646c0cf0
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273510
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add initial support for Oak rev1 board. This is just the
EC and includes battery charging but does not include
USB PD.
BUG=none
BRANCH=none
TEST=load on oak board and get console
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I626f3921025fbc39ba22b04eeb6dd1084cd70777
Reviewed-on: https://chromium-review.googlesource.com/261678
Our existing GPIO macros use port# / gpio#, but the concept of different
GPIO ports does not exist on the mec1322. Therefore, add new GPIO macros
for chips which do not have distinct GPIO ports.
BUG=None
BRANCH=None
TEST=make buildall -j
Change-Id: Ibda97c6563ad447d16dab39ecadab43ccb25174b
Signed-off-by: Steven Jian <steven.jian@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/262841
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Move parts of usb_pd_config.h that are not part of the phy layer
out of usb_pd_config.h and into board.h. This cleans up the
division between the TCPC and TCPM as only the TCPC needs to
use usb_pd_config.h.
Also cleans up the use of the CC detection voltage thresholds
by creating standard macros to use based on Rp strength for the
board.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I946cceb38bea8233095b8a4b287102bb8a3a296d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270337
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
New led control from Yuna since it is close to CrOS UI.
BUG=chrome-os-partner:37576
BRANCH=cyan
TEST="make BOARD=cyan" and check the two factors in CrOS:
shutdown=4% and full= 97%.
Change-Id: I8aa7ae5f35a3f3f6f15c6131a1f8fb581025de2d
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/272815
Reviewed-by: Mohammed Habibulla <moch@google.com>
Previously the Producer and Consumer interfaces tracked the
Consumer and Producer respectively at the other end of the
queue that they interacted with. This was done to avoid
modifying the queue implementation, but resulted in a rougher
interface that required additional initialization steps and
prevented alternative configurations; many producers and one
consumer for example.
This commit uses the new queue policies to track this
information. The new direct policy behaves as the old producer
and consumers did. Now the producers and consumers are just
named references to the queue that they work on and a convenient
location for a notification callback when the queue is updated in
a way that is relevent to the producer or consumer.
All users of Producer and Consumer have been updated including the
stream adaptors which are in use by the echo test code and the
mcdp28x0 driver. Use of the stream adaptors has also been
simplified.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Manual testing of Ryu (P5) and discovery board echo task
Change-Id: I704be6378a31b4e20f5063295eff9943e4900409
Reviewed-on: https://chromium-review.googlesource.com/271792
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
it was not needed before, it's now harmful for the new VBUS detection
circuit on EVT2.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=on Ryu P6 reworked with the new VBUS detection circuit, probed
voltages and did "gpioget CHGR_ACOK" with type-C unplugged.
Change-Id: I1d99f249c1949aa35f98a896e7ac8ee019295e19
Reviewed-on: https://chromium-review.googlesource.com/273006
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add config options for various parts of USB PD stack:
CONFIG_USB_POWER_DELIVERY: The use of this option has changed
slightly. It now represents whether or not to include the USB
PD protocol and policy layers of the software stack.
CONFIG_USB_PD_TCPC: Compile in type-C port controller module
which performs the phy layer of the PD stack.
CONFIG_USB_PD_TCPM_STUB and CONFIG_USB_PD_TCPM_TCPCI: If
CONFIG_USB_POWER_DELIVERY is defined, then one TCPM needs to
be defined to declare which port management module to use
to drive the TCPC.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I41aa65a478e36925745cd37a6707f242c0dfbf91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270171
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The battery of cyan only support specific shipmode command.
BUG=chrome-os-partner:40464
BRANCH=cyan
TEST=verify that "ectool batterycutoff" and "ectool batterycutoff
at-shutdown" are workable.
Change-Id: I48538d57eda77ae798b3b843252df297c2d8fa81
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/272414
Reviewed-by: Mohammed Habibulla <moch@google.com>
EVT board should enable it (low) since we need a workable track pad in factory.
Pre-EVT board work fine because of unstuffed resistor.
BUG=none
BRANCH=cyan
TEST=Check the pin is low by ec console.
Change-Id: I9602534aeadca76e24915d12701b3cd4e801746a
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/272103
Reviewed-by: Shawn N <shawnn@chromium.org>
Add CONFIG_LTO to use GCC Link-Time Optimizations to try to reduce the
flash footprint of the firmware.
Add additional protection to some functions/data to avoid removal by the
linker when their usage is not obvious.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall (with and without LTO enable on all boards)
Change-Id: I586b8c1eda4592b416c85383b65153c1d5ab0059
Reviewed-on: https://chromium-review.googlesource.com/271291
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Common battery cut-off host command / console command infrastructure
already exists behind CONFIG_BATTERY_CUT_OFF, so add the config rather
duplicating the code at the board level.
BUG=chromium:488157
TEST=Manual on Squawks. Verify that both "cutoff" on the ec console and
"ectool batterycutoff" succeed to cut-off the battery.
BRANCH=None
Change-Id: I159026d54924e058ea0262db04d8770c663ee613
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271513
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The HotPlug Detect signal generated by the PD stack in DisplayPort
alternate mode is connected to a 1.8V GPIO on the T210 AP, we need to
set the GPIO output as open-drain.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=manual, probe the level with a voltmeter and see 1.8V.
Change-Id: I627befc61ed06c75dd7e32a8541bd6d8f8e95642
Reviewed-on: https://chromium-review.googlesource.com/271553
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
- Use CONFIG_*_MEM when dealing with images in program memory.
- Use CONFIG_*_STORAGE when dealing with images on storage.
- Use CONFIG_WP when dealing with the entire WP RO region.
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Manual on Cyan with subsequent commit. Verify that FMAP matches
actual layout of image. Verify flashrom succeeds flashing + verifying EC
image using host command interface.
BRANCH=None
Change-Id: Iadc02daa89fe3bf07b083ed0f7be2e60702a1867
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270269
Add Primitive support for Bosh Sensor.
Neither gesture nor FIFO are supported.
BUG=chrome-os-partner:39900
BRANCH=none
TEST=Running accelinfo.
From user space, check values via /sys/class/iio/devices/...
Change-Id: I62dbe230c9064ec7c0fa8e343bbe6eae843e3ac0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270455
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Move structure used by lms6ds0 to motion_sense.h,
so that bosh driver can use the same mechanism.
Use code to avoid reading chip range when reading data.
BUG=none
BRANCH=none
TEST=Check Bosh driver is working as expected.
Change-Id: Id8b5bb8735e479a122ef32ab9a400fba189d7488
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270453
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rename image geometry configs with a uniform naming scheme to make their
purposes more clear.
CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory
CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage
CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image
CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory
CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage
CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image
CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage
CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Set date / version strings to constants then `make buildall -j`.
Verify that each ec.bin image is identical pre- and post-change.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd
Reviewed-on: https://chromium-review.googlesource.com/270189
Reviewed-by: Anton Staaf <robotboy@chromium.org>
- allow power swap only when we are dual-role toggling (ie in S0).
- enable the VCONN swap feature to support more type-C dongles.
and allow it using the same rule as power swap.
- become a power sink when we are connected to an externally powered
DRP.
- by default, try to be a data UFP for USB.
so Dual Role Device such as laptops can get our data.
- add a message to inform the AP that our USB role has changed
(but the host events are fully wired yet on Ryu)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
Change-Id: Id0f9027b140cb20f105bcdbc00cac5cb5f44c9e0
Reviewed-on: https://chromium-review.googlesource.com/269857
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The CR50 device will have to have two different drivers, for SPI slave
and master modes. This patch adds the slave driver which is called
SPS.
CR50 SPS controller uses 2KB buffer split evenly between receive and
transmit directions as two FIFOs. RX write and TX read pointers are
maintained by hardware, RX read and TX write pointers are maintained
by software.
The FIFO area allows only 32 bit writes from the CPU core, which
complicates the function placing TX data into the FIFO. There is no
limit to read access size.
Another complication is that the hardware pointers in the FIFO in fact
have 11 bits (instead of 10 required to address 1K), so the software
needs to use 10 bits when accessing the FIFO, but 11 bits when writing
the pointers into the registers.
Driver API provides three functions:
- transmit a packet of a certain size, runs on the task context and can
exit before the entire packet is transmitted.,
- register a receive callback. The callback is running in interrupt
context. Registering the callback (re)initializes the interface.
- unregister receive callback.
A CLI command is added to help testing this driver. When invoked, it
installs the callback function to handle receive data. The data is
expected to be of the following format:
<size/256> <size%256> [<size> bytes of payload]
where size should not exceed 1098 bytes.
Received frames are saved in a buffer and once received are
transmitted back to the host.
BRANCH=none
BUG=none
TEST=used the enhanced 'spiraw' utility which sends frames of random
size in 10..1010 bytes, and then clocks the line to receive the
same amount of bytes back, syncs up in the returning stream of
bytes and compares received and transmitted data.
# run 'sps 100' on the target
$ src/examples/spiraw.py -l 100 -f 2000000
FT232H Future Technology Devices International, Ltd initialized at 2000000 hertz
$
which is an indication of the successful loop back of 100 frames.
The cli command on the target exits and reports the stats:
> sps 100
Processed 100 frames
rx count 108532, tx count 51366, tx_empty count 100, max rx batch 11
Change-Id: I62956753eb09086b5fca7504f2241605c0afe613
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269794
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The code in board/cr50 and board/cr50_a1 directories is pretty much
identical apart from a few lines related to USB. Let's consolidate the
both board variants in the same source directory.
The command to build the cr50 board remains the same. The command to
build cr50_a1 becomes
$ make BOARD=cr50 CHIP_VARIANT=cr50_a1 out=build/cr50_a1
This is a small inconvenience to pay to avoid duplicating many patches
in two subdirectories.
BRANCH=none
BUG=none
TEST='make buildall' still succeeds
compared map files for cr50_a1 before and after the change. They
are identical modulo addition of the empty function
send_hid_event() in board.o.
Change-Id: I7584c8f215945b8b33eea4eff50c872a09ef349d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269160
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Enable the support to be a USB-PD alternate mode DFP and add
configuration for the DisplayPort alternate mode and the GFU mode.
Only on Ryu P6 as the P5 board is using the HPD line for the power
sequencing workaround.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:39946 chrome-os-partner:38689
TEST=on Ryu P6, plug a Hoho dongle, see that the superspeed muxes are in
DP1 or DP2 mode (using the "typec 0" command), plug and unplug an HDMI
monitor and see the HPD line moving when typing "gpioget USBC_DP_HPD".
> pd 0 state
Port C0, Ena - Role: SRC-DFP-VC Polarity: CC1 Flags: 0x1150, State:
SRC_READY
> adc
VBUS = 4980
CC1_PD = 992
CC2_PD = 57
> typec 0
Port C0: CC1 993 mV CC2 58 mV (polarity:CC1)
Superspeed DP1
> gpioget USBC_DP_HPD
0 USBC_DP_HPD
<--- PLUG monitor --->
> gpioget USBC_DP_HPD
1* USBC_DP_HPD
Change-Id: Ie25a3bb0d6331c1d931b7f542fbc637270c20b3b
Reviewed-on: https://chromium-review.googlesource.com/269855
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
