BRANCH=manual
BUG=chrome-os-partner:28585
TEST=manual,
Plug USB 3.0 capable device in both ports and both polarites on samus
and see device enumerate as superspeed. For example,
usb 2-3: new SuperSpeed USB device number 6 using xhci_hcd
In order you must first connected device (hoho) prior to configuring
mux via 'ectool --dev=1 --interface=lpc usbpd <port> dp'
Change-Id: Ia6b8a714ce9ae1539769399e51ff245d00202171
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214579
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As we add more PD states, it's easy to forget to update the names of PD
states. This doesn't break any PD functionality so would be hard to
discover. However, it can easily confuse us when we are debugging. Add
a compile-time assertion to make sure it's updated.
BUG=None
TEST=Remove one names and check build fails.
BRANCH=None
Change-Id: I8b503e361b3418835cdf510dd39481eb7d998035
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212885
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If a ping is dropped, instead of cutting power immediately, we should
first try soft reset. If the soft reset packet is not received or an
ACCEPT packet is not seen in time, we'll then perform hard reset.
BUG=chrome-os-partner:31296
TEST=Add a console command to drop pings on Samus. Check that when a
ping is dropped, the power is not cut and the connection is
re-established.
BRANCH=None
Change-Id: Ifbee4124d55a9a7857a019ca823698f32911f3c7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212925
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
After sending a soft reset, the port partner is supposed to respond with
an ACCEPT. If ACCEPT is not seen within PD_T_SENDER_RESPONSE, we should
try a hard reset.
This CL also changes the definition of SOFT_RESET state from an
artificial delay state to a state waiting for ACCEPT. With this, we are
now just waiting in DISCOVERY state after a reset and therefore we can
remove the 30ms artificial delay.
BUG=chrome-os-partner:31296
TEST=Along with the next CL to send soft reset on dropped ping, check
power doesn't drop when a ping is dropped.
TEST=Modify Samus to not send ACCEPT when a SOFT_RESET packet is
received. Check that we received HARD_RESET after SOFT_RESET.
BRANCH=None
Change-Id: Iddce33befa0c3c43228e68aac8e481d3da52db2a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212924
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Every time a type-C source is plugged in, send a special VDM to
read device info. Device info will contain RW Hash (sha1), a
unique hardware descriptor (USB_PD_HARDWARE_DEVICE_ID), a
software version number just for debugging (USB_PD_DBG_SW_VERSION),
and a flag for if the device is in RW. This feature is off by
default and can be turned on by defining
CONFIG_USB_PD_READ_INFO_ON_CONNECT, currently defined for samus
and ryu only.
Renamed the read RW_HASH VDM to READ_INFO since it now returns
more than just the hash.
When device info is received, we store the RW hash. In the future
we will use this to check if device needs an update.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=load onto a samus and a zinger. test when you attach zinger
we send a VDM, and we get device info printed to console. also
use "pd 0 hash" to query last hash received.
Change-Id: I0ca57651cf8506ea738b080a6cf8e7b020ef8724
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213832
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
This adds a new host commmand for sending RW updates to PD devices.
The host command has a variety of sub-commands for performing the
update, including: erase RW, reboot, write new hash, write flash.
To program zinger RW, you should send host commands in this order:
write new hash to all 0's
reboot (zinger boots into RO since RW hash doesn't match)
erase RW
write flash
write new hash to match contents of RW
reboot
This also adds an ectool command to write a new RW. Just pass it
the RW .flat or .bin file.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=ectool --dev=1 --interface=lpc flashpd 0 0 zinger.RW.flat
Change-Id: Ia81615001b83ad7ee69b1af2bf1d7059177cde04
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213239
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want these hooks for all dual role boards. Let's move them to common
so that we don't have to duplicate them for every board.
BUG=None
TEST=On Ryu, plug in C-to-A cable. Check we are in source state.
BRANCH=None
Change-Id: I9c7a798fda2cdec94ee533d54172c6cc4fed029e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214070
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Enable check for protected mode. If we are in RO and we are write
protected, then don't allow PD communication.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=Booted with and without battery, made sure PD communication
works and we can boot (note we are currently not protected).
Then commnented out CONFIG_SYSTEM_UNLOCKED, and ran flashwp enable
from PD console to protect the system. Now when boot with battery,
we don't communicate over PD and just take VBUS 5V. Removed battery
and attempted to boot with just AC, but not enough power to boot
off just 5V. EC goes to S0 and back to G3 after about 100ms.
Change-Id: Ib26f8f0f5e9134d0337ebbd7f087f50fa41842d8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213738
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add custom VDM to read last measured output current in mA.
BUG=chrome-os-partner:30850
BRANCH=none
TEST=Run "pd 0 vdm curr" on samus pd console and verify
reasonable current
Change-Id: Ie1f1ab235560eb4e90f399ceac31c5cd93003d80
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212981
Turn off sending pings in SRC_READY by default. Added custom VDM
to turn pings back on, which only zinger supports right now.
Changed the "pd ping" console command to be used to enabled/disable
pings in SRC_READY.
BUG=chrome-os-partner:31409
BRANCH=none
TEST=loaded onto samus and zinger. on samus_pd, enabled highest
level of debug info: "pd 0 debug 2" to allow printing ping received.
Then plugged in zinger. By default, we negotiate to SNK_READY and
receive no pings. Then send "pd 0 vdm ping 1" to send VDM to zinger
to enable pings, and verified we start receiving pings. Sending
"pd 0 vdm ping 0" sends VDM to stop sending pings.
Change-Id: I4f64c6fc59bb734146eeca5e3ea3a24954c786b2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212965
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
This fixes a bug in the PD transmit retry mechanism. In the retry
mechanism, we were assuming that only a pd rx interrupt will wake
up this event. But, there are other events that could potentially
wake us up, so we need to check to make sure that pd rx started
when we first wake up.
BUG=chrome-os-partner:30135
BRANCH=none
TEST=load onto samus and zinger. run "pd 0 flash rw_hash" a bunch of
times manually from the console. Observe that we nearly always fail
the first receive, but succeed on next try, which prevents us from
dropping the negotiation.
Change-Id: I5f7261176c151c3185d76aa374b9b83ac9df9a7d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213369
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
We're printing more and more log and this sometimes causes timing issue.
Let's guard the PD log with a log level. Currently there are three
different levels:
- 0: Log state transition
- 1: Level 0, plus packet info
- 2: Level 1, plus packet dump on error
The default value is 0.
BUG=None
TEST=On Ryu, enable USB PD console channel and set different log levels.
Observe different amount of log message.
BRANCH=None
Change-Id: I49613d406bcb1ec20d3f242f724dc1c054478c7d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212351
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On sysjump, we are losing all of our PD states. Instead of trying to
remember all the states and deal with on-going transmission, let's just
issue a soft reset so that the communication starts over.
BUG=chrome-os-partner:31207
TEST=With Ryu/Zinger, do 'sysjump rw' and check EC doesn't reboot.
BRANCH=None
Change-Id: I8779b74491a402434931b3455fa93ff2e178cb1f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212123
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, when we receive soft reset request, we only reset message ID.
According to the spec, we should also reset the state machine without
cutting power. This CL implements this, along with a console command to
issue soft reset request.
BUG=chrome-os-partner:31296
TEST=Issue soft reset from Ryu to Zinger. Check that we go back to
discovery state and re-negociate a contract.
BRANCH=None
Change-Id: Ib00b0d9dddaf6ac2a1ec5c46dbc2824d6d7814ed
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212122
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Change the VDM implementation in the PD task to allow for VDMs
at any time when connected without disrupting any regular PD
communications.
BUG=none
BRANCH=none
TEST=load on a samus and on a zinger and test sending VDMs:
pd 0 flash version
pd 0 flash reboot
Also, test using the flash_pd.py script to write zinger RW using
VDMs.
Change-Id: I48352978d8c45f78e8a5a7735d65b013a853f3e2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210746
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As per the PD spec, give up on sending source cap packets
after nCapsCount number of attempts.
BUG=chrome-os-partner:28341
BRANCH=none
TEST=Connect samus to an unplugged zinger. Samus recognizes
a device has been plugged in and sends source cap for 5
seconds (50 attempts at 100ms retry period), then stops
sending source cap but remains in discovery state providing
VBUS.
Change-Id: I0aa25263f200299a0eb8d219883f825ae655129c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211335
After sending a message, we wait for up to 2.7 ms for reply. If we don't
get one, we retry for up to twice. Therefore, a undelivered message
could take up to >8ms. To prevent starving other tasks, let's yield to
other tasks on retries and rely on interrupt to wake us.
BUG=chrome-os-partner:28341
TEST=Plug in zinger on port 0 and C-to-A dongle on port 1. Check that
port 0 drops connection less frequently.
BRANCH=None
Change-Id: If85a70fd1140fef69d79243b198703ce601f8030
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211281
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When PD state changes, log the state transition. Also, now that we have
the state logged, logging pings doesn't help us anymore, so stop logging
them to make console clean.
BUG=None
TEST=Run on samus_pd. Plug/unplug zinger. Check state is logged and
pings are not.
BRANCH=None
Change-Id: Ib482b3351d9681fbb4bcc2585da58c732428b7af
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211262
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a preparatory work for USB PD unit test. With this, we won't
need to duplicate these constants in both the implementation and the
test.
BUG=chrome-os-partner:31200
TEST=make buildall
BRANCH=None
Change-Id: Ia814a95450859caaa6d90e4cd866cb671d010b31
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211653
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Set input current limit based on the max current from the
PD negotiation. For samus, this information is passed to
the EC as a host command. For ryu, the max current is set
directly following a negotiation.
CONFIG_CHARGER_INPUT_CURRENT is now just the default limit,
but after a successful PD negotiation, the limit can be
raised.
Note, for now the input current limit for samus is set to
2/3 of the value negotiated for. This is due to hardware
problems measuring input current on p2b boards.
BUG=chrome-os-partner:28532, chrome-os-partner:24461
BRANCH=none
TEST=tested on a samus. Verified input current limit using
"charger" console command from EC. Input current limit
after a reboot is 512. When zinger is plugged in, it jumps
to the appropriate value (currently 1280mA), and when
the negotiation is changed using the "pd 0 dev 5" command
on the PD console, the input current limit is adjusted to
match (2000mA).
Change-Id: Iab9186a0f9814655e3240217a9baf4a38f15f84d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211023
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add PD communication enable flag. When disabled, the ports
will still detect source/sink connect and disconnect, and
will provide VBUS to a device, but will not send or respond
to any PD communication.
Use the CONFIG_USB_PD_COMM_ENABLED macro to define the
default state of PD communication enabled flag which may
vary board to board.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=load onto samus. use "pd 0 enable" console command to
toggle between enabled and disabled. when disabled, test
that plugging in a zinger only gets you the default VBUS 5V
and that no negotiation takes place. when enabled, test
that plugging in zinger negotiates successfully.
Change-Id: I78ac3091f12d9699b19647be48ab7b6f434f5d7d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211045
If we are in SNK_DISCOVERY state and get PD_RDY, we are not sure what
the power source is. In this case, instead of happily go to SNK_READY
state, we should do a hard reset to be safe.
BUG=None
TEST=Check PD on samus/zinger still works.
BRANCH=None
Change-Id: I2baca06d45ba41e30d2ccf7a02fb65eb3966e5c1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210925
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we are in disconnected states and get a request, it's likely either
ourself or whatever on the other side is confused. Do a hard reset in
this case.
BUG=None
TEST=None
BRANCH=None
Change-Id: Ic6504fccc55b79bd3ec4cc47007252e7dc69c778
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210924
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In PD state machine, we often need to do "go to X state, and if after Y
ms we are still in X state, go to Z state." However, we do this in a way
that are suspectible to premature timeout if PD task is waken at an
unfortunate time. Let's add methods to set the state w/ or w/o timeout
to prevent this.
BUG=None
TEST=Boot on samus. Plug in zinger, and check we have 20V power.
BRANCH=None
Change-Id: I91db44ef71e31007eef4edd0f826bf81505e51e5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210874
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove code for preventing PD negotiation until the battery
is at some minimum SOC. This was originally necessary because
transitioning voltages would cause the source voltage to go
briefly to 0V, which would kill power to the system unless
the battery was at some minimum level of charge. But, that
isn't true anymore. It is safe to transition up or down in
voltage and the source voltage should never drop to 0V.
BUG=chrome-os-partner:29499
BRANCH=none
TEST=make -j buildall. No need to do any more testing because
this code has been disabled for a while.
Change-Id: I8a3dca117f01f0f9c7d04b5d489e4a8588a89be6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211021
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add console commands to send the Vendor-Defined Messages used to flash a
USB-PD target.
Also add a simple test script to flash Zinger through its CC line. To
run the script, the board must have CONFIG_USB_PD_CUSTOM_VDM defined.
By default fruitpie has this config option enabled.
BRANCH=none
BUG=chrome-os-partner:28330
TEST=With a fruitpie connected to a zinger run
./util/flash_pd.py ./build/zinger/ec.RW.flat
and see Zinger booting on RW.
Change-Id: I06f8f545e28b93b2e646e668d81b594eb7976a2d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203375
Reviewed-by: Todd Broch <tbroch@chromium.org>
Fix bug in pd transmission. The retry mechanism was not working right
and was causing us to not do any retries.
BUG=none
BRANCH=none
TEST=Test with a zinger unplugged from the wall. Samus sends source
cap and doesn't get a response. Verify on console printout that we
retried 3 times.
Change-Id: Id273bf054655c2d24a791f4eaf4cb8d87253abe2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have three copies of 'typec' commands in three different boards. The
commands current mix hardware-specific logic and console command logic
together. Adding a board_get_usb_mux() interface to separate the logic
and deduplicate the console command logic.
BUG=None
TEST=make buildall
TEST=Test 'typec' command and verify GPIO settings.
BRANCH=None
Change-Id: Ie1825f49d32609c732db384679cb917f2f1a4082
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209955
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add back in sending hard reset on board fault.
BUG=none
BRANCH=none
TEST=Using zinger and firefly, create an overvoltage error by down
stepping with a 0 VOLTAGE_DOWN_STEP_TIME, and make sure that a hard
reset is received by firefly and that we re-establish negotiation
after the OVP fault is cleared.
Also tested with zinger and samus. On samus I set the input current
to 3.5A, which immediately triggers an OCP, and verified that we
get a HARD RESET from zinger and that after the reset we negotiate
correctly and get back to normal (note that when VBUS goes down, the
EC resets the input current limit to default 2A, so that's why we
don't continue getting OCP).
Change-Id: I991b15411c4ce05c1086851b1e2e56e2effab749
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209865
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow a sink to request a new voltage without dropping the established
negotiation. For this to work the sink must save the last received
source cap packet and use that to make a new RDO from the SNK_READY
state.
BUG=chrome-os-partner:30389
BRANCH=none
TEST=Tested on a firefly connected to zinger. made sure we can press
buttons to change voltage and we don't lose the existing negotiation.
Also tested on samus, ports 0 and 1, using pd x dev 5/12/20 to switch
between voltages and verified we don't lose existing negotiation.
Change-Id: I5a550b667f3aff7975185e091f3caac4555a907e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209864
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changes to match this part of the spec:
The Sink shall support the SinkWaitCapTimer. When a Sink observes an
absence of Source Capabilities messages, after VBUS is present, for a
duration of tTypeCSinkWaitCap for the Type-C connector and
tSinkWaitCap after VBUS is present,for all other connectors the Sink
shall issue Hard Reset signaling in order to restart the sending of
Source Capabilities messages by the Source (see Section 6.6.4).
tTypeCSinkWaitCap shall be between 210 and 250 ms
Also set send source cap period appropriately:
tTypeCSendSourceCap shall be between 100 and 200 ms
This should help avoid transmission collisions during negotiation.
BUG=chrome-os-partner:30135
BRANCH=none
TEST=load onto zinger and samus and verify they negotiate correctly
10 times. Then loaded custom code to zinger to not send source cap
and verified we send hard reset. Also tested plankton to samus
negotiation works.
Change-Id: Idd6118e3e0a9f7a96ebeae9518c8b10457232c70
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209558
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Include a force source mode for dual-role ports to allow us to
force a dual-role port into being a source.
BUG=chrome-os-partner:28782
BRANCH=none
TEST=tested on plankton, verified using the pd 0 dualrole console
command.
Change-Id: Ic4c2a9e11984b34b1dec09d5c71e1fd15ed9198c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209071
Reviewed-by: Vic Yang <victoryang@chromium.org>
Adds dual USB-PD port support for samus. Both ports are in dual-role
and can perform either role.
Both ports work fine when only one of the ports is in use. But,
still having problems with PD errors on the lower priority port (port
0). If you have a charger plugged into port 0, and a type-C USB dongle
plugged into port 1, then port 1 has higher priority, and in the
SRC_DISCONNECTED state, every 1.5 seconds when it sends source cap
packet, we occasionally drop pings on port 0, which results in a
lot of start/stop charging.
BUG=chrome-os-partner:28585
BRANCH=none
TEST=Tested on samus to make sure both ports work when I
plug in a charger and a type-C USB dongle with a pull-down on the CC
line. Tested on plankton and zinger to make sure PD works as expected.
Change-Id: Ie7bde3e258f5cd23a0b82b626c0993a45b0df074
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200750
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Add support for toggling between source and sink as dual-role
port. When transitioning to S0, we turn toggling on, when transitioning
to S3, we turn toggling off but remain in the same PD state, and when
transitioning to S5, we turn toggling off and force the PD role to a
sink.
Note, when toggling is off, the source disconnected state is
allowed to transition to sink disconnected, but not vice versa. This
means that if you go into S3 as a source, it will remain a source
until the device is unplugged, at which point it will transition to
a sink until the next transition to S0.
The spec specifies:
tDRP: 50ms - 100ms, Period a DRP shall complete a DFP to UFP and back
dcDRP: 30% - 70%, Percent of time that a DRP shall advertise DFP
tDRPHold: 100ms - 150ms, time to hold VBUS on after a DRP detects a UFP
tDRPLock: 100ms - 150ms, time to stay in DFP after detecting loss of UFP
This CL uses 40ms for time as a UFP (sink), 30ms for time as a DFP
(source), and 120ms for hold and lock times.
Also, if advertising as a DFP (source) and VBUS is detected, this
automatically switches to a UFP (sink).
BUG=chrome-os-partner:28782
BRANCH=none
TEST=test on samus, make sure we are toggling between source and sink
when disconnected. make sure plugging in zinger switches state machine
through to sink_ready and make sure plugging in a USB switches to
source_discovery. tested on a fruitpie by scoping the CC line and verifying
the timing (except the hold time which I can't easily test).
tested that dual role toggling is off in s3 and s5. also verified that
going into s3 as a source keeps the port as a source and going into s5
switches it to a sink.
Change-Id: I478634861f694164301d71359da35142ee7ebf75
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207154
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Revert
- https://chromium-review.googlesource.com/#/c/205145/2
- https://chromium-review.googlesource.com/#/c/205147/4
Now using the real AC_PRESENT gpio signal instead of whether or
not the PD MCU negotiated for 20V.
BUG=chrome-os-partner:29841, chrome-os-partner:29842
BRANCH=none
TEST=tested on a board with reworked AC_PRESENT signal. Verified
that gpio is correctly reporting state of AC and is charging when
AC is plugged in. Tested the no battery case to make sure
board powers on and stays on with just a charger. Also tested the
dead battery case by plugging in a dead battery, then plugging in
a charger and making sure system powers on and starts charging.
Change-Id: I4424771c91c8a2aa19eda68a8b5194e9265d529c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206598
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The HW signals to control the type-C ports muxing have changed between
Fruitpie and Samus, update the code to match the HW.
Also add the docking mux option and update the board muxing code to
prepare for the automatic mode detection :
- the polarity will be determined by the PD code.
- the port muxing will be enable/disable by the common alternate mode PD
code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
Change-Id: I0706626270c73d2a5e3f85b86e65a7c4fc21f9ec
Reviewed-on: https://chromium-review.googlesource.com/206685
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we reset the PD power source, ensure we always transition to
DISCONNECTED state, so we will re-enable the 5V power when transitioning
back from DISCONNECTED to DISCOVERY.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=Plug Firefly to Zinger and play with voltage transition buttons.
Change-Id: Ifa0f30391b2249b54385ce8c93df932e37803695
Reviewed-on: https://chromium-review.googlesource.com/206954
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Change PD sink to use VBUS for initial detection to match
USB type C spec.
BUG=chrome-os-partner:30116
BRANCH=none
TEST=Tested on samus. Connect and disconnect zinger a few times
and make sure we successfully negotiate each time.
Change-Id: Ifa9ff301cb34b6df6609d4bbbde3231bb029d554
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207000
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Verify the connection status at every FSM loop,
by monitoring VBUS presence for the sink and by monitoring CC going
above Vnc for the source.
Also ensure we are never stuck in the source transition state in the
sink doesn't ack the PSReady packet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=connect Firefly to Zinger, trigger hundreds of voltage transition,
record and analyze the PD traffic : no longer see spurious PSReady
messages.
Change-Id: I4495ae5415d53d77055fb2a562c594fa9a1d4dc8
Reviewed-on: https://chromium-review.googlesource.com/206945
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Once the source has successfully sent a SourceCap packet (ie it got
acked), it needs to transition from the DISCOVERY to the NEGOCIATE
state.
This was done when the source was sending unsolicited SourceCap, but
this was missing when the SourceCap was an answer to a Sink GetSourceCap
request. The usual effect of the missing transition was sending twice
the SourceCap triggering some collisions.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=plug a Zinger to a Firefly, randomly push the Firefly voltage
selection buttons and see the transition always happening properly.
Change-Id: If4b335e2144595f22ad4e9a8a9e289506f597407
Reviewed-on: https://chromium-review.googlesource.com/206941
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Until now when send_validate() receives another valid packet in place of the
GoodCRC, it was continuing its retries loop. But given that the presence
of a valid packet indicates that the other side is trying to send us
something, it's better to bail out immediatly and wait for its retry.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29847
TEST=repeatly plug and unplug a Zinger to a Samus and record the traces
of the PD negociations.
Change-Id: I901bd8d85999ed195ed9887d7375806f61222f8b
Reviewed-on: https://chromium-review.googlesource.com/206391
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The ACOK input to the EC is not connected to the charger so
that signal cannot be relied on for AC presence. Instead
have the PD report when it negotiates to 20V and when it
disconnects and have the EC use that for AC presence.
BUG=chrome-os-partner:29841
BRANCH=none
TEST=test charging with zinger on samus system.
Change-Id: Ia9096a24ab05d110e31910218dc8c214a846a9a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205145
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Increase the delay after receiving a good CRC in send_validate_message()
to avoid catching the last edge as the start of a new packet.
BUG=none
BRANCH=none
TEST=Tested with zinger and samus using the python script to flash
zinger RW, and simply negotiating power and receiving pings.
Change-Id: Iffdd73e02e5d292396d46a611d728f66402f2da4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203206
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Use a EC to PD host command to notify the PD MCU when a battery
is present and charged enough that it is ok to negotiate for a
higher power. The PD MCU will not negotiate until the host command
is received, which allows the system to be powered without a
battery or with a dead battery with 5V.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Tested on a samus:
1) Tested the normal case of battery charged and plugged in. When
charger is plugged in, the device immediately starts negotiating
for 20V and starts charging.
2) Tested with no battery. Plug in a charger, samus boots and stays
alive. VBUS measured at 5V. When a battery is plugged in, device
negotiates for 20V and starts charging.
3) Tested dead battery by taking a battery with no charge, and
plugging in zinger. Everything boots, but PD does not negotiate
for power. Then when battery reaches 1%, PD negotiates and zinger
switches to 20V without causing a reboot.
Change-Id: Iaa451403674e86cddbd3fe80e9503584910be576
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201958
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For non-PD aware sink, ensure that we detect their disconnection when
the CC goes back above Vnc.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28782
TEST=on Samus, put the port in source mode (using the "pd charger"
console command), then plug and unplug the type-C to type-A cable and see the
PD state going from Disconnected to Discovery and the other way round
(using "pd state" console command).
Change-Id: Ic9e19fee78f0c5e1fc742e2443eaf4b804ee5ee9
Reviewed-on: https://chromium-review.googlesource.com/202445
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
