Before sysjump we need to send a soft reset to any attached devices
and then disable PD communication so that we don't re-negotiate again
before the sysjump. This will guarantee expected message ID is cleared
for after the sysjump.
This also moves executing soft reset from before sending the soft reset
command to after the port partner accepts a soft reset.
BUG=none
BRANCH=samus
TEST=test on samus. without this change, when sysjumping the PD MCU
has time to re-negotiate (at least partially) before the sysjump, which
causes various problems. with this change, when sysjumping, the PD
MCU sends soft reset, and then does not send anything else.
Change-Id: Id7a60c62c8908ee4ab33dfbe995ef136b0aa83de
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233751
CL to migrate the flashing VDMs from zinger's custom vdm to
common/usb_pd_flash.c such that other updateable type-C devices can
share.
Additionally adds gaskets to call standard runtime flashing facilities
for USB-PD devices using it.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
Try following:
1. From samus_pd console w/ zinger in port 1
pd 1 flash version
pd 1 flash reboot
pd 1 flash info
2. From samus linux prompt w/ zinger in port 1
ectool --name cros_pd flashpd 1 1 <zinger RW payload>
Reading 16384 bytes from
/usr/local/zinger_v1.1.2528-d809e42.ec.RW.bin...
Erasing expected RW hash
Rebooting
Erasing RW flash
Writing RW flash
Rebooting PD into new RW
Complete
3. Repeat 1&2 above on hoho & dingdong.
Change-Id: I018055fa9de128f937c57debdc21dea026137bcf
Reviewed-on: https://chromium-review.googlesource.com/231835
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Added new hard reset recovery states for sink and source state machines
and transition there on hard reset. This is necessary because on a hard
reset we are not supposed to turn off vconn, nor disconnect USB, nor
switch the data role. In other words hard reset is not the same as a
disconnect.
This also changes timing around when to send source cap after a hard
reset and when to expect source cap after hard reset.
This also adds a delay between sending hard reset and executing it to
give time for sink to recognize the hard reset as differentiated from
a disconnect when VBUS goes down.
For sink, when a hard reset is issued or received, sink waits for VBUS
to go away, then for VBUS to come back, and then starts the sink wait
cap timer.
BUG=none
BRANCH=samus
TEST=make buildall
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Icb6ceaf242cebfcf8d08d7317976f83286a256ff
Reviewed-on: https://chromium-review.googlesource.com/228111
Reviewed-by: Vincent Palatin <vpalatin@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>
The role of hoho & dingdong is UFP, and the corresponding protocol
fields in VDO (vdo_idh) should reflect it.
Fix error in IDH_PTYPE definitions of SVDM Identity Header, it's reversed
Adds more legible names to protocol field constants
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Idac9327bf3e8e9597221654bce80bb311b3304af
Reviewed-on: https://chromium-review.googlesource.com/230657
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Bernard Shyu <bernard_shyu@bizlinktech.com>
Tested-by: Bernard Shyu <bernard_shyu@bizlinktech.com>
Add commands to send PD packets and to tweak individual parameters (TX
clock frequency, RX detection threshold, resistors on CCx).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28337
TEST=verify that the PD sniffing is still working by dumping traffic
between Zinger and Samus.
Connect Twinkie to Zinger, set Rd by using "tw res NONE RD" and see VBUS
going to 5V (reading it using "ina 0").
Send a BIST mode 2 request using the following command :
tw send 2 0x1043 50000000
and see the other end starting sending BIST.
Change-Id: I3c8ddf858435ac1c17a43f59351bbaa69603a209
Reviewed-on: https://chromium-review.googlesource.com/227778
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Add a Google Firmware Update alternate mode to zinger. This mode must
be entered in order to allow the unstructured VDMs that we use for
sending a new firmware.
BUG=chrome-os-partner:33754
BRANCH=samus
TEST=load on samus and zinger. see that "GFU" is printed on zinger console
to represent that it entered GFU mode. use twinkie to see that samus
sent discover identity, discover svids, discover modes, enter mode, and
then read info. See on samus pd console that we received result of read
info. from samus pd console with zinger attached:
> pe 1 dump
IDENT:
[ID Header] 2c0018d1 :: AMA, VID:18d1
[Cert Stat] 00000000
[2] 50100001 [3] 00000003 [4] 52136b91 [5] 0401137d
SVID[0]: 18d1 MODES: [1] 00000000
MODE[1]: svid:18d1 caps:00000000
Also, use a samus with cros_pd_update running in kernel, and see that zinger
auto-updates when plugged in. Performed 10 updates with no failures.
Change-Id: I8d4d38e4a9f649fe0889f688f262630ef55106ee
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229622
Reviewed-by: Vincent Palatin <vpalatin@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
When a PD charger is detected, gets its max charge capability, but
initially negotiate for its minimum charge mode. If we later determine
that the port will be the one active charge port, re-negotiate for the
max charge capability.
BUG=chrome-os-partner:32003
TEST=Manual on Samus. Plug in Zinger, verify that current limit is
initially set to 500 mA, then switches to 3000 mA shortly after. Plug in
two Zingers, verify that one provides 3000 mA current while the other
negotiates to 500 mA. Verify that the 500 mA charger bumps up to a high
current once becoming active.
BRANCH=Samus
Change-Id: Ifa562b72d763642fc8bd62bc7f5aaa4eda1ef950
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225922
Reviewed-by: Alec Berg <alecaberg@chromium.org>
During the discovery identity phase of type-C devices that support it
there is some info that could be useful to kernel & userland for
policy decisions. CL starts by passing up the vid, pid & product type
(ptype) of the discover identity VDO.
BRANCH=samus
BUG=chrome-os-partner:32650
TEST=manual,
From host, w/ hoho in port 1
ectool --name=cros_pd infopddev 1
Port:1 Device:4 Hash: 0x57b1e4e0 0x7204075f 0x65c0fa72 0xdcca15ed 0xf3231237
Port:1 ptype:6 vid:0x18d1 pid:0x5010
Change-Id: Ie05d191149ada0ec860b713d780b0345eab3a647
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226899
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Once a mode is entered object position (OPOS ... AKA alternate mode) field in
the VDM header should always track that mode.
CL fixes DP status & config messages which did not add the correct OPOS. In
fixing I mapped to the UFPs function pd_alt_mode which for the DFP did require
the addition of port parameter. Finally I cleaned up code to use this function
throughout common policy layer where previously I'd just accessed the pe
structure directly.
BRANCH=samus_pd
BUG=none
TEST=manual, compiles, insert hoho/dingdong into samus and see OPOS=1 from samus
for enter, dp_config, dp_status SVDMs
Change-Id: I66448c3386be01bae58768632da216aff41a9a30
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228130
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Add delay for power supply startup time before sending source
capabilities packets.
BUG=none
BRANCH=samus
TEST=load on samus, plug in C to A receptacle adapter, see that
VBUS enabled before source cap packet sent.
Change-Id: If3b595e1671d089e859693b420841a639fdb146b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227423
Initial versions of the USB Power Delivery (v0.7) had this bit defined but in
later versions its been removed and should be zero.
BRANCH=samus
BUG=none
TEST=manual,
capture message header with twinkie and see that message header <15> is no
longer asserted.
Change-Id: Ib3e099322b681a49a75b07e1ff929083c71eb44a
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227421
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@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>
Per table 6-24 of USB PD spec an alternate mode adapter (AMA) should
include both product & AMA VDOs.
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
Connect hoho/dingdong to fpie/samus and see product VDO proceed the
AMA VDO in DFP_U console output:
Product VDO -----------------------------v
|------|
SVDM/5 [1] ff008041 340018d1 00000000 50100001 1100000b
Note, hoho's PID == 0x5010
And dingdong (0x5011)
SVDM/5 [1] ff008041 340018d1 00000000 50110001 1100000b
Also see bcdDevice field in descriptor match above data.
$ lsusb -v -d 18d1: | egrep -i "idproduct|bcddev"
idProduct 0x5011
bcdDevice 0.01
Change-Id: I4d898816a45c68c7ff75a54fd348fc11be408ae0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226125
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
USB Billboard class can be used to advertise an alternate mode capable
device that hasn't entered a mode. Additionally it can remain after
mode entry providing its Billboard capabilities descriptor is
updated.
This CL postpones enumeration which previously occurred after boot
until tAMETimeout has passed and alternate mode has NOT been entered.
Future CL could choose to also (re)enumerate with mode capabilities
although this is not required by the USB PD specification.
BRANCH=none
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
With DFP_U which does not enter mode see Billboard class enumerate
else it does not.
Change-Id: I59a0815cd0ea551ba9a878907c0184df4ba9480c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224663
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual
Attach hoho/dingdong to samus and see AMA VDO bits <2:0> set to 0x3
during the discover identity response.
AMA VDO
|------|
SVDM/4 [1] ff008041 340018d1 00000000 1100000b
Change-Id: I1e2459b87cceca88ab3ae09440b689041ae03c7c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226101
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added return parameter to enter mode functions. For DP mode on
samus and fruitpie, only send enter mode if device is a DP
sink (DFP_U).
BUG=none
BRANCH=samus
TEST=make buildall. tested a simpler version of this with a
third-party DFP_D capable device and verified we don't send
enter mode.
Change-Id: I5caf008b7b3711232aeb1a1012cde2022584109b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225288
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Once alternate mode is entered the DFP will make an initial status
request to the UFP. Future status changes on the UFP are then sent to
the DFP via the attention command. This VDM consists of the VDM
header plus another VDO containing mode specific information.
CL adds ability of DFP to consume the attention VDMs status message
and in the case of DisplayPort SID toggle the necessary HPD gpio
accordingly.
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=manual, for DFP w/ HPD over CC see HPD toggle correctly without
manually driving it providing cable connected when AMA is inserted.
Change-Id: Ifef60b5d0170cbcc1b518e3b13e84bac99a17e32
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224769
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A USB type-C to DisplayPort dongle can support either DPv1.3 or
USB Gen 2 signaling.
Our dongles need to advertise that they support DPv1.3 and only this.
Our DFP needs to request DPv1.3 signaling.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=Plug a type-C to DP dongle from another vendor to Samus and see a
display output.
Change-Id: Ie0ac16b675e86f635220a954a2c03442777cc527
Reviewed-on: https://chromium-review.googlesource.com/225250
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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>
Per revisements to the DisplayPort Alternate mode specification there
are two additional SVDMs for DPout support: status & configure.
This CL adds those SVDMs and calls them (status then config) after
finding a device that supports DP Alternate mode.
Future CLs will use these SVDMs to complete providing HPD over CC
support.
BRANCH=none
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual, plug hoho/dingdong into samus and see:
1. Additional DP status [16] & DP configure [17]
2. Drives DPout properly
Change-Id: I52b373085ddc330e4afb1d1883d2621bc2e4ee95
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223260
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added data role bit to PD message header. The data role
is currently tied to power role: source = DFP, sink = UFP.
BUG=none
BRANCH=samus
TEST=tested with third part protocol analyzer
Change-Id: Ic56ea92899d20013aace108cee794d10c3780364
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previous reading of specification left some doubt about how SVDM
responder to 'discover modes' command communicated the number of valid
modes. It is communicated via the 'object position' field in the VDM
header where: opos = modes + 1.
This change adds the mode count to the opos field and sends only that
amount of data back to the initiator. Initiator stores that mode_cnt
so that it can correctly choose a mode when 'enter mode' phase occurs.
BRANCH=none
BUG=chrome-os-partner:30645
TEST=manual,
1. see SVDM responder to Discover modes only send supported number of
modes for SVID.
2. 'pe 0 dump' displays correct set of discovered modes on initiator.
Change-Id: I9b626dd6dd3e85e80b4f0596332300d74b1830ee
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Original implementation was complicated by belief that we'd want PD
MCU to manage entry of multiple alternate modes. This simply won't be
practical given the upper level system policies that would need to
weigh in on these decisions as well as the seemingly endless additions
to the alternate mode ecosystem.
Longer term we'll need to pass the generic alternate mode discovery
VDO info to the kernel/userland to implement remainder of policy.
However, for short term lets implement single mode entry instead.
BRANCH=none
BUG=chrome-os-partner:30645
TEST=manual, mode entry is successful on both ports.
Change-Id: Ia24f5ee4d59c13c62d68b30f8587b5e5fbdb2fa0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223980
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>
Change effects:
1. samus_pd: Acts as initiator of SVDM discovery once its reaches source
ready and upon identifying UFP with display port
alternate mode enters that mode.
2. hoho: Acts as responder for SVDM discovery providing its identity,
svids and svid capabilities which are display port only. If
asked to enter display port alternate mode it does.
3. fruitpie: Acts a initiator with mock display port mode.
BRANCH=none
BUG=chrome-os-partner:30645
TEST=manual,
Plug hoho into samus_pd
- see dpout
- from console
> typec 0
Port C0: CC1 451 mV CC2 111 mV (polarity:CC1)
Superspeed DP1
Change-Id: I1a76767353a69baeceffa3e79c37dcea77b8337d
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221354
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>
The PD protocol no longer uses a SHA1 RW hash. Instead, it uses the
first 20 bytes of the SHA-256 hash. Update constants and comments
accordingly.
BUG=chrome-os-partner:31361
TEST='make buildall -j'
BRANCH=samus
Change-Id: Ice74b841dbd1d81205c1ef0079a5e18fca2153b6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222446
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a minor revision to the PD device hardware ID field in the info
custom VDM and set increment this minor ID from 0 to 1 for zinger.
This differentiates zingers for the auto-update payload, so we can
update only those with a specific major and minor ID version.
BUG=none
BRANCH=samus
TEST=load onto samus and zinger. when connect zinger, see on PD
console: Dev:0x0401 SW:2289 RW:0, which shows the appropriate
device ID.
Change-Id: I482ee2d850332b608cdd81537f68d4dc509bfc1a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221320
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changed sending of info VDM from the UFP side in SNK_DISCONNECTED
to the DFP side in SRC_READY to match the PD spec. Only the DFP
is supposed to send VDMs, and by default the power source is the
DFP. This affects simple DFPs such as power adapters, they must
initiate the info VDM once a power contract has been negotiated.
BUG=none
BRANCH=samus
TEST=load onto samus_pd and zinger and make sure that when you
attached zinger to samus, samus receives info VDM and prints out
something like:
VDM/7 [11] 18d1000b
Dev:1 SW:2280 RW:0
Change-Id: I16ceac31939fdc1c74be7323e628dd8706e1283b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221174
Reviewed-by: Todd Broch <tbroch@chromium.org>
This is mostly the same as previous commits, but with increased delay.
Previously, we have short delays (e.g. 3ms) which is too short and may
cause instability.
Now that we have slowed down the time when running unit tests and
increased the delay, this shouldn't cause problems anymore.
BUG=chrome-os-partner:31200
TEST=Repeatedly run multiple unit tests in parallel.
BRANCH=Samus
Change-Id: Ib55e3adc5fd27a8e233996b4799dab3cefd62318
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Automatically go into hibernate (standby mode) if not powering
anything for 60 seconds. Will wake up when it is plugged into
something (senses pull-down on CC line).
BUG=chrome-os-partner:28335
BRANCH=samus
TEST=load onto zinger. if disconnected for 60s, see hibernate
print on zinger console. when connected to a device, verified
it boots again.
Change-Id: I2564c6192395bb5e4f6d7586c2725f13a4581049
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220837
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
PD accessories that are RW update-able will broadcast their rw_hash
SHA1 digest upon connection to the PD MCU which will store it.
For update purposes, the host needs that accessories device id and
rw_hash to determine its proper firmware update payload.
This CL creates a host command that requests the type-C accessory info
attached to a particular port. It also implements an ectool command
to expose the host command.
BRANCH=none
BUG=chrome-os-partner:31361
TEST=manual,
# connect zinger to port 1 on samus
ectool --dev=1 --interface=lpc infopddev 1
Port:0 Device:1 Hash: 0x7f4d7a13 0xf07b65b9 0x41181e10 0xb99b3d5f 0x9dee1206
ectool --dev=1 --interface=lpc infopddev 0
Port:0 has no valid device
Also do the same on port 0 with similar results.
Change-Id: Id63c7edad77a43d43c14d8cd6bd96e08d0d9b501
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216814
Reviewed-by: Alec Berg <alecaberg@chromium.org>
