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>
dingdong/hoho have no capability to measure VBUS which is advantageous
in determining what timeouts to honor. Previously we simply assumed
vbus was on and that made things happy until,
e0c80ac pd: on hard reset go to a hard reset recovery state
which introduced proper handling around sink & source reset recovery.
With VBUS assumed 'on' this leads to short timeouts chosen
(PD_T_SAFE_0V) which in turn causes sink to resend hard resets before
source has had time (PD_T_SRC_RECOVER) to handle request.
This change creates config CONFIG_USB_PD_NO_VBUS_DETECT for devices
without the capability to account for lack of VBUS detect.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34090
TEST=manual
from samus_pd 'pd 1 flash reboot' is successful
Change-Id: I9ef9b0115c7be6c56c64556d2ce8c296f95c614e
Reviewed-on: https://chromium-review.googlesource.com/233024
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@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>
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
Previously enabling USB would automatically (using an
init hook) initialize the USB peripheral. This would
take over the GPIO lines assigned to the USB module.
This is not OK on Ryu for Case Closed Debug because it
interferes with the AP's access to the USB 2.0 lines
even when not in Case Close Debug mode.
This change adds a configuration option to inhibit this
default initialization of the USB peripheral. It also
renames the existing CONFIG_USB_INHIBIT to
CONFIG_USB_INHIBIT_CONNECT now that there are two
possible inhibitions.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable console on ryu_p2 and discovery-stm32f072 board
Verify that it works on both
Change-Id: I6734357131b4356e3d4164349d6c74deac196ce5
Reviewed-on: https://chromium-review.googlesource.com/229138
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@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
For request message, add the operational and max current for each
board. If the requested power is less than the operational power
required, then set mismatch bit.
BUG=none
BRANCH=samus
TEST=make buildall. load onto samus, plug in zinger and see
that request 20V, operational current 3000mA and max
current of 3000mA.
Change-Id: I4df45d88b7e060f66ff5b806f6fe30803f1afcf7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227393
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
Previously the version string was special cased in the USB stack
because the build system prevented the inclusion of ec_version.h in
any file other than common/version.c. This lead to common/version.c
being the only place that the USB version string could be computed
and thus the special case of filling in the version string descriptor
at run time. This made the USB stack more complex, and lead to the
common/version.c file including usb.h, which is actually STM32
specific.
Now, the portion of ec_version.h that is deterministic is only
updated when something in the tree actually changes (by way of a
conditional in the makefile), and ec_version.h no longer has to
depend on all object files (other than the special version.o).
This allows anyone to include ec_version.h as needed. In particular,
each board that wants to define a USB version string can directly
include ec_version.h and do so.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
touch files and verify rebuilds happen correctly
Change-Id: Ic84d0b9da90f82ebb4630fb550ec841071e25a49
Reviewed-on: https://chromium-review.googlesource.com/227211
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
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>
When we are a UFP with a plug, for the supported DisplayPort pinout,
we need to state which DFP pin configuration we support.
Update the field used for declaring pin configuration in our display
dongles.
HoHo is a protocol converter : update the pin assignment to C.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=none
Change-Id: Ie5484f228bd39666c6b01055bd11f68eb9acad88
Reviewed-on: https://chromium-review.googlesource.com/225231
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>
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>
All non-interactive console prints should use their tasks channel
parameter to make it easy for developers to inhibit console output.
This CL corrects printf's in the various usb_pd_policy files that
belong to the USB PD task to use cprintf(CC_USBPD, ...) instead of the
macro reserved for interactive console commands ccprintf.
BRANCH=none
BUG=none
TEST=manual, set 'chan 1' and see none of the previous chatter
relating to USB PD. set 'chan 0x08000000' and see it return.
Output from DFP side for SVDM discovery now looks:
SVDM/4 [1] ff008041 340018d1 00000000 11000008
[1119.966911 DONE]
SVDM/2 [2] ff008042 ff010000
[1119.970135 DONE]
SVDM/2 [3] ff018043 00100081
[1119.973437 DONE]
SVDM/1 [4] ff018184
Change-Id: I47e5f4ec2d4a6a25f171177ead5ebc99409f80b6
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224191
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
So far, we always use channel 1 of the Tx timer and the configuration
code is hard coded. We need to support other channels for new Ryu
boards. Let's make this a configurable bit.
BRANCH=samus
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Plug in Zinger to Ryu and see 20V come up.
Change-Id: Id08d4eb0d6a5721d8a03672484d0892a0714383b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223836
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
Per alternate mode this GPIO should not be enabled until alternate
mode has been successfully entered.
BRANCH=none
BUG=chrome-os-partner:31192
TEST=manual, compile & boot on hoho gpioget PD_SBU_ENABLE = 0
Change-Id: Ide2a47851f30812b289221e302a930134a58a8a0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223159
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Remove the meaningless version string in iSerialNumber, which was incorrect
since this string should be unique to a device if it exists.
Export the firmware version string as the configuration string, so it's
traceable to a given firmware build/sources.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
from a workstation, do "sudo lsusb -v" and see the full version string
exported as the configuration name.
Change-Id: I557df2936421e2926ac0fc0003888370cec3e201
Reviewed-on: https://chromium-review.googlesource.com/222877
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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>
Allows dingdong to receive initial USB PD communication (source
capabilities payload) and with some manual manipulation (see 'TEST=')
drive DPout.
CL is based heavily off hoho dongle where all files were copied from
board/hoho:
7b1e58c ectool: Add host command support to set fan RPM for each
fan separately
Files gpio.inc, board.h & board.c were modified but others should
be identical.
BRANCH=none
BUG=chrome-os-partner:31193
TEST=manual,
When attaching dingdong to samus_pd and configured via
'pd dualrole source'
I see following on samus_pd console:
C1 st9
Switch to 5000 V 900 mA (for 900/900 mA)
C1 st10
C1 st11
C1 st12
showing power constract and transition to SRC_RDY:
> pd 1 state
Port C1, Enabled - Role: SRC Polarity: CC1 State: SRC_READY
> typec 1 dp
Also if I connect in CC1 configuration and get access to dingdong
console I can
> gpioset PD_SBU_ENABLE 1
And see dingdong drive external monitor
Change-Id: I30ef6f8503a3fb015cfb8806bc36fb98f5150e40
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221913
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
