Create new custom VDM to notify DUT to enter case closed
debugging mode. Send this VDM from Plankton when the case
closed debugging enable button is pressed. Once DUT
receives the CCD enable VDM, CCD remains enabled until
a reboot. Note, this is polarity dependent, so cable
might need to be flipped.
BUG=chrome-os-partner:42569
BRANCH=smaug
TEST=load on plankton and ryu. attach full feature C to C
cable (must have USB3.0 wires). make sure plankton is in
USB mode (USB_SS_USB_MODE light should be set, which can be
done by pressing DP_USB_TOGGLE button). Press CASE_CLOSE_EN
button to send VDM, and then attach micro-B to debug port
CN14 on plankton. See that VID/PID for Ryu show up in lsusb
on host, and EC console works. If device does not show up,
flip polarity of cable.
Change-Id: Ifa469e4a43e32089becd75fe6cdfe0ed462d950b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/287441
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add ability for Plankton to detect whether a single or double
CC cable is used to connect to DUT. This is done by toggling
the active CC line until a connection is detected, then toggling
once more and checking if we still have a connection. If we
can connect to the DUT in both CC polarities, then it is a
double CC cable. Before we know the cable type, keep PD
communication disabled to avoid partially negotiating and then
disconnecting. Note, this increases the time it takes for
us to connect a form a stable PD contract with the DUT.
When we detect a double CC cable, the cable flip button actually
flips the active CC polarity, thus testing all pins in the
opposite polarity.
BUG=chrome-os-partner:42569
BRANCH=smaug
TEST=test with plankton and samus. test that we form a PD
contract with both single and double CC cables as both sink
and source. also test the cable flip button for both cables.
Change-Id: I522369302848d4cdbb70c55a40af3ad0b7c3fb8a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286589
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This unifies all the EC header files to use __CROS_EC_FILENAME_H
as the include guard. Well, except for test/ util/ and extra/
which use __TEST_ __UTIL_ and __EXTRA_ prefixes respectively.
BUG=chromium:496895
BRANCH=none
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Iea71b3a08bdec94a11239de810a2b2e152b15029
Reviewed-on: https://chromium-review.googlesource.com/278121
Reviewed-by: Randall Spangler <rspangler@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>
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>
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>
If we are switching from DP mode to USB mode, reset the USB hub to make
sure the hub recognizes USB connection properly. Note that we only reset
the hub when making the switch by pressing the button on the board. This
is to prevent disrupting BFT test flow, during which we don't want to
reset the hub so as to maintain the USB link between the test host and
Plankton MCU.
BRANCH=None
BUG=chrome-os-partner:34296
TEST=Press the button to toggle between DP and USB mode. Measure USB hub
reset signal with a scope.
Change-Id: I69bdee292fe414abbe0a4778b8f5e8041e4534c1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237606
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
When a DP cable is attached, if we toggle the USB/DP mux to USB mode,
the DP data link is broken. In this case, we should send a HPD event to
notify the host. Similarily, when we switch back to DP mode when a cable
is attached, we should send a HPD attachment event and then a HPD IRQ to
notify the host that the DP link is ready.
BRANCH=None
BUG=chrome-os-partner:34296
TEST=Connect Plankton to Samus. Perform the following tests:
1. Attach a cable, and switch between USB and DP mode.
2. Attach a cable in DP mode, switch to USB mode, unplug the
cable, and then switch back to DP mode.
3. Similar to 2 but start without the cable.
Change-Id: I5db0c036ce45850b2f4ca142957f4a235673df6f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237604
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
HPD needs to be transported over USB PD as both SBU lines are consumed
for differential AUX signalling.
This CL does the following:
1. Enables GPIO DPSRC_HPD as interrupt.
2. Sends debounced HPD across CC via the SVDM DP status message.
3. Adds polling for GPIO_DBG_20V_TO_DUT_L as it shares the same
interrupt as DPSRC_HPD.
4. Configures DP redriver in presence of HPD high.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33132,chrome-os-partner:33761
TEST=manual,
1. Connect samus -> plankton via type-C
2. Connect plankton -> DP monitor via displayport
See initial SVDM discovery on samus console
See EDID information
See SVDM status message correct when plug/unplug DP cable from plankton
3. Press 'CHARGING_20V_TO_DUT_L' button and see below on plankton console.
Button 8 = 0
Change-Id: Id95567a3bfa073ffa2c699335be8c5bf0327675f
Reviewed-on: https://chromium-review.googlesource.com/229429
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit, '0016de8 - plankton: Initialize re-driver', didn't account for
the state of the redriver at the time it was being initialized in
manual training mode. This led to inconsitencies of manual training
configuration.
This CL resets the SN75DP130 via software to guarantee configuration
regardless of cold versus warm boot.
Additionally I learned that manual training requires setting of both
the link_bw_set (5.4gbps) and lane_count_set (4) in order make the
back side of the redriver happy. This can ONLY be done however in the
presence of HPD high. Future CL will incorporate this DPCD init into
HDP interrupt handler as well.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:35153
TEST=manual,
samus + plankton successfully drives Samsung U28D590 from cold or warm
boot of either plankton or samus in both polarities. Note DisplayPort
cable must be connected to external monitor prior to power on or reset.
macbook (2015 type-C) + plankton also works.
Change-Id: I8b34341d10f64abfa55c18f70c842a4446f36fa8
Reviewed-on: https://chromium-review.googlesource.com/266526
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Host's single lane training algorithm in kernel (intel_dp_is_reversed)
appears to confuse the re-driver's auto training algorithm. If
however its manually configured the algorithm succeeds.
NOTE, this does present risk on the DPsrc (re-driver) to DPsink
(external monitor) side as voltage levels & pre-emphasis will NOT be
adjusted.
This may be acceptable in the short-term while determining if
additional functionality needs to be added on host side to account for
re-driver's presence
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:35153
TEST=manual, plankton drives 4K monitor in both polarities
Change-Id: I83ea80c44d36ad1afad56528c80ec5b8a138b5be
Reviewed-on: https://chromium-review.googlesource.com/263138
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Treat externally powered dualrole devices as dedicated chargers.
This allows us to default to consuming power from externally powered
dualrole devices and cancels a charger override when one is attached.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=tested with third-party dualrole device that can be externally
powered.
also tested with another samus that was hard-coded with externally
powered bit set, and deleted it's policy for power swapping. when
this externally-powered samus is plugged into a samus running this CL,
we always charge from the externally-powered samus.
Change-Id: I850eba668e86d311d9353aa3881fc3a518409630
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263331
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Refactoring effort to unify the set of PD intialization tasks that
need to occur. Those areas include:
1. host mode as it relates to power & pull-ups/downs
2. PD tx init
3. PD mux settings
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. compiles and functions on samus_pd
2. If sysjump w/ dongle connected than alternate mode re-entered
properly including muxing and HPD
Change-Id: I47f32acaeccbd7745e1e01a8b085b1804c4c5000
Reviewed-on: https://chromium-review.googlesource.com/249273
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
VCONN should be off at the start of pd task. This is handled
initially by the defaults in gpio.inc. However in the case of a
sysjump after a RW only firmware update the previous state would be
preserved.
This in turn would allow us to evaluate polarity incorrectly if an
accessory was connected in the CC2 polarity and subsequently enable
both VCONNs which would leave the port with both CCx lines at 3.3V.
This change adds a new function, pd_config_init, which initializes
VCONN(s) to off. Future CLs will evaluate other PD related GPIOs that
may be left unitialized as a result of sysjump.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. Boot samus w/ samus_pd in RO
2. connect hoho | dingdong in CC2 polarity to type-C port
3. sysjump to RW
4. unplug / plug hoho | dingdongs
No longer see both VCONNs enabled.
Change-Id: Ia53c06ea8face4da6829f9667f4f44a9034183be
Reviewed-on: https://chromium-review.googlesource.com/248831
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
This includes:
- Enabling SBU path for debug USB usage in USB mode (not in DP mode)
- Add a console command to enable DFU mode for lab devices. This
requires the additional Silego chip on the device.
BRANCH=None
BUG=None
TEST=Hook up a Ryu with the additional Silego chip. Issue 'dfu' command
and see DFU device in 'lsusb' output. Issue the command again and the
device goes away.
Change-Id: I3f942c6abe52784351f2242c9b0b6400e9b2b6fd
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247350
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Separate macros for defining delays to turn on and off VBUS on the
Raiden ports.
Tune the delays for Samus to provide extra headroom based off of
measured worst case times.
BUG=chrome-os-partner:34525
BRANCH=samus
TEST=load onto samus. connect two samus' and use twinkie to analyze
time between request and PS_RDY on connect and then on a power swap.
Change-Id: I65cec911e34c22a4aad136423362a3a65bc2ab2a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241761
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Do not request a voltage that is within the deadband where we
aren't sure if the boost or the boost bypass is on.
BUG=chrome-os-partner:34938
BRANCH=samus
TEST=test on samus with zinger. change the deadband to [10V, 20V]
and see that we only negotiate to 5V. change the deadband to
[13V, 20V] and see that we negotiate to 12V. change the deadband
to [10V, 13V] and see that we negotiate to 20V.
Change-Id: Id761aef35eeadfa2ab7d2ca31a48d4324625ab32
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241528
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For samus, on PD connection or on resume to S0, if we are a sink,
and the other side supports PR_SWAP, then attempt a power swap.
This adds callback functions into board policy file to check
and issue power or data swaps if required by the product.
BUG=chrome-os-partner:31195
BRANCH=samus
TEST=connect samus to zinger and make sure zinger always ends up
as SRC-UFP.
connect samus to samus with both in S0 and see that
they swap power roles once and not data roles.
connect one samus in S0 to one samus in S5 and see that the one
in S5 is sink. then when you boot the one in S5 it switches to a
source.
connect samus to samus with both in S0. do chgoverride 1 on one
side to start charging from the other samus. then on the same
side, turn off the machine (S5) and resume (S0), and see that it
is still charging from the other samus (ie has not switched roles
to source).
Change-Id: Ifab2465fccef77448ac4771a3c2de1c867cbbec4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238302
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For factory testing, we need a way to simulate unplugging type-C cable.
To do so, we disable VBUS output and pull-up/pull-down on CC lines on
Plankton, so that the CC lines become floating.
BRANCH=None
BUG=chrome-os-partner:32163
TEST=Connect Plankton to Ryu. Try 'fake_disconnect' as SRC/SNK.
Change-Id: I73a7355e078b6aed4b7d281d480e0aedbc8c2db0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229662
Reviewed-by: Pin-chih Lin <johnylin@chromium.org>
Tested-by: Pin-chih Lin <johnylin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove common code across all PD policy layers to select the requested
voltage and build a Request Data Object (RDO).
BUG=none
BRANCH=samus
TEST=Load onto samus and connect zinger. Make sure we request the right
voltage (first 5V, then after initial contract is made, 20V). Make
sure input current limit is set appropriately by checking limit on EC
console using charger command.
Change-Id: Ic6bda5e23b2d7b7d710ffdf085e7fbc1b0c3add9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233673
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Remove dualrole power capable flag from source/sink cap packets
so that samus/ryu default to drawing power from plankton.
BUG=none
BRANCH=samus
TEST=load on plankton. select 20V to DUT, attach samus or ryu
and see that it charges
Change-Id: I3d31b14f65ee8dfa4d817d47598c505b0f6d7479
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231342
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Ensure that the PD source changes the output voltage after
tSnkTransition delay after having sent the ACCEPT message
(rather than before).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33684
TEST=connect Zinger to a PD power sink and monitor VBUS and CC while
doing a 20V to 5V transition.
Change-Id: If86f59eec67630491f4e8dc13a52015ac2de918a
Reviewed-on: https://chromium-review.googlesource.com/230805
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
If USB hub is connected to the type-C port, we need to reset the hub
whenever a cable plugs in. Otherwise, USB3.0 may fail to enumerate.
BRANCH=None
BUG=None
TEST=Plug/unplug cable and measure hub reset signal.
Change-Id: I60f67c83653d532971ee156914fe6ae0ecdb8d3a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229490
Reviewed-by: Pin-chih Lin <johnylin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow policy layer to request a PR or DR swap upon formation of
a power contract. Zinger always asks for a data swap so it can
be a UFP, and Samus asks for a data swap only if it is a UFP to
become a DFP.
BUG=chrome-os-partner:33754, chrome-os-partner:31195
BRANCH=samus
TEST=load onto samus and zinger and make sure they swap roles
upon connect with no collisions
Change-Id: I275c9669549c26f25c58f80845daad8edab11313
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229327
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add support for DR_swap, data role swap command.
BUG=chrome-os-partner:33686, chrome-os-partner:28343
BRANCH=samus
TEST=test with samus and zinger. use "pd 1 swap data" command
and verify data role swaps by using twinkie and "pd 1 state".
Change-Id: I410309199cdeecb26847a6bf217523fdfe688cba
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229192
For request message, add the operational and max current for each
board. If the requested power is less than the operational power
required, then set mismatch bit.
BUG=none
BRANCH=samus
TEST=make buildall. load onto samus, plug in zinger and see
that request 20V, operational current 3000mA and max
current of 3000mA.
Change-Id: I4df45d88b7e060f66ff5b806f6fe30803f1afcf7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227393
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Update GPIOs to reflect changes in Plankton v3. The default values are
set so that case closed debugging is disabled. Also, rename CABLE_FLIP
to MUX_FLIP to match the schematic. (Plus that MUX_FLIP is a more
suitable name for what it does.)
This change be functionally compatible with Plankton v2, except that the
change on PA7 causes a 0.33mA leakage current on Plankton v2, which
should not be a problem.
BRANCH=None
BUG=None
TEST=Compile only
Change-Id: I50c56a1c583015d3624ec9f5901ed477d07233f4
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/227980
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Remove redundant 5V source PDOs in source cap packet. We only
need one 5V advertisement with the maximum current that we can
provide.
BUG=none
BRANCH=samus
TEST=make buildall
Change-Id: I94a01813787eb92fafbf600dcbbc8a2f0aa69e2b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227392
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Add support for PR_SWAP command as per PD specification.
BUG=chrome-os-partner:28343
BRANCH=samus
TEST=test by connecting two samus' and running 'pd 1 swap power'
from console. verified that both sides switch power roles by
observing console output. also tested against third party
devices.
Change-Id: I0e8738b544de9f9a4348250630e67d0fefb4486d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Update source and sink capacity tables for all PD boards. As
per spec, the first entry in both tables must be a fixed power
supply PDO. Added dual-role capable bit to fixed PDOs and added
new state variable to keep track of that information for each
port. This will be used to make decisions in charge manager and
to pass up via host commands.
BUG=chrome-os-partner:28869
BRANCH=samus
TEST=make buildall. use "pd 1 status" to check
if part partner is dual-role capable and check zinger is not,
C to A receptable adapter is not, and another samus is.
Change-Id: I49f034a372bc145cd524577c17ca210eec4c1013
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227170
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
We updated the source PDO indices and we also need to update the output
voltage selection function.
BRANCH=None
BUG=chrome-os-partner:33133
TEST=On Plankton, output 5V and measure with INA.
Change-Id: I771c04cf929a8e473cf09ae3eb222518f042600a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225154
Reviewed-by: Pin-chih Lin <johnylin@chromium.org>
Integrate charge_manager and include several API changes designed
for reporting voltage.
1. Make pd_choose_voltage set the chosen voltage for use by caller.
2. Add voltage parameter to pd_set_input_current.
3. Add pd_get_role to grab the sync / source state of a port.
4. Add charge manager PD + type C port initialization to the pd
state machine.
BUG=chrome-os-partner:32003
TEST=Manual on samus. Insert Apple charger, verify charge limit is
selected appropriately. Insert PD charger, verify that charge port
switches to PD port. Remove + reinsert chargers, verify that port /
limit is selected appropriately. Remove battery, insert power source, verify
that our power source port never becomes disabled.
BRANCH=samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idf3198c71d2ddf1e401e766fc82a4b7a02aed068
Reviewed-on: https://chromium-review.googlesource.com/223758
Reviewed-by: Alec Berg <alecaberg@chromium.org>
All non-interactive console prints should use their tasks channel
parameter to make it easy for developers to inhibit console output.
This CL corrects printf's in the various usb_pd_policy files that
belong to the USB PD task to use cprintf(CC_USBPD, ...) instead of the
macro reserved for interactive console commands ccprintf.
BRANCH=none
BUG=none
TEST=manual, set 'chan 1' and see none of the previous chatter
relating to USB PD. set 'chan 0x08000000' and see it return.
Output from DFP side for SVDM discovery now looks:
SVDM/4 [1] ff008041 340018d1 00000000 11000008
[1119.966911 DONE]
SVDM/2 [2] ff008042 ff010000
[1119.970135 DONE]
SVDM/2 [3] ff018043 00100081
[1119.973437 DONE]
SVDM/1 [4] ff018184
Change-Id: I47e5f4ec2d4a6a25f171177ead5ebc99409f80b6
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224191
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
So far, we always use channel 1 of the Tx timer and the configuration
code is hard coded. We need to support other channels for new Ryu
boards. Let's make this a configurable bit.
BRANCH=samus
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Plug in Zinger to Ryu and see 20V come up.
Change-Id: Id08d4eb0d6a5721d8a03672484d0892a0714383b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223836
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The register format of INA231 and INA219 are very much alike. In our
use case, we only need to use different coversion coefficient.
BRANCH=None
BUG=chrome-os-partner:32764
TEST='ina 0' on Plankton V2.
TEST=Build twinkie.
Change-Id: I9c8e21e30ed844566793dcc1221f865400c3d90d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223370
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When the cable flip button is pressed, instead of only flipping on
Plankton side, we should also signal the port partner to flip. This is
done by sending a custom VDM. Upon receiving the flip VDM, the port
partner is responsible of flipping the DP/USB polarity.
Note that the "flip" here only affects the superspeed lanes. The CC
lines polarity is not changed. We need this for factory test automation,
and this "flip" function should only be used for testing purpose as it
clearly violates the USB PD spec and it only works on devices that
accept the custom flip VDM.
BRANCH=Samus
BUG=chrome-os-partner:32163
TEST=COnnect Plankton and Ryu. Press the button on Plankton and make
sure the polarity GPIOs on Ryu are negated.
Change-Id: I7ee5ea70067de4f422a7478623fe7fe8d3724372
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223325
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The PD task is using more space in the stack and I'm seeing frequent
stack overflow on Plankton. On Samus, we already increased the stack
size. Let's also increase this on Ryu and Plankton.
BUG=None
TEST=make buildall
BRANCH=None
Change-Id: I468985303b7fd38455dd1fed9db54544581c49cf
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223368
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some platforms may need to take different actions depending on which
port is requesting a limit. Add a new port parameter to the
pd_set_input_current_limit API to accomodate this.
BUG=chrome-os-partner:32003
TEST=Manual on samus_pd. Verify zinger charges battery.
BRANCH=samus
Change-Id: I1578252c751b3a80b4da6ca68e2a958934283cbf
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222621
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When a cable is connected, set USBC_POLARITY to the right polarity. This
is done in a different way than how we do this on other boards because
we only want to control polarity automatically on cable connection.
BUG=chrome-os-partner:32163
TEST=Flip the cable, check USBC_POLARITY changes.
BRANCH=None
Change-Id: I903123b8fd729e8c913014b83812d20328600f8e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219291
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When 5v/12v/20v buttons are pressed, plankton first switchs to source
role, set the requested source cap, and then perform a soft reset.
However, if plankton was sink and just switched to source, the port
partner might not have switched to sink and this leaves the CC line in a
state where communication is not possible. The subsequent soft reset
then fails. If we are not already sourcing power, we actually don't need
a soft reset after changing source cap.
BUG=chrome-os-partner:32163
TEST=Switch from sink to source. Doesn't see "soft reset" in console.
TEST=Switch from 5V to 12V. See "soft reset".
BRANCH=None
Change-Id: Ia4b834c2e7dc1324b9143c46a72938845499e2fb
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219004
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On power-on reset, the USB hub might get stuck in a locked state due to
a race condition in hardware. Let's reset the hub after 0.5 seconds to
make sure this doesn't happen.
BUG=chrome-os-partner:32163
TEST=Power on the board. Measure the reset signal.
BRANCH=None
Change-Id: I0f89883c5db7c5376f3612da1615ba4f86b5efa6
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219199
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Fix for plankton v2 so that the VBUS voltage selection buttons
work properly (5V, 12V, and 20V).
BUG=none
BRANCH=none
TEST=load onto plankton v2, connect type-C to samus, and press
5V, 12V, and 20V buttons. read adc on samus side to verify it
is getting the proper voltage.
Change-Id: I5004675bf658834219c295292c669182af7d8393
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217258
Reviewed-by: Vic Yang <victoryang@chromium.org>
