Change the ENTERING_RW gpio name to match other boards so that common/system.c
sets the gpio automatically when jumping to RW.
BUG=none
BRANCH=samus
TEST=make buildall
Change-Id: I8290462a73d99dad0a9f5b8de7ea1c0edb56876e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236964
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This addition allows the AP to query whether the PD device is currently
running from RO or RW FW.
BUG=chrome-os-partner:34599
TEST=Manual on Samus. Run 'ectool --name cros_pd infopddev 0' and verify
that correct RO/RW status of Zinger is printed. Verify that the output
matches the index printed by "pd 1 hash" on samus_pd console.
BRANCH=Samus
Change-Id: I4266cae931f5c7855ca0531717c4a18b138b2d62
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236771
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In order to reduce flash size on some constrained boards this CL
modifies the GPIO macro in gpio_list.h to change the name field from
that listed 'name' to the concat of 'port' and 'pin'.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34489
TEST=manual
1. build with and without CONFIG_COMMON_GPIO_SHORTNAMES
See >500 bytes savings with config option
2. See reduced names for gpioget
Change-Id: I6ed2c1d16aae5923fdf47a1b2dbb2362598a19e0
Reviewed-on: https://chromium-review.googlesource.com/236766
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
According to specification, a DCP port is only required to provide 500mA
@ 4.75V, though actual supply limit can vary upward significantly. Set
the current limit on DCP ports to 500mA to reflect this reality.
BUG=chrome-os-partner:32003
TEST=None
BRANCH=Samus
Change-Id: I46e25b44baaa41ddf173880e52d7485d952ebf23
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236772
Reviewed-by: Alec Berg <alecaberg@chromium.org>
STM32 seems to actually measure the rising and falling time of the I2C clock, so
if one uses a really small resistor the timing will go faster than with a bigger
resistor.
This commit makes it so the I2C frequency is limited to max 100kHz (respecting
the spec) no matter what size resistor (essentially we assume 0 rise and fall
times). While this will make stuff slower on boards with big resistors (where
they might have been under 100kHz anyway) this is the best compromise (since the
spec does not specify min frequency) without getting config defines for the
fall/rise times.
The TSCLH of some boards would be too short with the recommended timing
settings from spec, so increases the TSCLH would be better for everyone.
This patch does not touch the higher frequencies since the rise and fall times
do contribute a lot more to clocks, if the same method was used for those
frequencies, the speeds would have to be a lot slower.
BUG=chrome-os-partner:34375
BRANCH=None
TEST=on any EC, note how frequency does not go above 100kHz
TEST=As per tSCL = tSYNC1 + tSYNC2 + { [(SCLH+1) + (SCLL+1)] x
(PRESC+1) x tI2CCLK } from datasheet
Change-Id: Ibbeecac7f3da1b22d2ba3bca29ee3c17bfe997f5
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix bug causing tap for battery not to work in G3 when AC
is attached. Problem was that the lightbar was being held
in reset and would not light up.
BUG=chrome-os-partner:34722
BRANCH=samus
TEST=tested on samus with AC attached and unattached in S3
and in G3, tap for battery lights up the lightbar. Also
verified that plugging and unpluggin AC in S3 and G3 causes
lightbar to light up.
Change-Id: I0fbd989399d372d287467200512bbdf2551884d3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236560
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
We actually need to care about x, the PRI register is actually a list of
registers (and we have code that uses some of the later ones).
BUG=None, discovered while chrome-os-partner:33451
TEST=Change priorities of irqs(like UART over GPIO(spi_event)), note how they
actually work and override each other as told
BRANCH=None
Change-Id: I9f5bf7ba9d4211f782ff260fbce17deb7c53a31f
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236087
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
UART with no DMA is likely to drop RX characters when system is busy. This is
because the UART interrupt is lower priority than the spi_event GPIO interrupt.
We can work around this by enabling the DMA, so no UART interrupts are required
while recieving, since everything will happen in DMA.
This replaces the other patch(CL 236089) which suggested changing UART IRQ
priority.
BUG=chrome-os-partner:33451
TEST=get firmware to poll the EC for keyboard presses, type really fast on the
keyboard, note how no character is lost anymore
TEST=faft dev mode test now passes, faft is able to type "kbpress $(insert args
for Ctrl+D) 1" correctly without missing characters because firmware is loading
the EC with keyboard polls
TEST=While '+'s are scrolling on the EC terminal paste something big like this:
"kbpress 1 1 1
kbpress 1 1 0
123456789012345678901234567890
". Both kbpresses should be interpreted/executed properly(no "kbprss") and there
should be no missing digits in the echo back.
BRANCH=None
Change-Id: I01d4eaa23f10f07083875846ea48c34da2e2f6ce
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236365
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the EC is busy enough to start missing RX characters an ORECF might come
(Overrun error), we never check for this bit, so that means the interrupt
handler will be called in a loop because it never clears that bit.
This disables the overrun detection feature.
BUG=chrome-os-partner:33451
TEST=get firmware to poll the EC for keyboard presses, type really fast on the
keyboard, note how system does not watchdog reset anymore but loses the
occasional character instead.
BRANCH=None
Change-Id: I711483768e4ba80aaeb4a324c7dee790b3a23682
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236088
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Modify board_set_active_charge_port to return status indicating whether
the selected charge port was rejected. If rejected, zero out its
available charge and attempt to select a different charge port.
Also, reduce the length of related console prints.
BUG=chrome-os-partner:34677
TEST=Manual on Samus. Plug C-to-Arec into port 1, verify that charge
manager does not select port 1 as active and charging icon is not seen
in OS.
BRANCH=Samus.
Change-Id: I56e3337f90c04b93ef7cc9873af6ee0f4b1ffc7d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236361
Reviewed-by: Alec Berg <alecaberg@chromium.org>
According the STM32L RM, when writing to RCC_CFGR to change HSI or MSI
clock source, SWS bits of RCC_CFGR register have to be checked if the
new clock source is taken into account. Also, when writing ACC64 bit and
LATENCY bit to FLASH_ACR register, those bits have to be checked too.
Also changed in this CL is to disable MSI if HSI is enabled, and disable
HSI if MSI is enabled.
BUG=chrome-os-partner:32936
BRANCH=none
TEST=passed suspend_stress_test on big, blaze and nyan
Change-Id: I3ec660d149ecdec3ca3097239612bf2c542d0548
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/234490
Reviewed-by: Kary Jin <karyj@nvidia.com>
Tested-by: Kary Jin <karyj@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 400d9dca8c41f74cf0c2587e881707b80bb17d3d)
Reviewed-on: https://chromium-review.googlesource.com/236050
Allow CONFIG_CHARGER_MIN_BAT_PCT_FOR_POWER_ON to be defined at the board
level to be the minimum battery percentage required for power-on. If the
battery level is below the threshold, or if the battery is missing,
power button presses will be ignored.
BUG=chrome-os-partner:31127
TEST=Manual on Samus with subsequent commit. Verify that AP continues
to boot normally when charge level exceeds
CONFIG_CHARGER_MIN_BAT_PCT_FOR_POWER_ON. Verify that power button
presses are ignored when the charge level is below the threshold, and
we return to G3.
BRANCH=Samus
Change-Id: I0ff3f7ddabf38080332470e172c8b2e307bf1655
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236021
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Added check for collision just before transmitting on CC line.
To check for collision, RX monitoring is left on all the time
(except when in the act of receiving or transmitting, or in
between receiving and sending a goodCRC), and a
simple check for RX transmission started is used to see if the
CC line is idle or not.
RX monitoring is also changed to only trigger on 3 edges within
20us, as per the PD spec.
When a collision is detected by seeing that CC is not idle, the
transmitting packet is dropped.
BUG=chrome-os-partner:30135
BRANCH=samus
TEST=load onto samus and zinger. make sure we negotiate and make
sure custom VDMs succeed. enabled pings and made sure we stay
alive with pings for a few min.
Also added code to pd_rx_handler to toggle a test point on EVT
board to verify the timing of when we get RX interrupts:
Change-Id: I22d172163319437d3d901e019eda79d4d592f6b8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226118
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Cortex-m0 we supports 2 bit priorities for the NVIC, yet we clear with 0x7 (3
bits). Change so we now clear with 0x3
Also limited priority to the max available (so we don't set extra bits we don't
want or modulus the priority, otherwise setting priority 8 will actual give you
priority 0) in both cortex-m and cortex-m0.
BUG=None, discovered while looking at the code
TEST=Should be no functional change, NVIC priorities should still work the same.
BRANCH=None
Change-Id: I31ba041449cae96983753b297e2631c310a406c4
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a rate limiter to host commands so that a host that is continuously
sending host commands doesn't watchdog the EC.
BUG=chrome-os-partner:33905
BRANCH=samus
TEST=loaded onto samus and tested remote update of zinger 10 times.
also tested EC + PD software sync.
Change-Id: Ia024179c46b2180ee97ea1902de343306142311c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235530
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to reduce flash size on some constrained boards this CL
modifies the GPIO macro in gpio_list.h to change the name field from
that listed 'name' to the concat of 'port' and 'pin'.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34489
TEST=manual
1. build with and without CONFIG_COMMON_GPIO_SHORTNAMES
See 897 bytes savings with config option
2. See reduced names for gpioget
> gpioget
0 E6
0 F2
1 B0
Change-Id: Ife1e1e2bcfa620ba87fe6c1ce2b47fe258c46514
Reviewed-on: https://chromium-review.googlesource.com/234587
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Change backboosting workaround into a new extpower task. This
new task runs exactly what used to be run in a deferred function,
but at higher priority than charger task, which means that i2c
transactions from this new task will occur before charger task
i2c transactions.
This fixes the EC watchdog when writing PD device firmware
because the hooks task is no longer blocked on trying to grab
the i2c mutex for talking to BQ.
BUG=chrome-os-partner:33905
BRANCH=samus
TEST=loaded onto samus and tested remote update of zinger 10 times.
Change-Id: I01d259857aefc6bf456ab217bf46536237bc4008
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235862
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
.config is a file in build/$BOARD that contains all defined config
variables. It is used by external programs to know what features
have been compiled for a specific board.
BUG=chrome-os-partner:33908
TEST=Check .config is generated properly. Check content, check
it updates when new .bin are created.
BRANCH=none
Change-Id: If93c2a393867a9fcb60841e282d8e6b933f3dfec
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233888
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ryu sensor hub has asymectric RO/RW images. The first one is very limited
(not i2c master, no sensor drivers, gesture recognition).
Image size is alter to offer more space for the RW firmware image,
compiled with ryu_sh board.
To write RO image and basic RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w /tmp/ryu_sh_loader/ec.bin
To write the expected RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w -i EC_RW:/tmp/ryu_sh/ec.bin
BRANCH=ToT
BUG=chrome-os-partner:33908
CQ-DEPEND=CL:231970,CL:233233
TEST=load on Ryu, confirmed limited operation.
Change-Id: Ib976e2b048935adfb9b2b072c071db5be2bc1c09
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231984
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add high (and low) battery temperature warning which sends host
event to AP. After 30 seconds of out of range temp readings force
shut off AP and hibernate the EC.
BUG=chrome-os-partner:27641, chrome-os-partner:33111
BRANCH=samus
TEST=make buildall, and write unit tests to test this condition.
Change-Id: I95b7d9d753c17e4b76218a9845aa63dd1b96a500
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235645
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On samus it is possible to have AC plugged in but have the battery
discharging. So, add a new variable to charge state machine for
battery charging status and use that where necessary. For example,
the low battery shutdown code should now be based on whether or
not battery is charging rather than if AC is present.
This also changes the hibernate behavior when battery is low. The
change is to wait 30 seconds in G3 of low battery with no charging
before hibernating because for some chargers, like a USB PD charger,
the charger may increase it's current limit after a little bit of
time.
BUG=chrome-os-partner:34485
BRANCH=samus
TEST=test on samus. use low power charger and make sure that
ectool battery shows the "DISCHARGING" flag. use zinger and see
"CHARGING" flag. also use power_supply_info to make sure that
the battery state accurately reflects reality.
Change-Id: I8ac0267dd393071c4ca1fa24fbc9a13bf27848a9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235491
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
burn_my_ec is an utility that flash an image embedded in its code.
We can not compile it as part of ec-[dev]utils, because we have
devices that firmware should be build as part of chrome-ec package.
Remove burn_my_ec, barely used.
Split the makefile to build just the host utility when requested.
BRANCH=ToT
BUG=chrome-os-partner:32025,chromium:408713
TEST=Check that files are stil built when needed and
not when utils-host is invoked.
Change-Id: I3fabe16067d57c74ae36b05138f4c6fd2483c7c4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233347
Fix bug where if we have a non-PD aware charger, we constantly send
host events to notify EC of an input current limit change. This was
unintentionally broken when adding code to constantly monitor the
CC line pull-up strength and adjust the current limit accordingly.
BUG=none
BRANCH=samus
TEST=plug in a non-PD aware charger and make sure it sets the correct
input current limit and that it is not constantly sending host events
that the limit has changed.
Change-Id: I7d835769ebc768043a9a46f50721987dce0384f5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235414
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
For the transmitter to clear CHARGE_DONE, charging must be enabled.
Therefore, we should always enable charging when the lid is just closed.
BRANCH=ryu
BUG=None
TEST=Test on Ryu p1.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I44f3d7c9e413a63be66ccf9695fea5411b2067b6
Reviewed-on: https://chromium-review.googlesource.com/231121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After receiving more info from the manufacturer, it appears that
since we're using closed-loop feedback to drive the fan we can
turn it at whatever speed seems to work.
While we're bikeshedding over the startup noise, let's put the
start/min speed back to 1000RPM to help distinguish the startup
chirp from the fan-is-running-now noise.
BUG=chrome-os-partner:32757
BRANCH=ToT,Samus
TEST=make buildall -j
Watch fan speeds while doing things. It still makes noise, but it's
quieter.
Change-Id: I5c21bf9021e4110f31c6dded78852347c4eb6119
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234755
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
If a PD charger is attached and immediately becomes our charge port, we
will request PD_REQUEST_MAX twice. Remove this needless re-request by
storing the previous request, and only re-requesting from
PD_STATE_SNK_READY if the request has changed.
BUG=chrome-os-partner:34168
TEST=Manual on Samus. Plug Zinger as lone charger, verify that 20V @ 3A
is requested only once. Plug second Zinger in second port, verify that
5V @ 3A is correctly requested.
BRANCH=samus.
Change-Id: Ife6fa9788e97a045edbca5d83933af57cd0ea91d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234701
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove common code across all PD policy layers to select the requested
voltage and build a Request Data Object (RDO).
BUG=none
BRANCH=samus
TEST=Load onto samus and connect zinger. Make sure we request the right
voltage (first 5V, then after initial contract is made, 20V). Make
sure input current limit is set appropriately by checking limit on EC
console using charger command.
Change-Id: Ic6bda5e23b2d7b7d710ffdf085e7fbc1b0c3add9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233673
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Turn on PP5000 when AC is plugged in in G3 so that the PD
MCU can accurately measure the CC voltage.
BUG=chrome-os-partner:33909
BRANCH=samus
TEST=test with various type-C chargers. verify that in G3 the
pp5000 rail is on when AC is plugged in, but off when AC is
unplugged
used reported battery current to estimate that turning on
PP5000 rail in G3 consumes an extra 30mW of power, but that
shouldn't matter much when AC is connected.
Change-Id: I3cdd2aaf3e7688d69a65e5d11e38e5b9cf16e703
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233734
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The new board will move AC_PRESENT to another pin in order to avoid the
[1.052524 Overriding AC_PRESENT with KB_IN00 on EXTI8] problem.
BUG=chrome-os-partner:34024
TEST=EC should react to AC events
BRANCH=None
Change-Id: I5c1110f10a3ed2704593c749cef35ab73fceb3e8
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234586
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-by: Jerry Parson <jwp@chromium.org>
This exposes the pd_exchange_status() function and lets it
return the charge port that the PD reports, so that the lightbar
TAP sequence can decide which direction to display.
BUG=chrome-os-partner:32227
BRANCH=ToT, samus
TEST=make buildall -j
Change-Id: I78b57fbeaaf38fee15c86eca4d90abce77e2f722
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232092
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The power sequence doesn't meet the spec from Intel.
We should delay about 10ms between VccSUS3_3 and RSMRST.
BUG=chrome-os-partner:34411
BRANCH=samus
TEST=build and boot on samus
Change-Id: Ib35e9dfdcfa4cfde2440f85fbeae6ee878465949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234404
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If override charge is selected on a port currently acting as a charge
source, but the attached device is also capable of acting as a source,
request a charge role swap and initiate a pending delayed port override.
If the role swap completes successfully and a charge source is found,
the selected port will become the override port. If the role swap fails
or no charge source is found within 2 seconds, the delayed port override
will be lost.
BUG=chrome-os-partner:28343,chrome-os-partner:31195
TEST=Manual on Samus. Connect two Samus units together through charge
ports.
"pd 1 swap power" - put port on test device into source role
"chgoverride 1" - set charge override, verify that role swap takes
effect and charge manager selects PD charge source, 900mA @ 5V
Disconnect charge cable, verify that charge manager goes back to not
charging.
BRANCH=Samus
Change-Id: Iadcc4dc98631661f254245eeff18973df517f652
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231900
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Samus USB ports can't actually act as UFPs, so open switches when in
UFP mode.
BUG=chrome-os-partner:32003
TEST=Manual on Samus. Connect two Samus units, run `pd 1 swap data`,
verify that switches are opened on switch to UFP. Unplug samus and
connect a USB 2.0 device instead, verify that ports are again closed.
BRANCH=samus
Change-Id: I9e1ca58089caf29e419698c8426bf8b72500833a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233711
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The new hard reset recovery state was endlessly sending hard resets.
Added in hard reset counter to cap the number of hard resets for
a sink.
BUG=none
BRANCH=samus
TEST=test with non-PD type-C charger and verify that we only send
two hard resets and set the appropriate input current limit after
the hard resets.
Change-Id: I95a3739be28ad2a5fed245aad021bcd6d51d94b1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233754
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When we receive source capabilities packet from a source, if we are already
the active charging port, then we know we can request max power, otherwise
request vSafe5V. Normally, when you first attach a charger, the port won't
already be the active charge port when we receive source cap. But, if we
already have a power contract with a source and the source sends us new
source capabilities, then this comes in to play.
BUG=chrome-os-partner:34168
BRANCH=samus
TEST=test with plankton. when you press the 5/12/20 V buttons on plankton
it changes the source capabilites of plankton and sends a new source cap
packet to samus. thus, without this change, when you press one of the buttons
twice, the second button press causes us to negotiate to vSafe5V instead
of the max power. with this change, the requested power stays constant
when plankton re-issues source capabilities.
Change-Id: I3cc1e6b109117566f59de07762fd1af9adec05bf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233753
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Do not allow remote PD firmware update of a device that is providing
us power when we have no battery (or else we will lose power).
BUG=none
BRANCH=samus
TEST=attach a zinger that has an old FW to samus with no battery and
see that host attempts to update FW but PD MCU does not allow it.
Change-Id: Iaf816dc44017d9c65a2b248ea8536d7c03898910
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233752
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The task based approach made sense when it looked like
there would be a case closed debugging task to handle
multiple bridges (SPI/I2C/USART...). I'm not convinced
anymore that that task will be needed, so this
simplification seems good.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Ic431c287c28d10252246fe9f507d9c5fcc64a077
Reviewed-on: https://chromium-review.googlesource.com/232733
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This allows the USB SPI bridge to be controlled from the
host at a larger timescale than a single SPI transaction.
This allows the host to signal that many transactions
will take place and that the device should keep the SPI
bridge enabled across them. This allows the device to
hold the AP or other possible user of the SPI bus in
reset while the bridge is enabled.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Ifd6f96b0ff47f35d853735d44e255a205b0e677a
Reviewed-on: https://chromium-review.googlesource.com/232732
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
