The current header location is too large for small SPI flash chips.
Since this value is only used for private EC SPI, it doesn't really
matter what it is. Let's just move it to 0x0.
Note that this doesn't affect shared SPI case, as we need a more
sophisticated packer for that.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Build for Glower and check the size of ec.spi.bin.
Change-Id: I96871d1677999e7cc1c7385b749563b8c09a318a
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241114
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Before enabling GPIO interrupts on boot, we should clear pending
interrupt status to make sure the interrupts don't fire unexpectedly.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Boot on Glower and make sure GPIO interrupts aren't triggered on
boot.
Change-Id: I2729b4a5046063e4ee4c08dcb7084a329bfdf042
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241112
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
EC_CMD_PD_HOST_EVENT_STATUS should respond with
ec_response_host_event_status, not ec_response_pd_status.
TEST=Manual on Samus. Send EC_CMD_PD_HOST_EVENT_STATUS, verify that
resonse is four bytes.
BUG=chrome-os-partner:35510
BRANCH=Samus
Change-Id: I1a38591c7825f7e71c1fde8f3c1cab4be7852971
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241193
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Chipset sometimes needs I2C, therefore i2c_init should have a higher priority
than power_common_init so i2c is available by the time the chipset might be
talking to the battery.
BUG=chrome-os-partner:35502, chrome-os-partner:35173
TEST=There is no "battery not responding" message at startup on veyron
TEST=EC boot takes less than 1 second on veyron
BRANCH=none
Change-Id: Ib10b653decc7703e706d4dd1976abf0fdbc25ac2
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241102
Reviewed-by: Randall Spangler <rspangler@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>
Remove learn mode workaround for backboosting on all new board
revisions, starting with board 1.
BUG=chrome-os-partner:34938
BRANCH=samus
TEST=load on board with board revision 1 and make sure local var
use_bkboost_workaround is 0.
Change-Id: Ieccd7f86baca72d231b5e1491db824e53472eff7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241121
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add backboost detect interrupt to latch if we ever start
backboosting. Provide console command "bkboost" to read if
this has ever happened.
BUG=none
BRANCH=samus
TEST=load on samus and test console command. Note: have not
tested that gpio actually goes high when backboosting
Change-Id: Id7520a0a7777925af1611b8cdc295203d5b36187
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241031
Reviewed-by: Randall Spangler <rspangler@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>
Flashing PD devices works through ectool but only when device has
already entered GFU alternate mode. This CL adds ability to force
that entry for devices with default policy engine does not already do
that.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=manual,
1. On hoho flash RW successfully
ectool --name cros_pd flashpd 4 1 hoho.ec.RW.bin
Change-Id: Idd320cf91644f0c1bff87767ab20049d86aa86c6
Reviewed-on: https://chromium-review.googlesource.com/236959
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
In the samus power sequence steps there is a delay of 500ms when
booting without a battery attached. This delay is currently set
to happen in the S5->S3 transition time, which seems to confuse
sequencing on some boards as we have already set DPWROK and
RSMRST and so this 500ms delay can mess up timing.
Move this delay to happen after 5V is up but before any of the
triggers to the chipset to start sequencing are set.
BUG=chrome-os-partner:31583
BRANCH=samus
TEST=boot on samus pre-DVT and DVT without a battery
Change-Id: I9519c336b121c86183c8368282f6c94b32987c16
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241180
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On samus, set the input current limit ~200mA lower than the
value we want to accomodate hardware inaccuracy.
BUG=chrome-os-partner:34938
BRANCH=samus
TEST=load on to unit and verify using "charger" command on
ec console that the input current limit is 192mA less than
expected.
Change-Id: Ia6f82a1a622975715bd36c8c2a23e9677a6f18f0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240751
Reviewed-by: Shawn N <shawnn@chromium.org>
Update the thermal table to account for Tj_max changing from 100C to 105C
so the thermal shutdown temperature is 104C instead of 99C.
The warn and high(prochot) values are left the same as we do want to try
and throttle with some room before the critical threshold will pull power.
This is mostly a concern in the factory where they may run without active
cooling during MLB testing.
BUG=chrome-os-partner:35483
BRANCH=samus
TEST=build and boot on samus
Change-Id: Iae55d7ca41f81e6b7250585be374fb8dd1b6533c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241011
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Increase this timeout to 60s to allow powerd to cleanly shutdown the
system, if we boot with a low-power charger and low battery.
BUG=chrome-os-partner:35188
TEST=Manual on Samus. Deplete battery to 2% and boot system with 5V /
500mA charger attached. Verify that OS powers down before critical
battery shutdown occurs.
BRANCH=Samus
Change-Id: I9429d05efad506a855507bfb5b76de41df2aac1e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240816
Reviewed-by: Alec Berg <alecaberg@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>
The RTC delay is always less than a day (see the assert at the beginning
of set_rtc_alarm), so remove the useless module to save a few bytes of
flash.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
and see the zinger firmware is smaller by 16 bytes
(more than the 8 bytes I need to submit the following CL)
Change-Id: If0374ff5897f13e69574018d2123428075b2264e
Reviewed-on: https://chromium-review.googlesource.com/240564
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Put each assembly helper function in its own .text.__funcname__ section,
so the linker can remove the unused ones.
Also remove a few entrypoints used only by deprecated ABIs.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
check the firmware size and see we are saving 88 bytes on Zinger.
Change-Id: I6714da671c3449220652780d47993d6c919c331c
Reviewed-on: https://chromium-review.googlesource.com/240582
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: 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>
The check for overflow was originally in __hw_clock_source_read()
If it got interrupted, it would frequently see an overflow, because
"prev_read" would be less than "now".
1 - Use the comparator to check for overflow.
2 - Only check for overflow in the interrupt handler.
BUG=chrome-os-partner:35312
BRANCH=none
TEST=make buildall -j
use the keyboard code to type
use a console command "forcetime", to force the system time to overflow soon.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I7005724222289ba967e89af0ce8b9ef8f90a4ae4
Reviewed-on: https://chromium-review.googlesource.com/239967
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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
If the RO firmware has a different view of the protection than
the RW copy, we should not change the option bytes (write protection
settings) in RW else we will trigger a reboot loop : RW protects and reset,
then RO unprotects, resets and jump to RW, RW protects and reset again ...
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35383
TEST=craft a firmware image whose RO partition doesn't include commit
42d0104 (no virtual WP, no RDP set) and RW partition has everything
including this patch, see that HoHo no longer reboots in a loop.
Change-Id: I4cbdbf25a96cb6fb7cbabc7f2d1dc76d3a2a9e36
Reviewed-on: https://chromium-review.googlesource.com/240561
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds some temp limits from the motherboard die sensors to
use in determining the desired fan speed.
I'm also bumping the minimum PECI temp up a bit, since it varies
rapidly. At room temp the motherboard sensors will generally
request a little bit of cooling, but in cool environments it's
likely that the PECI changes will become the major annoying factor.
BUG=chrome-os-partner:34789
BRANCH=ToT,samus
TEST=manual
Watch/listen to fans. They shouldn't turn off and on as much.
Change-Id: I309132a053a052b456808e42261844dbf6442675
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240435
Reviewed-by: Sameer Nanda <snanda@chromium.org>
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
Increase discharge timeout delay to 275ms, which is the new
tSrcSettle time. Also, fix fault condition so that we reset
immediately upon receiving a fault.
BUG=chrome-os-partner:35330
BRANCH=samus
TEST=load on zinger and test with firefly many 20->5V transitions
without a discharge error
Change-Id: I13bc5d77889a37390603c6922c84b264c77d79ac
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240399
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change the reads of output enable and discharge gpio's to use
the output data register (ODR) instead of reading input data
register (IDR) because we are really intending to read it's output
state, what we have set it to.
BUG=none
BRANCH=zinger
TEST=make -j buildall. load on zinger and use it normally.
Change-Id: I308bbb659aa26a9d0bca8caef6d1257fc1146ae9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240398
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
MIPS host CPU does not access IO registers using a separate address space.
Remove for support of LPC for this host architecture.
Confine x86 function to Intel Architecture only.
BRANCH=none
TEST=Compile: Test on ARM, MIPS and X86: using emerge... ec-utils.
BUG=chromium:443783
Change-Id: I9d4276ec3588037adfcff96e596bbe8be74f22fd
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236687
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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
If we discharge directly the output voltage from 20V to 5V under load,
an undershot happens and we dip below the 5V UVP threshold.
So when doing a down voltage transition from 20V to 5V, split it into 2
steps : a 20V->12V transition then once we are reached 12V, a 12V->5V
transition.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33794
TEST=connect Zinger to a Firefly and an electronic load.
Using Firefly, ask for 20V->5V, 12V->5V and 20V->12V
transitions, check the VBUS waveforms on the scope.
Change-Id: Ie1e091ae6f1fee1fb7d4e3bd72edbe7491acd5ea
Reviewed-on: https://chromium-review.googlesource.com/229732
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
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>
To ensure we respond fast enough to the Discover Identity VDM
(which timeout after 30ms), we need to pre-cache the RW hash at startup.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35327
TEST=plug Zinger to a PD sink and check the PD protocol trace on Twinkie
Change-Id: I9decdff358dd1ab9ac373ce8bfdd0402f5e21f04
Reviewed-on: https://chromium-review.googlesource.com/240080
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
