(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>
(cherry-pick back to ToT)
Clear the CHARGE_INHIBIT bit when requesting non-zero current/voltage
and set it when charging should be disabled. On Blaze with the
BQ24725 charger, setting this bit saves 10-15mW when we're not on AC.
This also fixes an issue where battery charging would not get enabled
when the charger is connected while the machine is in S3/S5. This is
because the kernel driver would inhibit charging when the charger was
removed and then the EC would not enable it when the charger was
re-connected while the host was off, such as in S3/S5.
BRANCH=nyan
BUG=chrome-os-partner:29386
TEST=Boot Blaze, disconnect charger, suspend, connect charger and
observe that the battery now starts charging.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203163
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit bd4469ae4ffbbd6f2cd5549bdb8809838e55d6f7)
Change-Id: Ibcb635b01a2292f214f71ab400ec34cd12e7536f
Original-Change-Id: I2efaf02296dc08c0de85950a70ad2592f4428241
Reviewed-on: https://chromium-review.googlesource.com/206909
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>
On panic, reboot properly the CPU rather than just jumping to the reset
vector as that might lead to some incorrect initializations.
Properly plug the div by 0 to the panic handling.
Add a small trace if the debug output is activated.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29840
TEST=add adhoc code triggering a data abort and see the firmware
printing a trace, then rebooting immediatly in a working state.
Change-Id: I1d5a98d9113c8ae08e05588a40f941d1ed22cebe
Reviewed-on: https://chromium-review.googlesource.com/206268
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Until now when send_validate() receives another valid packet in place of the
GoodCRC, it was continuing its retries loop. But given that the presence
of a valid packet indicates that the other side is trying to send us
something, it's better to bail out immediatly and wait for its retry.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29847
TEST=repeatly plug and unplug a Zinger to a Samus and record the traces
of the PD negociations.
Change-Id: I901bd8d85999ed195ed9887d7375806f61222f8b
Reviewed-on: https://chromium-review.googlesource.com/206391
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The Over Voltage Protection was de-activated when the output is disabled
to avoid false positive when doing a down voltage transition,
but as a side effect, we might reset the OVP while the fault is still
present since the OVP first disables the output.
So, we want to keep testing the OVP fault condition if there is a
pre-existing fault.
Also add a hysteris and ensure we recover from OVP only when we go under
the new threshold.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=trigger an OVP using a voltage source and see the output is not
re-enabled until we shutdown the voltage source.
Change-Id: Idef3f630c3cfeb301e62f1e75c2a424b56bc98dd
Reviewed-on: https://chromium-review.googlesource.com/206185
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: 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>
remap DMA at startup, add function to switch mux and set gpio for usb debug
BRANCH=none
BUG=none
TEST=verify that gpio/mux set correctly for debug
Change-Id: I2ca39025c0cba3b5d04946ec4685a81c4de2d49f
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203493
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
These files are tabular data more than source code. We discussed
and concluded that the 80-column limit makes them harder to read,
not easier. This commit reformats them to take advantage of
longer lines, mainly by putting per GPIO comments on the end of
the line that defines the GPIO.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: I60f3e3620680196eb9462f97b34c453289240465
Reviewed-on: https://chromium-review.googlesource.com/205672
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
Add a retry mechanism for EC to PD host commands to make the
communication channel more robust.
BUG=none
BRANCH=none
TEST=run on system to verify that we don't drop host commands
to PD MCU.
Change-Id: Ida6f02a149e4dd9e85a5aac21790928b16864104
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205148
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a temporary workaround to allow dead battery charging without
an AC PRESENT signal by delaying going into hibernate with an extremely
low value in order to check if AC is present by waiting for PD MCU.
BUG=chrome-os-partner:29842
BRANCH=none
TEST=Test with a dead battery that when you plug in AC and reboot, it
is able to charge. Previous to this change with a dead battery and AC
plugged in the EC would boot and almost immediately go back into hibernate
Change-Id: I338a0cc9ee37dab3e6caf29369ac6e819772ca91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205147
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Set input points to interrupt on deep sleep as necessary.
BUG=none
BRANCH=none
TEST=make -j buildall and run on system without any notable
differences.
Change-Id: I7bcf336a676e259dfa4c73ffc7152f16f14093d2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205146
The ACOK input to the EC is not connected to the charger so
that signal cannot be relied on for AC presence. Instead
have the PD report when it negotiates to 20V and when it
disconnects and have the EC use that for AC presence.
BUG=chrome-os-partner:29841
BRANCH=none
TEST=test charging with zinger on samus system.
Change-Id: Ia9096a24ab05d110e31910218dc8c214a846a9a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205145
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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
Previously each board.h and board.c contained an enum and an array
for gpio definitons that had to be manually kept in sync, with no
compiler assistance other than that their lengths matched.
This change adds a single gpio.inc file that declares all gpio's
that a board uses and is used as an X-macro include file to
generate both the gpio_signal enum and the gpio_list array.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: If9c9feca968619a59ff9f20701359bcb9374e4da
Reviewed-on: https://chromium-review.googlesource.com/205354
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
ectool must support all prior versions of commands that shipped
EC binaries use.
BUG=chrome-os-partner:29830
BRANCH=None
TEST=Manual
With an EC that only supports version 0:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> error with explicit
message about at-shutdown not being supported
- Run 'ectool batterycutoff foo' -> error, bad parameter
With an EC that support version 0 or 1:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> success
- Run 'ectool batterycutoff foo' -> error, bad parameter
Change-Id: Ia88cfc5fa7c5125828ec0595f0b6a505916c97ea
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205155
Reviewed-by: Vic Yang <victoryang@chromium.org>
As per the new spec, use the fast OCP to protect against the
short-circuits by putting the threshold at 4.5A.
Set the slow OCP (a few dozen milliseconds latency) at 3.6A to limit the
accepted current range.
Also sample the current/voltage over a larger period (5us) to limit
noise issues.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=plug Zinger on an electronic load and trigger the OCP with various
pulses.
Change-Id: Ia66cd186716aebf88646cbf5fd340388f8cdd48d
Reviewed-on: https://chromium-review.googlesource.com/204590
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
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>
This is a temporary hack to allow PD MCU to negotiate for 20V before
EC tells it that the battery is present. This is currently necessary
because at 5V, we don't have enough power to boot the AP, and we can't
wait to boot the AP until we negotiate because the zinger tends to
get stuck in an infinite reboot loop when the AP is off.
Note that this will need to be removed when we implement PD software
sync because the whole point of that is to not talk to outside world
until we verify our code.
BUG=chrome-os-partner:29840
BRANCH=none
TEST=Tested on samus 2A and 2B boards, made sure system could boot
with and without battery.
Change-Id: I03f319bf81b4e90758132e774848dff5542f4ce5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205144
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This changes the input current limit to 2048mA with no ramp up.
Problem is that the bq24773 is doing a really poor job of measuring
input current, so even though the zinger side can support 3A, the
samus side can cause over currents down to 2300mA. This is set
consertavily to avoid over current errors and will need to be
updated when the hardware allows.
BUG=chrome-os-partner:24461
BRANCH=none
TEST=Used bench top power supply to power multiple samus 2A proto
boards and gathered data on max current samus was drawing based on
input current setting. Samus was often underestimating current by
300-700mA.
Change-Id: Iabeb0d026f2b72a9ee539d92579ee6d11aeaa56b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205143
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Increase the stack size for the charger task to work around I2C
battery communication issues.
BUG=chrome-os-partner:29839
BRANCH=None
TEST=watch for I2C0 transation failures and ensure that the charger
task does not stack overflow and reset the EC+system.
Change-Id: Iabae3e2c302b68eb9e25a604dd72ef48128866df
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205142
Reviewed-by: Vincent Palatin <vpalatin@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>
The PP1800_PGOOD pullup resistor was no-stuff on P2B boards so
the input value is floating and cannot be relied on for proper
sequencing.
Before P2B it was always pulled up so it was not a useful signal
to wait on anyways.
BUG=chrome-os-partner:29502
BRANCH=None
TEST=buid and boot on samus proto2b
Change-Id: I29167d55bb0ef36683282946b912dd8cf5b405cf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205140
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Use the board version to implement both power sequence behaviors
in order to support both boards with one EC image.
The order of bits used to calculate board version was swapped so
update the GPIO table to reflect that.
BUG=chrome-os-partner:29502
BRANCH=None
TEST=build and boot on samus proto2a
Change-Id: Ib0f6010163af4b3bf9b39f64c26220aee43618ef
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204869
Reviewed-by: Alec Berg <alecaberg@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>
On the P2 boards, the operational amplifier gain for current sensing is
exactly x100 rather than x101.
(non-inverter configuration with R1=1.8kOhm R2=178kOhm)
The voltage gain constant had a typo introducing a 10% error.
the voltage divider is 10k/100k,so it's x11 gain.
ie it should be written (10+100)/10 rather than (10+110).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=make BOARD=zinger
checked manually with a voltmeter and traces.
Change-Id: I8097ab50149fee319efc11ebae75802e8a49a7f8
Reviewed-on: https://chromium-review.googlesource.com/204540
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Twinkie only has test points for uart connection so nominally it will
need to be programmed via DFU mode over USB micro-B connection.
This CL changes from programming via flash_stm32 function and instead
adds dfu support.
BUG=chrome-os-partner:28337
TEST=util/flash_ec --board=twinkie successfully programs twinkie f/w
Change-Id: Ia5433b569579bb879bd405e98921450764510a73
Reviewed-on: https://chromium-review.googlesource.com/204749
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
In order to wake the chips from STOP/SLEEP mode with a touch, we need to
put the two chips in correct state before going into STOP/SLEEP mode.
Also, when one of the chips wakes up, it needs to wake the other chip
with GPIO interrupt.
This CL implements the necessary methods and also adds a sample routine
that put the chips in STOP mode and wait for a touch using the
implemented methods.
BUG=None
TEST=Build and boot. Touch the panel and see the response in console.
BRANCH=None
Change-Id: Ia5f7df8b550ee2459bcae1840f8a2717c8d947ce
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204482
Reviewed-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>
Increase watchdog timeout to 1.8 second. The pd_task can delay up
to 1.5 seconds, so the watchdog must be at least that value.
On Zinger, the new timeout period will be 2 seconds with LSI clock at 50kHz
and 3.36 seconds with LSI clock at 30kHz.
Note: the LSI frequency range is tighter on STM32F0 and cannot go up to
56kHz.
BUG=none
BRANCH=none
TEST=add 1.5 second blocking delay to pd_task and make sure
watchdog is normally not firing.
Change-Id: I444639ccacd3452181a5fb6caab8e5df7ef3c847
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204333
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
We never implemented this. We have no devices which support it. And
we used bit #17 in a 16-bit field to flag it, so it wouldn't have
worked even if we did. So, remove this (dead) code.
BUG=chromium:382944
BRANCH=none
TEST=make -j buildall
Change-Id: Id3a4a93612d1078a3239d85921a05cfd7362b84c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204162
Reviewed-by: Doug Anderson <dianders@chromium.org>
Currently the master and the slave must synchronize before starting
slave response. This is to make sure the previous slave response is done
and the slave is ready for the next response. By enabling interrupt on
the master side to capture slave ready event, we can get rid of the
extra sync's. This saves about 1300 us per frame.
BUG=None
TEST=Build and boot. Measure time. Examine heat map.
BRANCH=None
Change-Id: I3c319d8a3636f1f6ae905d7021433c3ba220c9b0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203789
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If at-shutdown is specified, the battery is cut off
1 seconds after the host has shutdown.
BUG=chrome-os-partner:29292,chrome-os-partner:28887
BRANCH=tot,nyan
TEST=Run batterycutoff ectool command and cutoff console
command with and without 'at-shutdown' option. Verify
the battery is cut off immediately without the option
specified and 1 seconds after shutdown with. View the
console log to see the deferred cutoff occur.
The following tests are verified on big.
console:
cutoff, AC on: system is off after removing AC.
cutoff, AC off: system is off immediately.
at-shutdown, AC on: system is off after "power off" and removing AC.
at-shutdown, AC off: system is off after "power off".
ectool:
batterycutoff, AC on: system is off after removing AC.
batterycutoff, AC off: system is off immediately.
at-shutdown, AC on: battery is cut off after 1s of shutdown.
system is off right after removing AC power.
at-shutdown, AC off: system is off after 1s of shutdown.
[84.058416 power state 3 = S0, in 0x0000]
[84.058803 power lost input; wanted 0x0001, got 0x0000]
[84.059120 power off 3]
[84.072148 Cutting off battery in 1 second(s)]
[84.123896 power shutdown complete]
[84.128790 power state 7 = S0->S3, in 0x0002]
[84.139694 power state 2 = S3, in 0x0002]
[84.150857 power state 8 = S3->S5, in 0x0002]
[84.166975 power state 1 = S5, in 0x0002]
[84.177972 power state 1 = S5, in 0x0002]
[85.080012 Battery cut off succeeded.]
Change-Id: Id4bacf79ad3add885260655f80cb8127bafe1ad6
Signed-off-by: Dave Parker <dparker@google.com>
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203694
Reviewed-by: Vic Yang <victoryang@chromium.org>
- Wait for SLP_SUS to deassert before bringing up PP1050 to avoid
leakage when PP1050 is enabled before the PCH is ready.
- CPU PGOOD is now connected to RSMRST_L on PCH. Configure this
GPIO as an output and hook it into the power sequencing.
- Add a "chipset_force_g3()" function to use for aborting G3->S5
transitions when there is an issue with a rail not coming up.
BUG=chrome-os-partner:29502
BRANCH=samus
TEST=build for samus, tested on reworked p1.9 board
Change-Id: Ib0251943864594ee89a4a9f2c71c45da2c01f44e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203081
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Detect when VBUS is disconnected when acting as a sink and go to
the disconnected state.
BUG=none
BRANCH=none
TEST=Connect a zinger to fruitpie, run pd state from console to
verify it is in SNK_READY, then remove zinger and verify the state
changes to SNK_DISCONNECTED.
Change-Id: I0b46cfe3ac129f1ec9c11327c9e0d45c0c6761e8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203564
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The timer on Keyborg is only of 32-bit width, so we should always use
get_time().le.lo instead of get_time().val to avoid unneeded 64-bit
integer operations. This saves about 0.66 us per call to
master_slave_sync(), which is called about 500 times per frame.
BUG=None
TEST=Measure the time used on master_slave_sync().
TEST=Boot and check touch scanning still works.
BRANCH=None
Change-Id: I6668cda3c6c00d1af971fc55fcc8d643b83a4578
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203670
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In order to make SPI CRC work, we had to ensure the master and the slave
agree on the size of slave response. This required us to first send the
response size and then send the full response. The downside of this is
that we cannot take full advantage of DMA.
Given the SPI bus is fast enough, let's add an option to always transfer
max size packet on slave response. This incurs some overhead as unused
bytes are also sent, but the overhead doesn't affect us when the slave
is busy with touch scanning. (The scanning time is longer than
transferring 64 bytes over SPI.) This situation may change in the
future, so make it a compile time option for now.
Also removed the use of RX channel on the slave side when the slave is
sending response. The RX channel is useless in this case.
BUG=None
TEST=Build and measure scan rate w/ and w/o
CONFIG_KEYBORG_SPI_FULL_PACKET flag.
BRANCH=None
Change-Id: I4b23b1d89903dd022b445eb81667679276858008
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203660
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
