When long power press is canceled, we need to cancel the current running
timer. Otherwise, if the power button is pressed again before the
current running timer expires, the next deadline won't be set. This
causes the chipset task to wake up too early and miss the subsequent
long power press shutdown.
BUG=chrome-os-partner:31372
TEST=On Ryu, long press following a short press shuts down the system.
BRANCH=None
Change-Id: I9855b146d430e5babda727fcb429c516ca91e48e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212560
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Passing the "--usb" argument will now utilized case-closed
debugging for flashing the EC. Currently this is only supported
for the samus LM4-based board.
BRANCH=none
BUG=none
TEST=verify that when the case-closed debugging flag is set, the
alternate openocd config file is used for samus, and an error is
thrown for all other boards
Change-Id: I0642bc2e9c2657cd8dbd83ee6e282365275d665a
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
During flash erase operation, read is stalled and thus interrupt might
be serviced later. This can cause PD communication to fail and thus the
board reboots if there is no battery. Print a warning message in this
case.
BUG=chrome-os-partner:31127,chrome-os-partner:31207,chrome-os-partner:31362
TEST=Boot Ryu, on software sync, see warning message before board
reboots.
BRANCH=None
Change-Id: If327a4f533fd2dfa83f92531148bd52ace927e03
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212264
Reviewed-by: Alec Berg <alecaberg@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>
Certain i2c host drivers don't allow one to snoop the byte
stream to abort a transaction. Allow those devices to make
forward progress by sending out the '0xec' byte for any
requests coming through after an EC host command error.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Ran on ryu. Allowed passthru probing which normally hung
the system because of there not being a passthrue device
on ryu -- error returned. Instead the command returns
successfully by returning 0xec for the unfilled bytes.
Change-Id: Ibcab5ade1f727f3852995437105eb9fa693caadf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212165
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c_packet structure wasn't always being initialized
in the error path. It's possible to crash the EC if the first
command processed hit this error path. Instead, unconditionally
set all the i2c_packet fields.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: Ic6d7c63f61d59c4449fbb20f656c1bfb835db8be
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212164
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The wrong define was being used when checking the I2C ISR status.
The wrong define just so happened to be the correct bit.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: I6c7aad34f5e7c7ace4db4442147023346b6285bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212163
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>
Seems like STM32_SPI_CR2_FRXTH from 5d208b99(STM32F0 SPI Fixes) was not enough
to "disable" RX FIFO from the F0 series. There were still a few bytes stuck in
the FIFO just after a command with a long sequence of 00 bytes.
This increases the dummy bytes read just before a DMA transfer to 4(size of the
FIFO).
BUG=none
BRANCH=none
TEST=Veyron with the new EC should survive the AP booting. ectool version will
work right away after boot. This change should not affect other STM32 chips
because reading dummy bytes from an empty register is essentially a NOP.
Change-Id: I812208622a75ecce82433eb6c12595fee3c1428b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212297
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add back the test but only enable USB PD tasks for usb_pd test. This
should ensure that we do not break existing tests.
BUG=chrome-os-partner:31200,chromium:402335
TEST=make buildall
BRANCH=None
Change-Id: I4daa41a96a1067362b2c40a2a09fce733843bdff
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211923
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 default to request 20V.
BUG=none
BRANCH=none
TEST=Load onto a firefly. Plug in a zinger, make sure 20V LED
lights up. Press other buttons to make sure we can change the
requested voltage to 5V and 12V.
Change-Id: I3a3e63a6d0e4f01b9fe7c730468da75ad6783f41
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211872
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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
* Changed chip in build.mk
* Renamed the Port H pins
* Switched to 32bit timer
* Remapped UART DMA Channel
BUG=None
TEST=Flash the new chip; UART Debug, SPI HC, I2C Battery should work. Everything
else should work (besides power usage)
BRANCH=None
Change-Id: Ia73f3f6b4e8b7b42af4dfa592b7ff435ee379206
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210522
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-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>
Change USBC port 1 PD comparator to use window mode, which
uses COMP1's non-inverting input for COMP2's non-inverting
input (pin PA1). This allows us to free up pin PA3 and PA7
for the next build.
BUG=chrome-os-partner:31215
BRANCH=none
TEST=make sure PD communication works on both ports by plugging
in a zinger. Then set gpioset USB_C0_REF_PD_ODL 1, to change
comparator voltage to 1.5 V and verify that neither port works.
Then gpioset USB_C0_REF_PD_ODL 0 and gpioset USB_C1_REF_PD_ODL 1
and make sure that both ports work. This proves that both ports
are using USB_C0_REF_PD_ODL as the comparator value (PA1).
Change-Id: I6e1e5606af43196b04c84417552002b063aa4134
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211416
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
HAS_TASK_HOSTCMD is not a good indicator that we intend to use I2C Host Commands
On platforms such a veyron we use an STM32F0 with SPI HC for example however
i2c-stm32f0.c was very eager to still provide host commands via I2C.
If one wants to use I2C host commands they need to define
CONFIG_HOSTCMD_I2C_SLAVE_ADDR anyway, so the presence of that is a better
indicator.
The boards that want I2C host commands are ryu and samus_pd.
veyron/pinky needs SPI host commands, so this patch makes this case possible.
The rest of the boards that use STM32F0 do not have HAS_TASK_HOSTCMD set.
BUG=None
TEST=make buildall -j
BRANCH=None
Change-Id: Ia5561afdc6e72019c24c5c4b775944b2b88cb950
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211434
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
The STM32F0 has a fancier SPI than the L1 series we've been using so far.
Notably it supports 16 bit data packing. This mode is activated automatically
by reading/writing to the SPI_DR register as 16 bits. We do not want this
feature since we only do 8 bit operations. This change prevents a misalignment
of the data where the MCU thinks it's doing 16 bit transfers and we want 8 bit
transfers.
Another unwanted feature is the FIFO. We rely on DMA and some buffers instead.
Keeping the FIFO enabled causes extra characters. The way this patch disables
the fifo is by changing the FIFO reception threshold to only 1 byte (which is
the same behavior that L1 has with no FIFO). Setting the FRXTH bit on the L1
chips should not affect anything as that area of the register is reserved.
BUG=none
BRANCH=none
TEST=Try SPI on both STM32L1xx(preexisting support, should not be broken) and
STM32F0(new support/veyron)
Change-Id: I90dc6bb8a82881e70058443591acaebc44ba982b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211476
Reviewed-by: Doug Anderson <dianders@chromium.org>
Added a check for if we are in RO and write protect screw is
present which will stop the PD task to prevent PD communication.
By default this check is disabled since the p2 samus units do
not have access to WP screw. This check will need to be enabled
for EVT.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=enabled the check, loaded on a p2 samus, and verified
that in RO, the console prints out "PD not allowed" and there
is no communication with an attached zinger. Then ran "sysjump
RW" and verified that power negotiation with zinger succeeded.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I5007db659d8b057431426157a2150127b97a7b3f
Reviewed-on: https://chromium-review.googlesource.com/211020
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
In order for the AP to access the SPI part one needs to drive
PD_DISABLE_DEBUG to 1. While all the closed-case debugging is being
worked out set this signal 1 by default so that the AP can boot.
BUG=chrome-os-partner:31149
BRANCH=None
TEST=Built and flashed on ryu. SPI works from initial poweron.
Change-Id: I1fdb0457da9db07063f86959d9eb969e3bcd83ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211141
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
