The interrupt handler is hardcoded to I2C1. We should choose between
I2C1 and I2C2 based on I2C_PORT_EC.
BUG=chrome-os-partner:30707
TEST=On Ryu, ectool hello and see ACK.
BRANCH=None
Change-Id: I07055b0ee7459e6cac5585737e200ff2d5814a34
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209960
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
for interface specific requests, the interface number is equivalent to
(wIndex & 0xff). this corresponds to ep0_buf_rx[2], since the setup
packet has format: bmRequestType (1), bRequest (1), wValue (2),
wIndex (2), wLength (2).
BUG=none
BRANCH=none
TEST=verify stm32 does not panic with multiple interfaces
Change-Id: Ied7750035f87fa81f9a6c03c6e73ae606c110398
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209903
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Adds dual USB-PD port support for samus. Both ports are in dual-role
and can perform either role.
Both ports work fine when only one of the ports is in use. But,
still having problems with PD errors on the lower priority port (port
0). If you have a charger plugged into port 0, and a type-C USB dongle
plugged into port 1, then port 1 has higher priority, and in the
SRC_DISCONNECTED state, every 1.5 seconds when it sends source cap
packet, we occasionally drop pings on port 0, which results in a
lot of start/stop charging.
BUG=chrome-os-partner:28585
BRANCH=none
TEST=Tested on samus to make sure both ports work when I
plug in a charger and a type-C USB dongle with a pull-down on the CC
line. Tested on plankton and zinger to make sure PD works as expected.
Change-Id: Ie7bde3e258f5cd23a0b82b626c0993a45b0df074
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200750
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Increase RAM_SIZE for all stm32f07x chips to 16kB to use all of
on chip SRAM.
BUG=none
BRANCH=none
TEST=added 4000 byte array, verified in ec.RO.map that we are using
the new RAM space (bss size over 0x2000), loaded on samus and
verified that we could read and write to the 4000 byte array.
Change-Id: Ided3ce7c5fb353c9c37a01e6ed64f03786717e9b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209847
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Check for warm reboot before initializing ADC. Part of the initialization
process involves calibration of the ADC, which can only be done when the
ADC peripheral is disabled. This fixes a bug on samus_pd where jumping to
RW causes a watchdog because ADC reads hang.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=on samus_pd, without this change running sysjump rw causes us to jump
to RW and then causes a watchdog. With this change sysjump rw works. Also
verified that PD communication works in RW, which means ADC channels are
being read correctly after jumping to RW.
Change-Id: Iaa41da4795c3d15a6db56b0d715e36c29417d9b6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209331
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Only one EC was an i2c slave, samus_pd.
Now we have 2 more, ryu and ryu_sh (sensor hub).
Define a new variable: CONFIG_HOSTCMD_I2C_SLAVE_ADDR
TEST=Compiled
BRANCH=None
BUG=chrome-os-partner:30740
Change-Id: I484aaf5ca72f14a91ce261b91fbe600dca3474dc
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208978
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want repeated start instead of stop+start. Apparently, we need to set
START bit along with read configuration. Otherwise, the I2C module
generates a STOP condition.
BUG=None
TEST=Monitor I2C with a logic analyzer. See repeated start instead of
stop+start.
BRANCH=All using stm32f0.
Change-Id: I47491e240f2543e5d023e950d15468ec0e3c301b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208760
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously these macros took a small integer to identify the USART
to access. This integer was token concatenated to form the macro
name that resolved to the base address. This made it imposible to
use these macros in a driver that could manage more than one USART
because there was no runtime way to go from base address (or other
unique identifier) to register address.
This change makes it possible to pass either a static compile time
known base address or a runtime variable with the base address,
thus supporting either sort of driver. The existing USART driver
has been updated to compute the base address of the console USART
and pass that at compile time, resulting in no increase in code
size.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Followed by manual testing of console over UART functionality
on the STM32F072 based discovery board.
Change-Id: I06547a173b1e5cf625a57019ea4b8a84d1768444
Reviewed-on: https://chromium-review.googlesource.com/208488
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Previously the F0 and L variants had almost identical driver files
and the F variant shared about half of its driver. This refactor
moves the shared code into gpio.c and gpio-f0-l.c, the latter
is for code shared between the F0 and L variants.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Followed by manual testing of interrupt on change and UART
functionality on STM32F0 based discovery board.
Change-Id: I920babd1861548272af2857c8bd3e4f9dac4985c
Reviewed-on: https://chromium-review.googlesource.com/207986
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Now that gpio_get_level() always returns actual pin states, we can
simplify i2c_raw_get_scl/sda().
BUG=chrome-os-partner:26483
TEST=make buildall
BRANCH=None
Change-Id: Ifefb6fa5da8f566b44c419a0ea5adec41f8925e3
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207057
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For open-drain output pins, this would allow us to easily check pin
state without changing it to input.
BUG=chrome-os-partner:26483
TEST=Toggle output level and read it back.
BRANCH=None
Change-Id: Ia7ceb7a221a8f0cfec9b19a5c5baae4d5441150f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207060
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry-pick back to ToT)
If the AP de-asserts the SPI NSS pin while host command handler is
still processing the command, we would delay the Rx DMA setup later.
If this case happens, the pending result of handler will be dropped.
BUG=chrome-os-partner:28979
BRANCH=tot,nyan
TEST=build and play around on big.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204427
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 4be73492817f3f6c24ece75fed33eb956c0038b8)
Change-Id: Ie2a6550696760eadad3b0d6e3a4e56a2b29abdda
Original-Change-Id: I371a2a0b96b1ee0602be91338bd53d13f6abbd2e
Reviewed-on: https://chromium-review.googlesource.com/206922
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
(cherry-pick back to ToT)
In setup_for_transaction(), read spi->dr into a dummy variable instead
of into in_msg[0]. Since in_msg[0] is an alias for a command's port number,
this will prevent a command's port number from being over-written if spi
transaction is terminated early while a command is still in progress.
BUG=chrome-os-partner:28979
BRANCH=nyan
TEST=passed factory_test.reboot2 test for >1000 cycles
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/204355
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2b043665850f7c74cd6a4a7f24d7a18b01b378ac)
Change-Id: Ia412fadcd7621f45bbb096771615ce75fe445592
Oiginal-Change-Id: I308ea954d6242fce5b3a70a14660767ac88d8242
Reviewed-on: https://chromium-review.googlesource.com/206920
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Fix the beginning and end of BMC PD communication:
- Initial transmission within 1us of taking control of CC line
- CC line released between 1us and 23us after last edge
- If final bit is a 0, then add two 1 bits to the end
- No garbage after the final bit
BUG=chrome-os-partner:30132
BRANCH=none
TEST=tested with a fruitpie, samus, and zinger.
verified timing on scope.
Change-Id: Ie45695eb367a7554cf5d5b76b6fbdf1e3fc85d29
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206453
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
These changes were made in files that did not have the [%T ... ]
pattern. These files were broken by the change because they still
contained uses of the CPRINTF macro. There were two options to fix
this, switch to the CPRINTS macro and get the timestamp added to
these strings, or switch those files back to defining the CPRINTF
macro. Switching back seems like the right thing since it doesn't
change the output of those debug messages.
This commit also adds newline termination to a few invocations of
CPRINTF that were missing it, but obviously wanted it.
This breakage is only visible with a particular set of CONFIG_
defines that no boards currently use.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: I784b52dc385b29f05d7b9bc1521e37597409153b
Reviewed-on: https://chromium-review.googlesource.com/206281
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
When going into and waking from hibernation, we should keep CPU at high
clock frequency so that we can save and restore chip state faster. This
is especially true for the wake-up case as it affects AP boot time.
This CL keeps the CPU at 12MHz for saving state and clocks it up to
48MHz for restoring.
With this, the wake-up time (time from GPIO interrupt to completely
restoring chip state) reduces from 11ms to 0.85ms.
BUG=None
TEST=Measure wake-up time with logic analyzer
BRANCH=None
Change-Id: Ib470a3d38959247b082cc7a5fd2d889cdc2a15ca
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206308
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The SPI init should run before we power up AP. Otherwise, the AP
would try to talk to EC before the EC SPI is ready. This could fail
the first SPI transcation.
BUG=chrome-os-partner:30083
BRANCH=Tot,nyan
TEST=build and run on Nyan only.
Change-Id: Ie40ba5210c49446c94c01d697aa66568730de83f
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206181
Reviewed-by: Vic Yang <victoryang@chromium.org>
Save system states before hibernating and restore them after waking up.
This saves us from needing to reboot every time we wake up.
BUG=None
TEST=wake from hibernate. Check UART, ADC, and timer are working.
BRANCH=None
Change-Id: I044fb8a796e1560c0f748d766f4aeee4dda23342
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On MEC1322, we don't have indication of empty space in transmit FIFO. To
work around this, we needed to look at Tx FIFO empty bit instead. However,
this effectively made the FIFO length one. This CL fixes this by only
checking Tx FIFO empty bit every 16 characters written to Tx FIFO. This
is assuming the UART module works the same way as 16550 UART, which has
a 16-byte FIFO.
In a simple bulk write test, this improves Tx performance by 30%.
BUG=chrome-os-partner:24107
TEST=Build and boot. Check console still works.
BRANCH=None
Change-Id: I97a6f42bd11be6bb18bc339af6d9b0cf2bae4845
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206160
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The auto mode keeps the read buffer full and thus interfere with the
next transaction. We need to disable it when we are done with the
current transaction.
BUG=chrome-os-partner:29805
TEST=Read from SPI flash multiple times
BRANCH=None
Change-Id: I624299aae29fecde03e41228a694550f1deafd2a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205799
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This allows us to use the two SPI ports as SPI master. Also, to save CPU
time on reading large amount of data, let's add an async interface for
SPI transaction.
BUG=chrome-os-partner:29805
TEST=Read manufacturer ID from SPI flash with sync/async interface
BRANCH=None
Change-Id: I427f4215602cccc55c4151f4116226b1e0ccc15e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204719
This implements the DMA driver using the same DMA interface we are using
now.
BUG=chrome-os-partner:29805
TEST=Along with the following SPI driver, read manufacturer ID from SPI
flash.
BRANCH=None
Change-Id: Ife3c0c8b414568ff1cab7d072901ba2d11142a17
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205067
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It would be really nice to be guaranteed to see watchdog warnings
before we actually hit a watchdog reset even if something strange is
going on with the CPU. Let's increase the margin between the timer
and the independent so that the hardware watchdog is really hit as a
last resort.
It seems like a 1.6 second hardware watchdog wouldn't be the end of
the world so let's bump that way rather than increasing the number of
warnings.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST="waitms 1000" on EC console no longer ever reboots and "waitms
2000" usually does.
Change-Id: Ic5e5ddec22fb8484cc7c552b19d3f2043c105d0c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204895
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On stm32 we were programming the WATCHDOG_HELP timer with the same
value as the independent watchdog (which automatically resets the
CPU). That means we weren't guaranteed to see the WATCHDOG_HELP. It
happened to work most of the time due to the the LSI oscillator fudge
(we assumed the watchdog was on a 56 kHz oscillator when it was
probably on a 38 kHz one), but let's give ourselves a guaranteed gap.
It's unlikely that this extra gap will actually help on most machines
(if we're running at 53 kHz or lower we already had this much margin),
but it's nice to be safe.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST=Increase margin to 400 (instead of 50) and type "waitms 300".
Sometimes hit watchdog warning.
Change-Id: I7f876757c15d7775116720c408a4127b4b94adfa
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204894
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug and actually increase watchdog timeout to 1.8s.
BUG=none
BRANCH=none
TEST=put a 3 second blocking delay in pd_task and make
sure watchdog reboots. set blocking delay to 1.5seconds
and make sure no reboot.
Change-Id: Ie66621a3bd98354f9fd22b9b10a866d004277340
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204471
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This adds back DECLARE_IRQ() support when building without common
runtime. With this, we can enable only a subset of IRQs and avoid
linking in other unused IRQ handlers.
Note that after this change, all boards without common runtime need to
have a ec.irqlist file.
BUG=None
TEST=Build Keyborg and check it still works.
TEST=make buildall
BRANCH=None
Change-Id: If68062a803b9a78f383027a1625cf99eb3370d3f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203264
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Created a new smaller task size, 384, for tasks that don't need much
stack space including PDCMD and ALS tasks.
BUG=none
BRANCH=none
TEST=loaded on samus, ran taskinfo, made sure we were comfortbaly
under the smaller task size for those tasks that changed.
Change-Id: Icfa26eeaeed26171ec8b2d888e1190be32f688d1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202719
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c timeout on lm4 is currently 1 second, which is very long.
This changes it to 100ms. Note, the biggest transfer we might
every do is probably ~256 bytes to do a flash program using a host
command over i2c. And the slowest bus speed is ~100kHz. So, worst
case, the transaction shouldn't be more than about 25ms.
Decreasing the timeout is useful when peripherals are not plugged
in. For example, the ALS is sampled in the hooks task every second.
We don't want the ALS sampling to be delayed for a second because
it will throw off all of our other hooks.
BUG=chrome-os-partner:29003
BRANCH=none
TEST=ran on a samus and tested i2c commands to various peripherals
Change-Id: I5e1b6d0f8b100cbcb6cd9209c6198e31d99bb085
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202515
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Support bist carrier mode 2 - continuously transmit alternating
1's and 0's, and check for bit errors on receive side. note
that once the test is started the only way to stop is to hard
reboot the devices involved.
BUG=none
BRANCH=none
TEST=connect two fruitpies together. set one to be source:
> pd charger
and then start the bist
> pd bist
start receiving data:
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa - incorrect bits: 0 / 0
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 - incorrect bits: 0 / 0
Change-Id: Id920f6b7177a418a80e1ce325042243cd633cec6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202187
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
refactor existing code in usb_pd_phy.c to use new register definitions
BRANCH=none
BUG=none
TEST=manually verify macro substitutions produce same value
Change-Id: Ia0cd815164b0262640425abd6da973c170163f2f
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202392
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After clearing the TC flag, we should re-enable TCIE so that when
the DMA transfer is done we re-interrupt and allow
uart_process_output() to continue printing whatever is in the
circular buffer (in the case of wrap-around) or finish gracefully
if there is nothing left in the buffer.
BUG=chrome-os-partner:28837
BRANCH=nyan
TEST=Commands now reliably print full output whereas before they
might appear truncated until another interrupt was triggered to
finish printing the buffer.
Change-Id: I0a4236139f57812f384e2b99af45195537201a04
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200499
If we sysjump to EC-RW, that sets enabled=0. enabled is only set back
to 1 when the chipset resumes. But on an AP-requested sysjump, the
chipset is already on, and so the resume hook never gets called.
So, in spi init, check if the AP is already on. If it is, enable spi
transfers right away.
This probably also affects Pit/Pi. That may need an additional fix in
power/gaia.c, if it returns an incorrect chipset state after a sysjump
(I didn't test that.)
BUG=chrome-os-partner:28249
BRANCH=nyan,pit
TEST=Power+Refresh boot system with RONormal disabled, so that the AP
tells the EC to jump to EC-RW. Confirm EC communication still works
after that.
Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198869
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
We found some cases where the battery can flip out and get confused
and hold the i2c lines. Since the battery is actually smbus it will
give up after 25ms. Increase our timeout to 30ms so that the next
trasaction will work OK.
BRANCH=ToT
BUG=chrome-os-partner:28425
TEST=Revert (1cd618e Wait for battery boot-up) and use a problematic
battery; see boot works OK.
Change-Id: Ife051220cbbbd49d7bc9c8607ba177cd9582fe58
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198212
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Ensure that we finish reception if and only if we started it
whatever other events happened.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28332
TEST=Connect Zinger to Firefly, request higher voltage and ensure that
Firefly was still getting the Pings after several hours.
Change-Id: Ie99984aeb4c565be39d349457dbd2813203b3f5b
Reviewed-on: https://chromium-review.googlesource.com/197946
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
With change b610695b61, we fixed a problem
with the number of FP regs that were being saved on the stack. That change
decreased the required stack size for non-FP tasks by 64 bytes, but
increased the size needed for FP tasks (such as the lightbar).
The lightbar task was previously using within 64 bytes of its alloted stack,
so handling the task switching correctly meant that it now overflowed.
The hooks task had the same problem, but was hidden by the lightbar task.
This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar
task to use it instead of the default size.
BUG=chrome-os-partner:27971, chrome-os-partner:28407
BRANCH=ToT
TEST=Try it on both Link and Samus.
Before this change, the Samus lightbar was overflowing its stack every time
the AP booted (causing the lightbar to do things). With this change, it
doesn't. Here are typical stack sizes after this CL:
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 28.394913 328/512
1 HOOKS 00000000 0.534085 640/768
2 R LIGHTBAR 10000000 5.359356 520/768
3 CHARGER 00000000 0.094674 384/512
4 CHIPSET 00000000 0.003353 320/512
5 KEYPROTO 00000000 0.002814 312/512
6 HOSTCMD 00000000 0.002942 244/512
7 R CONSOLE 00000000 0.193776 340/768
8 POWERBTN 00000000 0.000392 248/512
9 KEYSCAN 00000000 0.409337 332/512
Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197733
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In some cases, the system will boot to S0 from the point of view of
the EC, but PLTRST# will never deassert. Work around this by waiting
50 ms for PLTRST# to deassert. If it doesn't, force the chipset all
the way down by deasserting RSMRST#, then pulse the power button to
turn it back on.
Also add a powerfail debug command to simulate this failure event, so
that the recovery process can be tested.
Add API to the LPC module to get the state of PLTRST#, and to the
power button state machine to force it released when we shut down the
chipset and and force another power button pulse as we reset the
chipset.
BUG=chrome-os-partner:28422
BRANCH=baytrail
TEST=1. Boot system. Should boot normally. Shut system down.
2. powerfail
3. Boot system. On the EC console, should see the system come up,
go back down through G3S5, then come back up. From the user's
point of view, it just boots.
1. Boot system. Should boot normally. (That is, powerfail is not sticky)
Change-Id: Ia57f196606f79b9f2fce7d9cd109ab932c3571aa
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197523
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
