On boot, if VBUS is present, then when PD protocol gets to
SNK_DISCOVERY state, if it times out waiting for source cap,
then send attempt to send a soft reset first instead of
directly sending a hard reset. This allows us to not lose
VBUS in the case that we were in a stable contract as a sink
before this boot (for example a sysjump or EC reboot).
BUG=chrome-os-partner:44085, chrome-os-partner:44952
BRANCH=none
TEST=test on glados and samus. test by sysjumping between
RO and RW with zinger plugged in and no battery, and verify
that we don't lose power. also test rebooting with a battery
and verify we don't lose power. also tested with a third
party PD charger.
Change-Id: Ib7ce46d8b9843db66805ba3237d8919d611324e0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308201
Reviewed-by: Rong Chang <rongchang@chromium.org>
On TCPC startup, set an alert to notify TCPM that we have been
reset. When TCPM gets this notification, it should re-send
initial TCPC parameters. If we were in a stable contract as
a sink, make sure we don't reset connection. If not, then
reset PD protocol state machine to the default state.
This fixes a bug where if the TCPC reboots while the TCPM is
still running, then the TCPC would not get re-initialized and
therefore no PD communication would not work. This also fixes
it such that if we are in a stable contract as a sink and the
TCPC reboots, then we don't lose power.
BUG=chrome-os-partner:46676
BRANCH=none
TEST=tested on glados. reboot PD MCU with and without a charger
plugged in and verify that PD communication works after the
reboot. verify that with a charger, we don't lose power.
also tested with a hoho plugged in during reboot.
Change-Id: I84fec4577b0daf5891bd8461d3f3d925014a5ecf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307187
Reviewed-by: Shawn N <shawnn@chromium.org>
Remove duplicate code for checking request message, but keep
a board specific check of the request message for custom checks
needed on zinger and plankton.
BUG=chrome-os-partner:42490
BRANCH=none
TEST=make -j buildall. run on samus and connect a hoho, make
sure we successfully negotiate a contract.
Change-Id: I7398953a158d340e3e113f5a816b55445a857711
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305374
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add more flags to EC_CMD_USB_PD_CONTROL including whether
the port partner is PD capable, and if the port partner has
any of the following flags set in its capabilities: dual-role
power, dual-role data, USB comms capable, and externally
powered.
BUG=none
BRANCH=smaug
TEST=tested on samus using 'ectool --dev=1 usbpd 0'. Tested
with zinger, guppy, another samus, and other third party
devices to verify the flags are set as advertised in src/snk
capabilities packet
Change-Id: I4d78d1880073fdacce57516111ac6cab37b93f27
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300953
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Send soft reset to all connected USB PD ports before a user
initiated reset (via console or host command). This fixes a problem
where EC will send PD hard reset to a charger after an EC reboot, which
will cause another reboot if battery is not present.
BUG=chrome-os-partner:44085
BRANCH=none
TEST=tested on glados without a battery. with zinger attached, issue
'reboot' from console and verify that we only reboot once.
Change-Id: Id6c56cda33c289e3425cb433f7fcbe76669d2dff
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295889
Reviewed-by: Shawn N <shawnn@chromium.org>
PD charger voltage + current can now be limited with
EC_CMD_EXTERNAL_POWER_LIMIT. The limit is automatically cleared when the
AP transitions out of S0 into S3 / suspend.
BUG=chrome-os-partner:43285
TEST=Manual on Samus w/ zinger.
- Plug zinger, verify charging at 20V/3A.
- `ectool extpwrlimit 3000 12000 --dev=1`, verify charging at 12V/3A
- `ectool extpwrlimit 1000 5000 --dev=1`, verify charging at 5V/1A
- Plug zinger into other port, verify still charging at 5V/1A
- `powerd_dbus_suspend`, verify charging at 20V/3A
- `chglim 2000 12000`, verify charging at 12V/2A
- `ectool extpwrlimit 0xffff 0xffff --dev=1`, verify charging at 20V/3A
- `chglim 1000 20000`, verify charging at 20V/1A
- `chglim`, verify charging at 20V/3A
BRANCH=ryu
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6cd5377be91b3df75f99cb414fd3fa5a463b56cb
Reviewed-on: https://chromium-review.googlesource.com/293954
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
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>
Even a decent type-C device SHALL respond SNK_CAP query message when we are in
SRC_READY state, but in the case its mal implementation shouldn't get us being
trapped in an infinite loop of SRC_READY / SRC_GET_SNK_CAP states.
Introduce a counter to give up sending of SNK_CAP and just print a ERR
indication log when the partner device ignores SNK_CAP query.
BUG=none
BRANCH=samus
TEST=make buildall
manual testing against the failing USB-C device
Change-Id: I4c4251b2264230d7dd30bd2b9fc2b56027ff0d5a
Signed-off-by: Bernard Shyu <bernard_shyu@bizlinktech.com>
Reviewed-on: https://chromium-review.googlesource.com/284035
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
1. Added new config option CONFIG_USB_PD_TRY_SRC
2. Added pd_try_source_enable global flag with console command
3. Added bit to pd.flags to indicate Try.SRC states are active
BUG=chrome-os-partner:39724
TEST=Manual samus to samus with the Try.SRC enabled on both and just
one samus. Tested Samus to Honeybuns and Samus to Zinger connections.
BRANCH=TOT
Change-Id: Ifa5d5d82e443f376e546aaf852ff24d92ef04d72
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282052
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
DP Alternate mode specification defines two bytes in the DP
capabilities payload with respect to pin configs. One that governs
the DFP and the other the UFP. The one that the DP source needs to
examine depends upon whether the UFP is a receptacle or a plug.
Previously we just examined the DFP pin config which was correct for
all UFP plugs but not UFP receptacles. This change fixes that by
examining bit <6> of capability message to determe plug vs receptacle
and in case of receptacle choosing the UFP ping config instead.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chromium:505652
TEST=manual, hoho & apple (UFP_D plugs) still work.
While I don't have a test for UFP_D receptacle partner device reports
following for its DP caps which should now decode correctly.
<31:24> 00 Reserved/SBZ
<23:16> 1C UFP pin config == C, D, E
<15:08> 00 DFP pin config zero
<07:00> C5 <6> == 1 == receptacle
Change-Id: Ib9e3a808828ff6b8c062baf0fc3c23b3da33c2c3
Reviewed-on: https://chromium-review.googlesource.com/282621
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
In preparation for adding support for additional USB-C mux chips, add a
new high-level USB-C mux interface usb_mux.c. usb_mux functions are now
called from pd code instead of board-level functions. usb_mux calls down
into a mux chip-specific driver (currently pi3usb30532) or
board-specific drivers which toggle GPIOs (for legacy boards).
BUG=chrome-os-partner:41696
TEST=Manual on Glados in subsequent commit. Verify set() and get()
functions set and return consistent values. Verify that USB SS device
functions when muxes are set to dock or USB. Also, verify that DP
dongle and USB SS device are functional on both PD ports on samus_pd.
BRANCH=None
Change-Id: Ib6477f489310f3be1430585ea09fea26f57e3752
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/281435
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Refactor the tcpm/tcpc split such that the tcpm driver implements
the alert functionality since it may be unique for different tcpc
chips.
BUG=chrome-os-partner:41842
BRANCH=none
TEST=make -j buildall. run on samus and glados.
Change-Id: I23f2d7f8627d5337b8d001a09bf27622be24fe33
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/281631
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Updated the VDM information to handle properly the DisplayPort alternate
mode.
Switch to 2+2 (DP+USB3.0) if mode D is entered else use 4 lanes of DP
for mode C.
Set the Multi-Function Preferred bit, so laptops select the mode D.
BUG=none
BRANCH=none
TEST=Tested with samus. Verified we get 36W of power + USB2.0 key +
USB3.0 key + external DP display.
Change-Id: I95e3b3640fd5952faeb24312e387468aed6266c7
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267688
Reviewed-by: Todd Broch <tbroch@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>
When we are going to S5 with a debug accessory plugged, we cannot
transition through the 'PD_DRP_FORCE_SINK' else we would
disable/re-enable the USB muxes triggering disconnections/glitches on
the USB debug console.
So, rework the management of the dual role toggling special case
(used to detect debug accessories) : remove the special DRP state and
re-write the conditions.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:41399
TEST=on Ryu, connect to the EC console through Suzy-Q and issue
the "apshutdown" command, then see the EC USB console is randomly
disconnected/re-connected or acting up.
Change-Id: Id44a9360a836e7c10a30f5afb2971bc7c3d01a5c
Reviewed-on: https://chromium-review.googlesource.com/277275
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Move the task responsible for detection of USB chargers to common code
to reduce code duplication.
BUG=chrome-os-partner:40920
TEST=Manual on samus_pd. Plug USB charger, verify detection is correct
on both charge ports.
BRANCH=None
Change-Id: I362f8b5b51741509e459c66928131f1f6d2a3b1d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/276210
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Enable charging through debug accessory by setting input
current limit to 3A when debug accessory is detected.
Add new dual-role toggling state for stay sink unless VBUS
is detected, which allows us to detect debug accessory
when we are not normally dual-role toggling.
BUG=none
BRANCH=smaug
TEST=plug suzyQ into ryu in S0 and in S5 and make sure that
we go to the SRC_ACCESSORY state and set charger input
current limit appropriately.
Change-Id: I6262c9d6cd0ae7159f343d36e19d290c2f2e0181
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/276368
Reviewed-by: Vincent Palatin <vpalatin@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>
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>
Initial split of the USB PD protocol code to create the new port
controller (TCPC) and port management (TCPM) blocks. The intention
is that the TCPC code will eventually reside on a different MCU,
along with the USB PD phy layer. The TCPM will stay with the protocol
and policy layers and provide a standard interface to TCPC (over
i2c).
As a first step, this CL merely splits up the files and directly
calls functions to reach across between TCPM and TCPC.
BUG=none
BRANCH=none
TEST=tested on samus using zinger, hoho, another samus, donette,
and a third party PD charger. Tested the following:
- dual-role toggling
- forming a connection as a source and as a sink
- power negotiation at different voltages
- charging
- sourcing power to USB stick
- soft reset
- hard reset
- power swap
- data swap
- bist mode 2
- zinger remote firmware updates
Change-Id: I70bd68a003c81e075310913f10351b792f76d7e0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266923
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add explicit setting of USB D+/D- switch when setting the type-C
muxes. This fixes a bug in which we would open D+/D- switch when
entering DP mode and lose USB2.0 connection.
BUG=chrome-os-partner:39766
BRANCH=samus
TEST=add printf to board_set_usb_switches() on samus and make sure
we don't open the D+/D- switch when entering DP mode.
Change-Id: I2b5bb2185298794ddb4cc457f3695ce6adabd9f8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268993
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Previously samus_pd just picked pin mode E without regard to what the
UFP was requesting. This change surveys the UFP's DP pin capabilities
and then requests the appropriate pin config.
Additionally if the UFP supports multi-function and has preferred it
during the initial DP status message, samus will configure its
type-c mux in 'dock' mode.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:38728
TEST=manual,
1. hoho + samus, pin mode = 'C'
2. dingdong + samus, pin mode = 'E'.
3. apple type-C HDMI multiport + samus, pin mode = 'D' and USB device
enumerates as SuperSpeed.
4. plankton + samus w/ patch asserting alternate mode with
multi-function preferred sets config to 'F' now and only drives DP
out on 2 lanes w/ other two allowing USB key to be seen.
Change-Id: Ie4764c33f108e8a88f0052b64ddb96cb92e5a78b
Reviewed-on: https://chromium-review.googlesource.com/267796
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Samus does NOT provide any sink capabilities for DisplayPort or USB
device mode so it should NOT request UFP_U select any pin assignments
for DFP_D.
Additionally even if this functionality was provided by the DFP the
specification states, 'and one pin assignment for either the DFP_D or
UFP_D'.
This did NOT cause any functional issues but strictly speaking is a
compliance bug.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:38728
TEST=manual, hoho still successfully drives external monitor.
Change-Id: Iea3441989924dcee69fdb83299ef7e817df55683
Reviewed-on: https://chromium-review.googlesource.com/267794
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>
Cleanup PD receive error enum by including RX in name since
we will have a different enum for TX errors.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I355092e0e73a022acb4a92736374cd2289d324bf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267670
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Identify and ignore cable reset PD command
BUG=chrome-os-partner:39464
BRANCH=samus
TEST=connect two samus'. on one samus add code to send a cable
reset like such:
int send_cable_reset(int port)
{
int off;
CPRINTF("C%d Send cable reset\n", port);
/* 64-bit preamble */
off = pd_write_preamble(port);
/* Hard-Reset: 3x RST-1 + 1x RST-2 */
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC1));
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC3));
/* Ensure that we have a final edge */
off = pd_write_last_edge(port, off);
/* Transmit the packet */
if (pd_start_tx(port, pd[port].polarity, off) < 0) {
pd[port].send_error = -5;
return -5;
}
pd_tx_done(port, pd[port].polarity);
/* Keep RX monitoring on */
pd_rx_enable_monitoring(port);
return 0;
}
Without this CL, the receiving samus times out and ends
up causing equivalent of hard reset. With this CL, we receive
cable reset and drop it.
Also used twinkie to measure goodCRC delay. No measureable
change in delay on samus and zinger. Samus delay is ~70us and
zinger delay is ~65us.
Change-Id: Ic0e871c8cf96502b861f430e05ee145881fb55fa
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Support VCONN swap on samus and always accept VCONN swap when in
S0 or S3. In S5, we can't provide VCONN, so reject VCONN swap
requests.
BUG=chrome-os-partner:34978
BRANCH=samus
TEST=load on two samus' and use "pd 1 swap vconn" to swap which
side is source vconn. also run in S5 and verify swap request is
rejected.
Change-Id: I04be8d1d910a2d6c5ad8b27a790f8e33121c86ee
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264856
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When using the Twinkie dongle without a protocol decoder on the host,
add a simple text tracing mechanism, so the user can get the timestamped traces
of the packets on the wire (in a best effort fashion).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=On Twinkie command-line, type "tw trace on"
then plug a DingDong to Samus through Twinkie and
see the PD message traces on the console.
Change-Id: I4fa35d6783cc6279c95209c86f37e6d717de7301
Reviewed-on: https://chromium-review.googlesource.com/237222
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Combine source and sink data role swap states into one data
role swap state. This saves 128B of flash.
Also add DUAL_ROLE_IF_ELSE macro to clean up all the places
we check our role and need to know if we are DUAL_ROLE or not.
BUG=none
BRANCH=samus
TEST=load onto two samus' and try data swaps from both sink and
source sides and make sure they get rejected and go back to the
correct ready state. load onto zinger and make sure we successfully
data swap when connected to samus.
Change-Id: I57744593ce291e512cb254b08745115de365cab4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264855
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- Changed TX BIST mode so that it transmits for 50 msec instead
of transmitting forever.
- Added console command to initiate TX BIST mode.
- Fixed an issue with circular DMA mode which was causing watchdog.
- Modified RX BIST to account for shorter TX BIST duration.
BUG=chrome-os-partner:36335
TEST=Manual on Samus to Samus, manual on Zinger to Samus
BRANCH=Samus
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Change-Id: I666347de47c81b5b7a1e82c2b99345ff3ebbb7d4
Reviewed-on: https://chromium-review.googlesource.com/256194
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Trybot-Ready: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Create a USB PD device whitelist for allowing charging by default
from dual-role devices that don't set the externally powered bit.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=modify zinger and modify VID and PID to match white-listed
entry. also modify zinger to remove externally powered bit and
set dual-role power bits so that we treat as a dual-role device
by default. when you plug in this modified zinger into samus,
it still will not charge because the VID and PID are obtained
after deciding to treat it as dual-role, but when you issue
soft reset "pd 1 soft", it starts charging. the white-listed
device will always ask for a power swap if it is a sink, so
we will always get source cap after learning the VID/PID, which
should correctly trigger changing the device to be treated as
a dedicated charger.
Change-Id: Ibe7ec57f842a0b9bfb02447baf5b3327217a9516
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264015
Reviewed-by: Vincent Palatin <vpalatin@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>
Add the proper checks to be able to compile source-only PD devices with
the common runtime.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:37078
TEST=make buildall
build honeybuns without CONFIG_USB_PD_DUAL_ROLE defined
Change-Id: I7ad0b39b2e62736117ec2d7b5163502afbf14786
Reviewed-on: https://chromium-review.googlesource.com/259112
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: 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>
Since charge manager is now informed of all capability changes as they
happen, it makes sense to store the port capability within charge manager,
rather than storing in pd.
BUG=chrome-os-partner:36390
TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection.
Run 'chgoverride -2' to prevent charging, then repeatedly insert +
remove a dual-role charger on the other charge port. Verify that
charging is still prevented. Finally, insert a dedicated charger and
verify that the override is removed. Also, pass unit tests and verify
correct detection in various scenarios with various chargers.
BRANCH=Samus
Change-Id: I3669050b37ddd67f6608bf790a07e74f86b6ac01
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247724
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If a dual-role charger is plugged, we will not realize it is dual-role
until after we see a type-C charge source. It can cause us to briefly
charge from a dual-role charger, which has bad side effects related to
charge override and the lightbar. Fix this by not charging from a port
until we are fairly certain that it is a dedicated charger (based upon
PD discovery timeout).
BUG=chrome-os-partner:36390
TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection.
Run 'chgoverride -2' to prevent charging, then repeatedly insert +
remove a dual-role charger on the other charge port. Verify that
charging is still prevented. Finally, insert a dedicated charger and
verify that the override is removed. Also, pass unit tests and verify
correct detection in various scenarios with various chargers.
BRANCH=Samus
Change-Id: Ia4154f34dd0a850b6e72bebadbd938f034532f14
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247130
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Occasionally the charge circuit on samus gets wedged and will not
charge. This change detects when the charge circuit has failed
and automatically recovers from it. It uses the BQ PROCHOT warning
to detect the failure by setting PROCHOT to trigger when the BQ
thinks input current is higher than the input current limit. When
the failure is detected, the EC disables charging and tells PD MCU
to disable CHARGE_EN, then a couple seconds later, it re-enables
charging.
This CL also adds more communication between EC and PD for the EC
to be able to set the charge state for the PD. Valid charge states
are: No charging allowed, 5V charging only, and max charging. The
EC uses this as such:
- When the EC gets AC present interrupt, it sets off a deferred
function to change charge state to max charging after some delay
to give time for the charge circuit to settle down.
- When the EC gets AC disconnect interrupt, it disables charging
briefly, enables learn mode, and then sets 5V charging allowed.
This allows for the same starting conditions in the charge circuit
for every AC attach.
- When the EC detects a wedged charge circuit, it disables charging
and waits a few seconds before re-enabling 5V only charging.
Additionally, this change moves the charging cutoff in S3/S5/G3 when
the battery is full to the EC. With the added control for the EC
to set the PD charging state, it is more convenient for the EC to
manage cutting off charging when battery is full.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=test the basics:
- connect/disconnect zinger a bunch of times
- connect and disconnect two zingers in different order
- connect two zingers and charge override between the two
test the automatic charge wedge recover:
- wedge the charge circuit by setting charger voltage under battery
voltage: "charger voltage 7000"
- wait a few seconds for the system to recover and check it is charging
with "battery" command
test full battery charge cutoff:
- added console command to change battery soc in board/samus/extpower.c:
static int cmd_battfake(int argc, char **argv)
{
char *e;
battery_soc = strtoi(argv[1], &e, 10);
batt_soc_change();
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, "", "", NULL);
- in S0, tested "battfake 100" does not disable charging.
- in G3, tested "battfake 100" disables charging and "battfake 99"
re-enables charging.
- set "battfake 100" and tested transitioning to S0 enables charging and
transitioning to S5 disables charging.
- attached two chargers and used charge override to select active port.
then toggled "battfake 100" to "battfake 99" back and forth and verified
charge override port is still the same.
test third-party 12V charger:
- plug in a bunch of times and make sure we stay at 5V for 500ms and then
transition to 12V
test with no battery:
- tested five different units with no battery and just zinger. 3/5 boot,
while the other 2 don't. But, the 2 that don't boot without battery also
can't boot w/o battery when this CL is reverted, so I don't think this
change is causing the problem, I think there is an electrical limitation.
test with EVT zinger:
- EVT zingers (P2 - C2) negotiate very quickly after connection, which
can cause INA problems w/o this CL. Tested an EVT zinger with samus and
did a bunch of connections and disconnections and verified that we always
wait at 5V for 500ms and that we don't wedge the INA circuit on connect.
test backwards compatibility:
- test new PD with old EC and make sure we can charge with zinger.
(note that if the charge circuit wedges, we won't be able to unwedge it).
- test old PD with new EC and make sure we can charge with zinger.
Change-Id: I7703b7a2ab1209d7f559b265b03517e79c74b16a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245253
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Current simplified implementation allows single mode entry. Specification
allows multiple mode entry and its advantageous for things like flashing RW
while staying in DisplayPort mode on video dongles.
CL adds capability on DFP to track as many alternate modes as supported by the
DFP. Initial mode entered is still the default supported mode ( 1st entry, 1st
opos). Policy manager can then use host command, EC_CMD_USB_PD_SET_AMODE, to
enter additional supported modes.
On the UFP (hoho, dingdong) a small modification to track multiple svid mode
entries was made.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdsetmode can successfully enter/exit multiple modes.
For example,
# port:1 svid:18d1 opos:1 cmd:1==enter
ectool --name cros_pd pdsetmode 1 0x18d1 1 1
Checking with pdgetmode shows both modes entered.
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. Still drives external display. With bootarg drm.debug=0x6 and following
command: 'tail -f /var/log/messages | grep "Received HPD" &'
I see HPD assert & deassert when switching between GFU and DP mode.
If both modes entered screen stays lit (after reboot) during write.
Change-Id: I7a21ebea377402eb1b0a0cf1d29df59694e301b1
Reviewed-on: https://chromium-review.googlesource.com/241790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Renaming this to 'opos' for consistency with USP-PD specifications
'object position' in VDM header.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35495
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdgetmode pdsetmode can successfully enter/exit
other modes
3. Works across hard & soft resets
Change-Id: I08cb8e003ced4de481adcb503bcba3437ebb1ab7
Reviewed-on: https://chromium-review.googlesource.com/241718
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Poll USB PD accessories for event log entries only after we have
performed a Discover Identity and identified them as a Google device
(USB VID = 0x18d1) in order to avoid confusing third party devices with
our logging VDM.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35858
TEST=connect Zinger to Samus and see the proper PD log entries.
Change-Id: I022fa0d19dc012e46a27b786a724ff251280eeaf
Reviewed-on: https://chromium-review.googlesource.com/242871
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-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>
The AP informs us of the latest update image for a given device through
the EC_CMD_USB_PD_RW_HASH_ENTRY command. If the latest update image is
equivalent to our RW, we don't need to request an update.
BUG=chrome-os-partner:35510
TEST=Manual on Samus. Flash latest RW FW to Zinger. Verify that
subsequent Zinger insertion doesn't trigger the FW update host event.
Insert RO-stuck Zinger and verify that FW update host event is
triggered.
BRANCH=Samus
Change-Id: I300b150b3469e3fe32307e61273880a1a052ac5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241172
Reviewed-by: Alec Berg <alecaberg@chromium.org>
More updates to connection state machine. Adds CONFIG option
for backwards compatible DFP (used on zinger), and change UFP
state machine to debounce CC while VBUS is not present.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=load on samus and zinger and connect a bunch of times. also
test samus to samus connection.
Change-Id: Ia967eb6a17b10aa0c05a30686235fbf8a24e9a7b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240587
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a FIFO to log important events on the PD MCU and coming from the PD
accessories.
The retrieval of the accessories log from the accessories by the PD MCU
is not implemented yet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32785
TEST=execute "ectool --name=cros_pd pdlog"
before and after plugging Zinger charger.
Change-Id: If96d73e711ff6ad64cfb99bd3e4d2d8f2643f19a
Reviewed-on: https://chromium-review.googlesource.com/238854
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
