Fix bug in USB PD initialization after a sysjump. Since the CC pull
resistors weren't being initialized after a sysjump, we would sometimes
end up stuck in sink debounce state because we would have Rp applied
and our initial state of sink disconnected would think that a source
was attached. And since we continued to apply Rp, we would never make
a connection with a charger, so we would be stuck in sink debounce
until a reboot.
BUG=chrome-os-partner:35608
BRANCH=samus
TEST=load on samus and keep rebooting and sysjumping and making sure
that we don't falsely go to the sink debounce state.
Change-Id: Ic81fe02be78f3f4ffe00e3e3e378f5befe8545a5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241874
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix a couple bugs that cause problems when executing a power
swap with a poor PD connection.
1) If we are a sink switching to a source and we have turned on
vbus and then get an error, then make sure to turn off vbus.
2) If we are a sink switching to a source and we receive a
redundant PD_RDY, then ignore it.
BUG=chrome-os-partner:32392
BRANCH=samus
TEST=load on samus and connect port 0 to 1 creating a poor
PD connection with a lot of retries and missed responses. with
this change, I swapped power ~20 times with "pd 0 swap power"
and each time it was eventually successful.
Change-Id: Ib6b97961c7e40186a14ca1d2922b2ce6a6598180
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241872
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Set the PD protocol last state to hard reset when executing a
hard reset. This fixes a bug in which if we receive a hard reset
while in one of the hard reset recovery states the last state
doesn't change, which means we don't restart timeout periods and
it is possible to be indefinitely stuck in the hard reset recovery
state until PD MCU reboots.
BUG=none
BRANCH=samus
TEST=when connecting samus port 0 to port 1 we get a very crappy
PD connection and about 1 in 5 times it causes us to get stuck in
SNK_HARD_RESET_RECOVER until a reboot. with this fix, we never get
stuck.
Change-Id: I294462ffa56a804ca613535ab9bdc466175f8066
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241871
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change charge_state_v2 to set the maximum input current limit when
there is no battery present AND the system is not locked. This allows
us to boot without a battery.
Note that using the max input current limit may cause us to overcurrent
our charger, but that's no worse than putting a limit on it and having
the system brownout. Either way you must have a high enough power
charger to boot without a battery.
BUG=chrome-os-partner:35570
BRANCH=samus
TEST=load on samus, remove battery and plug in zinger. check "charger"
has input current limit of 8128mA, and on PD MCU jump back and forth
between RO and RW and make sure system doesn't power off. Note that
without this CL, if you sysjump on the PD MCU it causes input current
limit to reset to 500mA and causes AP to shutoff.
Change-Id: Ie13d97a6b5c0937510cff0cf05fb032898c3b131
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241762
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix some issues with how the battery present flag is reported
up to the host.
If there is no battery presence GPIO or custom function then
errors updating the smart battery info can result in the
battery present flag reporting BP_NOT_SURE and indicating to the
host that the battery is missing. In order to prevent spurious
events require a second back-to-back read of a missing battery
before the host is notified.
When the battery presence does change, the host needs to be told
to re-read the static battery info with EC_HOST_EVENT_BATTERY,
passed to the OS via Notify command to tell the OS to re-execute
_BIF/_BIX method on the ACPI battery device.
When sending these events to the host the battery flags should
first be updated in LPC shared memory so if the host handles
the event quickly it will read the correct updated flags value.
BUG=chrome-os-partner:34011
BRANCH=broadwell
TEST=manual testing on samus:
1) add a console command that allows the smart battery update
function to set batt.is_present to BP_NOT_SURE for a specified
number of update cycles.
2) ensure that when the smart battery update only returns the
battery missing for one update cycle that it does not result in
an event to the host.
3) ensure that if the smart battery update indicates the battery
is missing for more than one update cycle, such that the host is
notified the battery is missing, that it correctly gets an event
to re-read the battery info when it is indicated as present again.
Change-Id: I0da004b991ea1a89b34cd7c0f8f3628b813ffe44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241763
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If a character is received between uart_init() and task_start(), we
shouldn't try to wake console task. Usually this shouldn't happen
because the input shouldn't be floating, but still, the EC should not
crash in this case.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Boot on Glower without servo connected. Check the LED is not
blinking.
Change-Id: I62157c3ecd50b5eca6b09c1cf594b65a605546f9
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241512
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Separate macros for defining delays to turn on and off VBUS on the
Raiden ports.
Tune the delays for Samus to provide extra headroom based off of
measured worst case times.
BUG=chrome-os-partner:34525
BRANCH=samus
TEST=load onto samus. connect two samus' and use twinkie to analyze
time between request and PS_RDY on connect and then on a power swap.
Change-Id: I65cec911e34c22a4aad136423362a3a65bc2ab2a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241761
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Do not request a voltage that is within the deadband where we
aren't sure if the boost or the boost bypass is on.
BUG=chrome-os-partner:34938
BRANCH=samus
TEST=test on samus with zinger. change the deadband to [10V, 20V]
and see that we only negotiate to 5V. change the deadband to
[13V, 20V] and see that we negotiate to 12V. change the deadband
to [10V, 13V] and see that we negotiate to 20V.
Change-Id: Id761aef35eeadfa2ab7d2ca31a48d4324625ab32
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241528
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The AP informs us of the latest update image for a given device through
the EC_CMD_USB_PD_RW_HASH_ENTRY command. If the latest update image is
equivalent to our RW, we don't need to request an update.
BUG=chrome-os-partner:35510
TEST=Manual on Samus. Flash latest RW FW to Zinger. Verify that
subsequent Zinger insertion doesn't trigger the FW update host event.
Insert RO-stuck Zinger and verify that FW update host event is
triggered.
BRANCH=Samus
Change-Id: I300b150b3469e3fe32307e61273880a1a052ac5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241172
Reviewed-by: Alec Berg <alecaberg@chromium.org>
More updates to connection state machine. Adds CONFIG option
for backwards compatible DFP (used on zinger), and change UFP
state machine to debounce CC while VBUS is not present.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=load on samus and zinger and connect a bunch of times. also
test samus to samus connection.
Change-Id: Ia967eb6a17b10aa0c05a30686235fbf8a24e9a7b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240587
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some batteries report 0 charge when their charge level is very low.
powerd has a special interpretation of 0 charge, which causes
low-battery shutdown to not occur. Work-around this powerd behavior by
never reporting 0 charge if our battery is discharging.
BUG=chrome-os-partner:35188
TEST=Manual on Samus. Drain battery to critically low level, verify that
powerd correctly shuts down system.
BRANCH=Samus
Change-Id: I6bd50e038f0e22de7e7de754fa2ea459dc662f35
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241101
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Certain platforms may wish to have a longer shutdown timeout, so make
the timeout a config option.
BUG=chrome-os-partner:35188
TEST=Manual on Samus with subsequent CL. Set config option to increase
timeout, verify that timeout is extended.
BRANCH=Samus
Change-Id: I69feb0d31fdc53e533671dec1e88ba96cc4553c2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240815
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add the charging events to the PD event log FIFO
and add an ectool to retrieve/decode them.
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Run `ectool --name cros_pd pdlog`, verify that
all log entries are dumped and the content matches expectation.
BRANCH=Samus
Change-Id: I65dd5696cc0487856ab42aff24134bcdfa1a8219
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238093
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a FIFO to log important events on the PD MCU and coming from the PD
accessories.
The retrieval of the accessories log from the accessories by the PD MCU
is not implemented yet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32785
TEST=execute "ectool --name=cros_pd pdlog"
before and after plugging Zinger charger.
Change-Id: If96d73e711ff6ad64cfb99bd3e4d2d8f2643f19a
Reviewed-on: https://chromium-review.googlesource.com/238854
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Assuming the dut has red/green battery led and a single power led
CONFIG_LED_POLICY_STD implements the chromeos spec:
* power led on in S0
* power led off in S5
* power led pulsing in S3
* battery led amber when charging
* battery led green when fully charged with AC
* battery led off when discharging
* battery led pulsing red when battery error
BUG=chrome-os-partner:35355
TEST=The Charging led behavior should match the cros spec
BRANCH=None
Change-Id: I645a939ecc2d44d73d2f52b295f9c7e8c923f77b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240705
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Shorten some PD protocol printf's to save flash space and add
port information to a handful of important ones to help find
errors when both ports are in use on samus.
BUG=none
BRANCH=samus
TEST=load onto samus and connect to zinger
Change-Id: Ieecb2a35ebb8c8275c520ad2bd3018e7608b5ecb
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240482
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug causing firefly to disconnect when changing voltage request
too fast.
BUG=chrome-os-partner:35330
BRANCH=samus
TEST=test with firefly and zinger.
Change-Id: I6efb2f6fdd1ff64cee2cc722a538164cca946380
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240460
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:35312
BRANCH=none
TEST=make buildall -j
I added a debug message to nrf51/hwtimer.c to show when the timer overflowed.
"forcetime 4 0xfffff000" overflows to 5.00000000 in 4096 microseconds.
Define CONFIG_CMD_FORCETIME to enable it.
Change-Id: I30835d038ef8cd639565ffb7a638979d95d0a684
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239968
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
When displaying the temps, if the sensor has valid entries to
control the target fan speed, show them. This lets us see which
sensor is the main player in the cooling needed without doing a
bunch of math.
BUG=none
BRANCH=none
TEST=manual
On the EC console:
> thermalget
sensor warn high halt fan_off fan_max name
0 368 370 372 316 358 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 314 328 I2C-Charger-Die
3 0 0 0 0 0 I2C-Charger-Object
4 0 0 0 308 322 I2C-CPU-Die
5 0 0 0 0 0 I2C-CPU-Object
6 0 0 0 301 317 I2C-Left C-Die
7 0 0 0 0 0 I2C-Left C-Object
8 0 0 0 302 316 I2C-Right C-Die
9 0 0 0 0 0 I2C-Right C-Object
10 0 0 0 303 317 I2C-Right D-Die
11 0 0 0 0 0 I2C-Right D-Object
12 0 0 0 316 327 I2C-Left D-Die
13 0 0 0 0 0 I2C-Left D-Object
Then, before this CL:
> temps
PECI : 308 K = 35 C
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
After this CL:
> temps
PECI : 308 K = 35 C 0%
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C 0%
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C 0%
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C 6%
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C 7%
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C 0%
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C 0%
I2C-Left D-Object : Not calibrated
Change-Id: I12bca5826e8a5a3325710fa5d39cec88f1cc95b1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240517
If we're charging on a port and the active port supplier changes, it is
an indication of a significant change. Re-set the port as active, to
give the board-level function an opportunity to reject the port, in case
charging is untenable.
BUG=None
TEST=Manual on Samus. Plug Zinger, verify that 20V is negotiated
correctly.
BRANCH=Samus
Change-Id: I4a530d5bab510498dd9b30f141208ce33b52ef6b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239250
Reviewed-by: Alec Berg <alecaberg@chromium.org>
prevent_hot_discharge and prevent_deep_discharge are near-identical
copies of one another, and can be combined without the loss of any
useful functionality.
BUG=chrome-os-partner:35188
TEST=Manual on Samus. Charge to 2% and boot system with 5V power supply.
Verify that warnings print to console and AP powers down after 30s. Also
pass unit tests.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0f1da5248825a3884f7910babc742dfa7eadf5a3
Reviewed-on: https://chromium-review.googlesource.com/240033
Allow VDO responses to be sent faster by taking out the check for
incoming packet when a VDO is pending. This check isn't needed
because we already check if the PD state machine is busy sending
something.
With this change, the turn around time for responding to Discover
Identity on zinger is ~200us.
BUG=chrome-os-partner:35327
BRANCH=samus
TEST=loaded onto zinger and used twinkie to verify that discover
identity is responded to in ~200us every time. used ectool to
perform remote update on zinger, now takes ~18s (compared to ~55s).
Also, used following bash loop to constantly sent PD voltage requests:
while true; do dut-control "usbpd_uart_cmd:pd 1 dev 5"; sleep 0.3;
dut-control "usbpd_uart_cmd:pd 1 dev 20"; sleep 0.3; done
Used bash loop while updating zinger via ectool. I programmed zinger
~50 times and verified:
- we never missed a PD voltage request
- never got any PD protocol or phy layer errors (no collisions)
- zinger successfully jumped to RW after each (no packets missed)
Note: sending any other PD traffic while programming zinger does
obviously slow down zinger update (~30s with my bash loop above).
Change-Id: I94d1ac01440d096671972fa9c21c149ea432863f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240150
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Make sure the power role and the CC pull resistor match after
receiving hard reset command in the middle of a swap.
BUG=none
BRANCH=samus
TEST=on samus connect left and right ports together with C to C
cable. note that after some collisions and some hard resets, it
eventually stabilizes with one port in SNK_READY, the other in
SRC_READY. without this CL, we get stuck executing a power swap
and our power role and CC resistor get out of sync, requiring
a reboot.
Change-Id: Ia1385eb3a1c503052ad5bfd0d1595ecc096cd5f4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239976
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Avoid multiple power and data swaps on connect by clearing our
local flag for checking our role when we receive a role swap.
This means if the port partner sends a role swap on connect before
us and we accept, then we will not turn around and ask for another
swap.
BUG=none
BRANCH=samus
TEST=connect samus to samus and make sure only one swap on connect.
Change-Id: I2414b5bd5ffc54701b5758047e5d7e51ca3ff596
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239951
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Another fix for redundant requests. This time there can be
redundant requests if the maximum allowed voltage changes,
but we still fall into the samus PDO index and therefore are
asking for the same voltage. This fixes by checking the voltage
value we actually request vs. the max value we can request.
BUG=none
BRANCH=samus
TEST=samus to samus was causing redundant requests and now it's
not.
Change-Id: Ie49add1a42b86de97cee87f9d4637dd0578e2ce3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239950
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Implement the new type-C connect state machine which removes
lock and hold times and adds a debounce time to make sure
CC lines settle before going into the attached state.
This also adds detection of accessories, but doesn't do anything
when an accessory is detected.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=test samus connected zinger and samus connected to samus. make
sure that the connection is always formed. also tested with a third
party with old state machine implementation and formed a connection
every time.
Change-Id: I91a7a6031bc35082cc19d7697142e4aa92ef46f2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238210
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If the EC controls the lightbar and sets the sequence when
it notices the chipset transitioning between states, we can't
make exceptions for cases where we don't want to activate the
lightbar, such as in dark resume. Instead, let's make it a
separate command that we expect from the kernel.
BUG=chrome-os-partner:32181
TEST=build on samus, verify lightbar does correct thing with
manual control set
BRANCH=ToT
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I5dc619cbbf2498e2ef03ce622831b33e14c7c495
Reviewed-on: https://chromium-review.googlesource.com/239215
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
VESA DisplayPort Alt Mode on USB Type-C Standard specifies:
When DisplayPort Configuration is not selected (and the converter is
driving its HPD output low), the converter shall track the current
state of HPD, ready for appropriate indication when DisplayPort
Configuration is subsequently selected.
Not only are we violating specification here but it also causes a race
between enabling DPout muxes to AUX line which in turn causes GPU to
timeout trying to read EDID/DPCD on occasion.
Change adds post_config function for DFPs alternate mode and in the
case of DP it sets the dp_on flag there. This allows attention
function to correctly defer HPD_HI that may accompany 'DP status' VDM
to be queued (deferred) until such time that AUX muxes are enabled
properly.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35219
TEST=manual, using hoho & dingdong
With kernel bootarg drm.debug=0x6 following cases all show these
drm debug lines:
[drm:i915_hotplug_work_func], Connector DP-2 (pin 5) received
hotplug event.
[drm:intel_dp_get_dpcd], DPCD: 12 14 c4 01 01 00 01 00 02 02 06 00
00 00 00
[drm:intel_hpd_irq_event], [CONNECTOR:38:DP-2] status updated from
disconnected to connected
case1: boot connected to external display
case2: attach dongle to external display then samus
case3: attach dongle to samus then to external display
case4: connect/disconnect rapidly on type-C side
case5: connect/disconnect rapidly on external display side.
Change-Id: I40eab797fdd5090c8ad13fae2cd053b740d9a307
Reviewed-on: https://chromium-review.googlesource.com/239420
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
It's not safe to sysjump with a DMA enabled as it can led to memory
corruption after we have landed in the new image before that piece of
hardware is re-configured.
Implement and call dma_disable_all() on all platforms with generic DMA.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:34865
TEST=on various boards, call "sysjump rw".
Change-Id: I2a6b63ff19c2d932a5e31bc375bf468bc8ae5125
Reviewed-on: https://chromium-review.googlesource.com/237340
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
With CL:
5ef45ad pd: Add timeout for HC flash commands.
I thought I'd licked the timeout related issues with flashing dingdong
& hoho.
With further testing however I found I was occassionally hitting the
failure where I couldn't return from 'flash erase' on PD peripheral
prior to the 1 second limit for host command timeout.
That could be remedied by retrying the erase on the host side which
then succeeds quickly. That solution seems non-optimal however.
Additionally, even when erase does succeed in <1sec we have the shared
i2c bus pending. That too is non-optimal.
For those reasons I've decide to return immediately from flash erase
command and instead put the burden of waiting the necessary time on
the host which at least does have some wider perspective on what the
system is attached to and doing.
CL also adds following related changes:
1. corresponding ectool edit to delay 3sec after RW erase.
2. fixup to error returns from hc_remote_flash for timeouts.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=flashing dingdong/hoho via ectool works reliably.
Change-Id: I8fbfb592f760273b26bcb16b67210d569454eee2
Reviewed-on: https://chromium-review.googlesource.com/239253
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Refactor pd_exit_mode to be only a DFP function. Additionally make
pe_init a public function and call it during hard reset.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, using pdsetmode from later patches see proper exit and
resetting of pe struct.
Change-Id: I45afe1f82926f1c32f4d84eb60c65f1f39b19d81
Reviewed-on: https://chromium-review.googlesource.com/236958
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
If two identical suppliers are capable of supplying equal power, select
the port which is currently active.
BUG=chrome-os-partner:34912
TEST=Manual on Samus. Plug Zinger into right port, verify that it
becomes active. Plug a new Zinger into left port, verify that the right
port stays active.
BRANCH=Samus
Change-Id: Ib1baf4bd3f619169f0e31ec509a2fe7dbd8c897e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238766
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove clearing of the type-C pull-up supplier current limit
on hard reset. Hard reset is a PD command and should clear the
PD supplier current limit, but the type-C pull-up is independent
and is still connected, so should not reset.
BUG=none
BRANCH=samus
TEST=load on samus and plug in donette. without this CL, the
charging icon flashes off then on. with this CL, it doesn't flash
and still draws 3A.
Change-Id: I90f87f3970754ca3618d87466412c97acc0a4d6f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239269
Reviewed-by: Shawn N <shawnn@chromium.org>
These USB type-C accessories don't have a write-protect GPIO.
Add a configure flag (CONFIG_WP_ALWAYS) to force the flash
write-protection on the dongles.
Also set the read protection (by elevating RDP to level 1),
so trying to unprotect the flash will trigger a full erase.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35088
TEST=boot Hoho,
check the flash OBR and WRPR registers:
"rw 0x4002201c" / "rw 0x40022020"
and the option bytes write-protect bits: "rw 0x1FFFF808"
dump the logical state with "flashinfo" command.
> rw 0x4002201c
read 0x40022020 = 0xffff0002
> rw 0x40022020
read 0x40022020 = 0xffff0000
> rw 0x1FFFF808
read 0x1ffff808 = 0xff00ff00
> flashinfo
Physical: 128 KB
Usable: 128 KB
Write: 2 B (ideal 2 B)
Erase: 2048 B (to 1-bits)
Protect: 4096 B
Flags: wp_gpio_asserted ro_at_boot ro_now
Protected now:
YYYYYYYY YYYYYYYY ........ ........
Change-Id: I45bbc0bce40ecc174b6b8a1ebacf4f53d2fd372d
Reviewed-on: https://chromium-review.googlesource.com/238893
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
These versions of the queue add and remove methods support
using memcpy like routines to access regions of memory with
specific requirements. In particular, this will allow for
transfers between queues and USB packet RAM on the STM32
which has specific access requirements.
This change also includes an update to the mem* util routines
to make their prototypes compatible with C89 and POSIX
standards.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Test USB Echo functionality on discovery-stm32f072 board to
ensure that queues still function correctly.
Change-Id: I557064d99abfc3e8cfc98099a1d94334a976550c
Reviewed-on: https://chromium-review.googlesource.com/239217
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
When changing a port that is sourcing power to a force sink role,
then make sure VBUS is turned off before going to SNK_DISCONNECTED.
BUG=chrome-os-partner:34036
BRANCH=samus
TEST=test on plankton with samus. verify can change from source to
sink multiple times with no problems
Change-Id: I781f6f4395845f949d00b322e4e87c150aeba187
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233755
Currently, 'ectool usbpd' shows PD task state in numerical format. Every
time we add/remove a state, the number changes, and this makes the
command difficult to use. Modify the command to print the name of the PD
task state.
BRANCH=Samus,Ryu
BUG=chrome-os-partner:34296
TEST=Run 'ectool usbpd 0' with different combination of new/old PD
firmware and new/old ectool.
Change-Id: Ic0daa03e9f7565c1322166713c2cce3b7cb93a30
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237623
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
- Correctly identify certain source ports (ex. c-plug to empty a-receptacle)
- Correct ectool power unit print (mV * mA != mW).
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Connect c-plug to empty a-receptacle, run
"ectool --name usbpdpower", verify that port power role is identified
as source. Also, verify that 5000 mV @ 500mA port correctly prints
2500mW total power.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Icf0850afc570a1056578df9f1a647079a00229b3
Reviewed-on: https://chromium-review.googlesource.com/238235
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Commit f993fe3c refactored pd_vdm_send_state_machine to allow well timed
PD disconnects to be acceptable. This violates specification as VDMs certainly
shouldn't proceed without an explicit contract and mode entry.
CL reverts the logic to make 'ready' VDM in shadow of disconnect an error.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=manual, compiles when disconnect occurs 'ready' VDM transistions to
vdm_state VDM_STATE_ERR_BUSY instead of staying 'ready'
Change-Id: Ic8e96506df365a72053713a806356c4afcfde26d
Reviewed-on: https://chromium-review.googlesource.com/238292
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
For flash commands add timeout so if VDM doesn't return properly host
can receive error message.
Note, for flash erase its performed by page at a cost of 20-40ms
according to datasheet. For hoho/dingdong that leaves maximum erase
time at 40ms * 32 =< 1280ms which is above the host command timeout.
Increasing the host command delay (i2c bus pending) is not an option
and since the erase will complete and subsequent erases will be much
faster do to early out in physical_flash_erase this solution should be
acceptable.
Future CLs could alternatively push the burden of command latency to
host altogether and return EC_RES_SUCCESS in similar fashion to reboot
command.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=manual, if VDM doesn't return by timeout HC command is properly returned
EC_RES_TIMEOUT error code.
Change-Id: I33c515200c2999dd97fdd690a7e900c5548b2d47
Reviewed-on: https://chromium-review.googlesource.com/238290
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Initial VDM implementation had a very conservative 500msec timeout period. This
CL adds the timeouts defined in the USB-PD specification for various commands.
Additionally it adds a state to the vdm state machine to allow proper busy
response handling.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=manual,
Alternate mode and flashing still work. Creating a VDM responder which returns
busy shows retries from initiator after at least 100msec.
Change-Id: I79f5da557ca9faf63d2299bb77009f6d98a782bd
Reviewed-on: https://chromium-review.googlesource.com/235682
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
