implement USB mass storage class using the bulk-only transport
protocol with the transparent SCSI command set.
BRANCH=none
BUG=none
TEST=verify that usb mass storage functions on windows xp, 7, 8, mac os x, goobuntu precise
Change-Id: Ideecad55bd275df7b30aa4a3ed263304a3a109cd
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206303
Reviewed-by: Vincent Palatin <vpalatin@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>
Currently charge state machine resets input current limit to default
every time AC is connected. Problem is by the time charge state machine
gets around to setting input current, it could have already been set
by successful PD negotiation, and this ends up overriding that value.
This fix has the state machine store desired input current limit, as
determined from PD negotation or any other place, and send last desired
input current limit on AC connect.
BUG=chrome-os-partner:24461
BRANCH=none
TEST=load on samus, test toggling between "pd 0 dev 5" and "pd 0 dev 20",
and test plugging and unplugging zinger numerous times, and verify charger
command always gives the expected input current limit based on PD
negotiation.
Change-Id: I18d8acc9e2085739e783c9c70c682d46bcce7fdb
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211639
Reviewed-by: Bill Richardson <wfrichar@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>
ACPI and thermal throttling are used only by x86 platforms.
Modify the conditional build to avoid building them where they are not
used.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
check the flash size on Ryu and see we are saving about 200 bytes with
this changes.
Change-Id: Ie5e1603fb3bea95eaa5cb1e6cb19f4ddb0e235e8
Reviewed-on: https://chromium-review.googlesource.com/210056
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-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>
I2C reads from the PD happen in two separate transactions, but no stop
condition is set after the first transcation. Therefore, it is necessary
to lock the I2C bus across both transactions to prevent other tasks
from using the bus in between.
BUG=chrome-os-partner:29839
TEST=Manual on Samus. Boot to recovery screen, plug + unplug power
supply, verify that no I2C error messages are printed to console.
Then repeat 100x.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie441637f499980a349022e281379ad2cc825b1aa
Reviewed-on: https://chromium-review.googlesource.com/211649
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
There is nothing chip-specific in the software CRC implementation. Let's
move it to common so that we can reuse it for other chips and unit
tests.
BUG=chrome-os-partner:31200
TEST=Define CONFIG_SW_CRC for host. Check crc.c compiles fine.
BRANCH=None
Change-Id: Icdc1d105c55c38ff07410cb5d733a31dbac53aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211494
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>
If a battery is found in disconnect state, we need to apply a charge
current to get it out of that state, even if the battery is full.
BUG=chrome-os-partner:29465
TEST=Manual on Samus. Put full battery into disconnect state then
power-on the EC. Pull AC and verify that the battery is no longer
disconnected.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I43e872e225dc5a651f566d7b190cff85a487805e
Reviewed-on: https://chromium-review.googlesource.com/210343
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@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>
Previous assumption assumed that the flash was remapped
to address 0.
This is not the case anymore since cl/210063
BUG=chrome-os-partner:30997
TEST=Check we can boot the EC now.
BRANCH=None
Change-Id: I46e1dc0ad840b21661aa5d87817369b29a659c9b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210407
Host commands can be generated by either the PDCMD task (in response
to PD interrupts), or the HOSTCMD task (in response to passthru
requests). Use a mutex to serialize access to the EC->PD interface.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Boot samus
Change-Id: If65d5eb4bbef91e6c811a06ea2e1487e17143dc7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210401
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@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>
On most platforms, the power button is active low,
but the power button on Ryu is active high.
Add CONFIG_POWER_BUTTON_ACTIVE_STATE to override the default active
state.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=on Ryu, use the servo pwr_button to start and stop the AP.
Change-Id: I11c6bb3c700bccd3606ce1fa1a69905671792990
Reviewed-on: https://chromium-review.googlesource.com/207274
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@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>
The Samus battery can be placed into a disconnect state by asserting a
disconnect input signal. In this state, the battery will not function
until a charging current is applied. This patch adds detection of the
disconnect state. If a battery in disconnect state is found, a current
is force-applied to the battery to kick it out of disconnect.
BRANCH=None
TEST=Manual on Samus.
1. Put battery into disconnect state
2. Pull AC, then reattach AC
3. Verify "found battery in disconnect state" is seen on the
EC console.
4. Pull AC and verify that EC console is still accessable
Also verify that battery gets out of reset state:
1. Pull AC
2. Issue "i2cxfer w16 0 0x16 0x0 0x12" command on EC console
3. Re-attach AC
4. Pull AC and verify that EC console is still accessable
BUG=chrome-os-partner:29465
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib4268887fb483094ac4e641749200268160d3014
Reviewed-on: https://chromium-review.googlesource.com/209013
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
We are now using argv[5] even if the user only gives 5 arguments. Fix
it.
BUG=None
TEST=Read with i2cxfer command and doesn't see "Invalid param 5"
BRANCH=None (this can be worked around by adding a dummy param)
Change-Id: Ice13fec4ad53c71b6529daa3510fa6fc1d7f8c00
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208489
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ILIM control line is inverted before reaching the USB charge
controllers when they are cross-connected to allow only one port
to deliver the HIGH current limit at a time.
BUG=chrome-os-partner:29053
BRANCH=ToT
TEST=Verify, with a multimeter, that ILIM (pin 4) on a TPS2546
is 3.3V when the chargemode is set to CDP
Change-Id: I2f720d04b959417ae96687d7e30ee60270eeccb9
Original-Change-Id: Idd89dcfc117f1f3393ded1887e8d1cb27ba367ad
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205811
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208161
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>
Host commands in the range 0x4000-0x7fff will be passed thru the EC to
the PD MCU as 0x0000-0x3fff.
BUG=chrome-os-partner:30079
BRANCH=samus
TEST=manual. On PD console:
hcdebug params
On EC console:
hostcmd 2 0 -> hex string of EC version
hostcmd 0x4002 0 -> hex string of PD version, and PD console shows host
command 2 was received. The hex response shown on the PD console
matches the one printed by the EC
Change-Id: Icc2d97c5977145a0c3ad2630d2b5a19e876a36d0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207821
Reviewed-by: Bill Richardson <wfrichar@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>
This caused all platforms to check only the first 25% of each page to
see if it's already erased. Fortunately, we tend to fill flash pages
from the beginning, so in normal usage we don't hit this bug.
BUG=chrome-os-partner:30281
BRANCH=all (if convenient)
TEST=Make sure CONFIG_CMD_FLASH is defined. Then at the EC console:
flasherase 0x1f000 0x400
rw 0x1f3e0 -> 0xffffffff
flashwrite 0x1f3e0 0x20
rw 0x1f3e0 -> 0x03020100
flasherase 0x1f000 0x400
rw 0x1f3e0 -> 0x03020100 (bad!) or 0xffffffff (good)
Change-Id: If78b08b5e0414993a440bc8cd707b5ce70eb1a0a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206891
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
