Board support for Planton, the Raiden testing board for type-C
functional testing.
BUG=none
BRANCH=none
TEST=make BOARD=plankton, load onto a plankton, and verify
buttons are read correctly, and connect raiden to samus and
verify that PD communication is successful
Change-Id: I40922d5627d62f7f3540ac6a307596428d40baf5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207724
Veyron only has one bicolor led (green and orange) near the AC connector.
I dedicated the green channel for displaying power status:
* Power on: Green
* Suspend: Green in breeze mode ( 1 sec on/ 3 sec off)
* Power off: OFF
Charging is now displayed only on the orange channel:
* Fully charged / idle: Off
* Under charging: Orange
* Battery low (10%): Orange in breeze mode (1 sec on, 3 sec off)
* Battery critical low (less than 3%) or abnormal battery
situation: Orange in blinking mode (1 sec on, 1 sec off)
* Using battery or not connected to AC power: OFF
The unfortunate side effect is that they have to share. So while the laptop is
charging in standby the led will blink orange(1s)-yellow(3s). While it's a
little ugly (it would have been nice to have 2 separate leds), it still provides
more information than how it was done before (where there was no indication of
power state).
BUG=None
TEST=Go through the various states (charging on/off/low and power on/off/
/suspend (warning: kernel doesn't report suspend to the EC properly yet, one can
still test this by reverting c/209668 "veyron: fixed SUSPEND_L line"))
BRANCH=None
Change-Id: I8ca0fb0909da1a186e4e5c451d8868e977b3ca1b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209911
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Ensure that the slow OCP (thermal/power protection) is not triggering
for power spikes below 20us, by sampling 4 times (with a 5us sampling
period).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=connect Zinger to Firefly+electronic load, test with various
current pulse widths and amplitudes.
Change-Id: Ic8150dbbf191c002bba9e8d3f70beb47af4577b9
Reviewed-on: https://chromium-review.googlesource.com/204588
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@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>
Like Samus, the battery can be placed into a disconnect state. This CL
implements the necessary function to determine if it is so and kick it
out of this state when possible.
BUG=chrome-os-partner:30633
TEST=Put a battery in this state. Plug in AC. Verify the battery is
revived.
BRANCH=None
Change-Id: I074a72a2efe3844cbdfb0eda16a25fd8d1755a9b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209634
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This patch is base on new hardware board, veyron has not some stuff,
such as power led, charge en
BUG=None
TEST=Read log with servo board, it has reponse when type some commends
BRANCH=None
Change-Id: I45502fd1278f69db5e46fc9ab1deaee02fc8708f
Signed-off-by: zyw <zyw@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/209231
Reviewed-by: Alexandru Stan <amstan@google.com>
Commit-Queue: Alexandru Stan <amstan@google.com>
Tested-by: Alexandru Stan <amstan@google.com>
The Samus battery can be placed into a disconnect state by asserting a
disconnect input signal. In this state, the battery will not function
until a charging current is applied. This patch adds detection of the
disconnect state. If a battery in disconnect state is found, a current
is force-applied to the battery to kick it out of disconnect.
BRANCH=None
TEST=Manual on Samus.
1. Put battery into disconnect state
2. Pull AC, then reattach AC
3. Verify "found battery in disconnect state" is seen on the
EC console.
4. Pull AC and verify that EC console is still accessable
Also verify that battery gets out of reset state:
1. Pull AC
2. Issue "i2cxfer w16 0 0x16 0x0 0x12" command on EC console
3. Re-attach AC
4. Pull AC and verify that EC console is still accessable
BUG=chrome-os-partner:29465
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib4268887fb483094ac4e641749200268160d3014
Reviewed-on: https://chromium-review.googlesource.com/209013
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@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>
This is a straightforward conversion of existing tables
into X-Macro style definitions for the GPIO alternate
functions. This change in itself, is not particularly
powerful, but having all GPIO settings in a single file
makes a board easier to understand.
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: Ib7f1f014f4bd289d7c0ac3100470ba2dc71ca579
Reviewed-on: https://chromium-review.googlesource.com/207987
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
With only mini-PCIe devices, we don't need to wait for the full 99ms that
PCIe devices require.
BUG=chrome-os-partner:25530
BRANCH=ToT
TEST=manual
Log in, connect to the web via WiFi. Close the lid, wait a bit, open the
lid. WiFi should resume and still work.
Change-Id: I24d6ae95607f8f9a0fa70aebf5eaa0ebd68260f6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200084
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add support for toggling between source and sink as dual-role
port. When transitioning to S0, we turn toggling on, when transitioning
to S3, we turn toggling off but remain in the same PD state, and when
transitioning to S5, we turn toggling off and force the PD role to a
sink.
Note, when toggling is off, the source disconnected state is
allowed to transition to sink disconnected, but not vice versa. This
means that if you go into S3 as a source, it will remain a source
until the device is unplugged, at which point it will transition to
a sink until the next transition to S0.
The spec specifies:
tDRP: 50ms - 100ms, Period a DRP shall complete a DFP to UFP and back
dcDRP: 30% - 70%, Percent of time that a DRP shall advertise DFP
tDRPHold: 100ms - 150ms, time to hold VBUS on after a DRP detects a UFP
tDRPLock: 100ms - 150ms, time to stay in DFP after detecting loss of UFP
This CL uses 40ms for time as a UFP (sink), 30ms for time as a DFP
(source), and 120ms for hold and lock times.
Also, if advertising as a DFP (source) and VBUS is detected, this
automatically switches to a UFP (sink).
BUG=chrome-os-partner:28782
BRANCH=none
TEST=test on samus, make sure we are toggling between source and sink
when disconnected. make sure plugging in zinger switches state machine
through to sink_ready and make sure plugging in a USB switches to
source_discovery. tested on a fruitpie by scoping the CC line and verifying
the timing (except the hold time which I can't easily test).
tested that dual role toggling is off in s3 and s5. also verified that
going into s3 as a source keeps the port as a source and going into s5
switches it to a sink.
Change-Id: I478634861f694164301d71359da35142ee7ebf75
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207154
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The 2 boards are similar enough to test stuff on big for now, at least
until the new hardware comes.
Also added veyron to flash_ec.
Also cleaned up the style: pre-upload.py was giving errors on files
that were unmodified from big(spaces instead of tabs).
I had to ignore this though:
> ERROR: Macros with complex values should be enclosed in parenthesis
> #471: FILE: board/veyron/board.h:35:
> +#define KB_OUT_PORT_LIST GPIO_A, GPIO_B, GPIO_C
BRANCH=none
BUG=chrome-os-partner:30167
TEST=~/trunk/src/platform/ec $ make BOARD=veyron clean &&
make -j BOARD=veyron && util/flash_ec --board=veyron --ro
verify ec is alive and version is reported as veyron
Change-Id: I1f4bd562c0ab55360a2160a753ad8ad9b58f8c47
Signed-off-by: Alexandru Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207270
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Revert
- https://chromium-review.googlesource.com/#/c/205145/2
- https://chromium-review.googlesource.com/#/c/205147/4
Now using the real AC_PRESENT gpio signal instead of whether or
not the PD MCU negotiated for 20V.
BUG=chrome-os-partner:29841, chrome-os-partner:29842
BRANCH=none
TEST=tested on a board with reworked AC_PRESENT signal. Verified
that gpio is correctly reporting state of AC and is charging when
AC is plugged in. Tested the no battery case to make sure
board powers on and stays on with just a charger. Also tested the
dead battery case by plugging in a dead battery, then plugging in
a charger and making sure system powers on and starts charging.
Change-Id: I4424771c91c8a2aa19eda68a8b5194e9265d529c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206598
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This version of the EC firmware just provides a console and some
blinking lights for the stm32f0 discovery board. This is a
convenient board to work with for peripheral bringup.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: I9ae87235e8a505d58fa7a5c996528c4dd6c3f2ac
Reviewed-on: https://chromium-review.googlesource.com/207130
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
The HW signals to control the type-C ports muxing have changed between
Fruitpie and Samus, update the code to match the HW.
Also add the docking mux option and update the board muxing code to
prepare for the automatic mode detection :
- the polarity will be determined by the PD code.
- the port muxing will be enable/disable by the common alternate mode PD
code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
Change-Id: I0706626270c73d2a5e3f85b86e65a7c4fc21f9ec
Reviewed-on: https://chromium-review.googlesource.com/206685
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Use the interrupt as faster detection when VBUS is going off, so we are
not missing when the source is cutting its output due to a fault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=Connect Firefly to Zinger, trigger a short OCP with the electronic
load, once Zinger has recovered from the fault, see Firefly
re-negotiating voltage.
Change-Id: I4d273a0007d1e79884e0acbf75509ab9c8578893
Reviewed-on: https://chromium-review.googlesource.com/207031
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Enable the VBUS detection to be able to re-negociate a PD contract when
we are losing power.
The VBUS_WAKE GPIO is broken on the current hardware (not triggered when
VBUS is 5V), so we fall back on using the ADC on VBUS_SENSE.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=With a Firefly connected to a Zinger,"fault" the power supply to
get it to turn off its output. See Firefly detecting the cut-off and
re-negotiating voltage.
Change-Id: Ia5f0734cbd8f20d84ce170cea191410bb72a87c3
Reviewed-on: https://chromium-review.googlesource.com/206944
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The default VBUS voltage is 5V, let's switch on the matching LED rather
no LED when no voltage has been selected.
This allows to know that the board is powered.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=power up Firefly and see the 5V LED ON (if the cable is plug) or
blinking (if the cable is unplug).
Change-Id: I8f6525bc6f901daf21af9b20eede2a9b1e8dbfdf
Reviewed-on: https://chromium-review.googlesource.com/206940
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
this fixes the previous patch to correctly restore the GPIO
BRANCH=none
BUG=none
TEST=verify that GPIO state after restore matches default
Change-Id: I42f73d21399f5e9429dfb50aacb6aba59ba33315
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206905
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry-pick back to ToT)
The comment #20 of issue 29162 looks like a stack overflow to me.
The issue 29067 also shows the stack is overflowed in some case.
Let's increase that.
BUG=chrome-os-partner:29067,chrome-os-partner:29162
BRANCH=nyan,tot
TEST=build only. Should run RunIn.DozingStress.SuspendResume/RunIn.Reboot2.
Change-Id: Ic7fc7c8fa9e817b2db497ebedcdff6cb8c49c565
Origin-Change-Id: If3b97af578362eb6d2794b331716f499be7ad066
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204277
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206921
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>
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>
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>
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>
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 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>
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>
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>
