For historical reasons, CCD, reset, and power button control were
scattered around several files. Consolidate the code in more sensible
(in retrospect) places.
No functional changes, just moving code.
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50
Change-Id: Ic381a5a5d0627753cc771189aa377e88b81b155e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653766
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
SYSTEM_IMAGE_RW_B hasn't been globally treated as a RW copy.
This change makes EC treat it also as a RW copy.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Iae5a9090cdf30f980014daca44cdf8f2a65ea1f2
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/656337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
- This CL adds the infrastructre needed to support different battery
types for the Coral project.
- This includes adding a battery_check_disconnect common function
that's used folloiwng battery cutoff events to ensure that the
battery is able to provide power before reporting it as present.
When the battery is not present, there is a 1 second delay used
before allowing the battery to report as present. This specific
change is motivated by an issue discovered on Eve which resulted in
H1 power rail issues and could lock up the H1.
https://chromium-review.googlesource.com/c/592717https://chromium-review.googlesource.com/c/585837
- This includes a battery_cutt_off_battery common function that can
be used by all battery types using the register and regiseter data
required for each battery's ship mode.
BUG=b:64772598,b:64728711,b:64821365
BRANCH=None
TEST=manual testing on Coral proto with Sanyo battery and tested on
Nasher with BYD and LGC-LGC.593 batteries. Verified that battery
cutoff command via EC console works. Verified that can start up as
expected following battery cutoff. Also tested battery cutoff
initiated by removing the battery from the system while it's powered
up. Also tested 'ectool batterycutoff at-shutdown' from the AP console
and verifed that battery cutoff was successful following 'apshutdown'
on the EC console.
Change-Id: I9d884efa9d64fb94d46447feb028c5d9ae82a20f
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627496
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Servo v4 monitors the SBU lines on USB-C connects in order to determine
which direction to set the orientation of the SBU mux. However, when
there's traffic on the lines, for example when the EC is rebooting, it
can lead to the wrong conclusions and terminate the USB connection.
This commit adds a CCD keepalive console command.
Additonally, when the Type-C cable is unplugged from the DUT for at
least 900ms, the CCD keepalive will be cleared. This is such that if
the cable is unplugged and then replugged in a different orientation,
the detection will still work.
BUG=b:64903997
BRANCH=servo
TEST=Flash servo_v4; `keepalive enable`. Run `dut-control
power_state:reset` > 100 times and verify that the USB connection stays
alive.
Change-Id: I5c8f9ab3361d4f52f906161ab5da471a36725a4e
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/647031
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Currently, the Cr50 state machines (EC, AP, RDD, bitbang, etc.) manage
their own enabling and disabling of the ports (UART, SPI, etc.) This
is tricky because the rules for when ports should be enabled are
non-trivial and must be applied in the correct order. In additionl
the changes all need to be serialized, so that the hardware ends up in
the correct state even if multiple state machines are changing
simultaneously.
Consolidate all of that into chip/g/rdd.c. The debug command for it
is now 'ccdstate', which just prints the state machines. This will
allow subsequent renaming of the 'ccdopen', etc. commands to 'ccd
open', etc.
Also include UART bit-banging into that state which must be
consistent. Previously, it was possible for bit-banging to leave UART
TX connected, instead of returning it to the previous state.
Use better names for CCD config fields for UART. I'd had them backwards.
BUG=b:62537474
BRANCH=cr50
TEST=manual, with a CR50_DEV=1 image
1) No servo or CCD
Pull SERVO_DETECT low (disconnected)
Pull CCD_MODE_L high (disabled)
Pull EC_DETECT and AP_DETECT high (on)
Reboot. RX is enabled even if cables are disconnected so we buffer.
ccdstate -> UARTAP UARTEC
Pull EC_DETECT low.
ccdstate -> UARTAP
Pull EC_DETECT high and AP_DETECT low.
ccdstate -> UARTEC
Pull AP_DETECT high.
ccdstate -> UARTAP UARTEC
2) Servo only still allows UART RX
Pull SERVO_DETECT high (connected).
ccdstate -> UARTAP UARTEC
3) Both servo and CCD prioritizes servo.
Pull CCD_MODE_L low (enabled).
ccdstate -> UARTAP UARTEC
Reboot, to make sure servo wins at boot time.
ccdstate -> UARTAP UARTEC
Bit-banging doesn't work when servo is connected.
bitbang 2 9600 even -> superseded by servo
bitbang -> disabled
ccdstate -> UARTAP UARTEC
4) CCD only allows more ports and remembers we wanted to bit-bang
Pull SERVO_DETECT low.
ccdstate --> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI
Reboot and see we don't take over servo ports until we're
sure servo isn't present.
ccdstate --> UARTAP UARTEC (for first second)
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI (after that)
5) Bit-banging takes over ECTX
bitbang 2 9600 even
bitbang -> baud rate 9600, parity even
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
6) Permissions work. Allow easy access to full console and ccdopen:
ccdset OpenNoTPMWipe always
ccdset OpenNoLongPP always
ccdset GscFullConsole always
Default when locked is full AP UART EC RO, no I2C or SPI
ccdlock
ccdstate -> UARTAP+TX UARTEC
No EC transmit permission means no bit-banging
bitbang 2 9600 even
bitbang -> disabled
ccdstate -> UARTAP+TX UARTEC
But it remembers that we wanted to
ccdopen
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
Try turning on/off permissions
ccdset UartGscTxECRx always
ccdlock
ccdstate -> UARTAP+TX UARTEC+TX
No read means no write either
ccdset UartGscRxECTx ifopened
ccdlock
ccdstate -> UARTAP+TX
ccdopen
ccdset UartGscRXAPTx ifopened
ccdlock
ccdstate -> (nothing)
Check AP transmit permissions too
ccdopen
ccdset UartGscRxAPTx always
ccdset UartGscTxAPRx ifopened
ccdlock
ccdstate -> UARTAP
Check I2C
ccdopen
ccdset I2C always
ccdlock
ccdstate -> UARTAP I2C
SPI port is enabled if either EC or AP flash is allowed
ccdopen
ccdset flashap always
ccdlock
ccdstate -> UARTAP I2C SPI
ccdopen
ccdset flashec always
ccdset flashap ifopened
ccdlock
ccdstate -> UARTAP I2C SPI
Back to defaults
ccdoops
Change-Id: I641f7ab2354570812e3fb37b470de32e5bd10db7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/615928
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
There is no point in updating the Cr50 to an image which will not be
allowed to run due to board ID settings mismatch.
This patch modifies the prototype of check_board_id_mismatch() to
allow to pass to this function an arbitrary pointer to an image
header, so that the function can check not only the image in the flash
memory, but also the image which just arrived over the line.
The contents_allowed() function now checks if the new image is
compatible with the Board ID value in Info1 and rejects the new image
if there is a mismatch.
BRANCH=cr50
BUG=none
TEST=tried updating a Cr50 to an image which is incompatible with the
Info1 fields contents. The update attempt is rejected. Verified
that updating to a compatible image still works as designed.
Change-Id: I3d6c16df11fcabd05888f3cbf5e9a81dc51fe66f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/650812
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The state machine in common/case_closed_debug.c only handles a subset
of what we need to do for Cr50 external case closed debugging, and
also supports a 'partial' CCD state that doesn't exist for Cr50. Move
the few lines of code from that we actually need into our file.
BUG=none
BRANCH=cr50
TEST=manual
Assert CCD_MODE_L
See 'CCD EXT enable'
Confirm Cr50 console appears as a RW /dev/ttyUSBn endpoint
Confirm firmware update over USB works
Deassert CCD_MODE_L
See 'CCD EXT disable'
Confirm Cr50 console appears as a RW /dev/ttyUSBn endpoint
Confirm firmware update over USB does not work (can't find device)
Change-Id: Id96f2770632839a9690740ece54bc2eb71d39a38
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/647909
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, only usb_pd_protocol.c cares about the actual ccd mode
(disabled/partial/enabled). Everything else just cares whether it's
enabled or not. So promote the boolean ccd_is_connected() from
board/cr50 up to chip/g, and rename it to ccd_ext_is_enabled() to
match the new nomenclature (since 'CCD' itself is now too overloaded).
This will make it easier to handle CCD state directly in board/cr50
after we split it from common/case_closed_debug.c
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50; make sure USB endpoints still work
Change-Id: Ic3df7467bfe29f1c5d7060cac1309a1f0e090d9e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648212
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Previously, chip/g/rdd provided a method for an external console
command to override the Rdd cable detect state. But since we'll be
refactoring the 'ccd' command, it's tidier to move this to a console
command inside the rdd driver itself.
BUG=none
BRANCH=cr50
TEST=manual, with no debug cable present
rdd enable -> Rdd connect
rdd -> keepalive
rdd disable
rdd -> connected (hasn't had a chance to run state machine)
(wait <1 sec)
rdd -> debouncing
(wait 1 sec) -> Rdd disconnect
Change-Id: I141eedf8070b4ad2c96cc5a364f4e37dc29bed70
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/647991
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This is the last state machine which used common/device_state.c. But
servo is more complex than that, because it needs to differentiate
state-isn't-known (debouncing) from state-isn't-knowable (Cr50 driving
EC TX), so it's cleaner to split it out the way we did AP and EC state
machines in previous CLs.
BUG=b:35587387
BRANCH=cr50
TEST=manual with CR50_DEV=1 build
// Test detect at boot, even with CCD connected
Pull CCD_MODE_L low
Pull DETECT_SERVO high
Pull DETECT_EC high
reboot -> 'Servo connect'
// CCD is not driving EC UART TX
ccd -> EC on, Servo connected, CCD enabled, EC UART RX
// When servo disconnects CCD can drive EC TX
Pull DETECT_SERVO low --> 'Servo disconnect'
ccd -> EC on, Servo undetectable, CCD enabled, EC UART RX+TX
// Can't detect servo reconnecting if we're driving EC TX
Pull DETECT_SERVO high --> (no change)
ccd -> EC on, Servo undetectable, CCD enabled, EC UART RX+TX
// When we stop driving EC TX, can redetect servo
Pull EC_DETECT low --> See 'EC off', 'Servo connected'
ccd -> EC off, Servo connected, CCD enabled, EC UART disabled
// Test debouncing at boot
Pull DETECT_EC high
Pull DETECT_SERVO low
Pull CCD_MODE_L high
reboot
Within 1 sec, pull DETECT_SERVO high --> 'Servo connected'
// Test debouncing after boot
Pull DETECT_SERVO low then high < 1 sec --> (no message)
Change-Id: I964bd36c35f52c8ef7b3ea3793b6e0764e93587c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/636047
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When my 15V/30W charger is plugged in scarlet,
I see rt946x (the battery charger on Scarlet) asserts OVP because
VBUS(15V) > VBUS_OVP(14V) defined in rt946x datasheet.
So we should limit the maximal VBUS to ~13V even if the source can
provide higher voltage.
Meanwhile, let's replace some numbers with macros for better
maintainability.
BUG=b:65118519
BRANCH=none
TEST=manually verify charging works with a 15V/30W PD charger
Change-Id: I19b7d8297bdbab0a722c488910fd872eb1395e16
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/639927
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Before all of the charge suppliers are initialized,
charge_manager_refresh() wouldn't be called to update
charging voltage/current.
Since we don't define CONFIG_USB_CHARGER, we need
to do the initialization in board specific files.
BUG=b:65118519
BRANCH=none
TEST=manually verify charging voltage/current are updated
Change-Id: Ib0c226c236b8add0dcba7bf3610da47c26166732
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/639926
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The device state machines aren't quite similar enough to use common
code. Split the AP state machine out, the way we split out the EC
state machine in the previous CL.
BUG=b:35587387
BRANCH=cr50
TEST=manual, with Cr50 strapped (or hard-coded) not to use platform reset
and not to use TPM reset to detect the AP:
Pull CCD_MODE_L low, so Cr50 detects/enables CCD
Pull AP_DETECT high.
Pull INT_AP_L low (with resistor).
Pull AP_DETECT low --> See 'AP off' message
gpioget --> INT_AP_L=0
ccd --> AP UART disabled
Pull AP_DETECT high --> See 'AP on' message
gpioget --> INT_AP_L=1
ccd --> AP UART RX+TX
Pull AP_DETECT low for <1 sec then back high
(don't see AP off/on message)
gpioget --> INT_AP_L=1
ccd --> AP UART RX+TX
Reboot with AP_DETECT still low -> AP off at 1 second
Reboot with AP_DETECT still low and then assert AP_DETECT
within a second -> AP on immediately
Repeat with Cr50 strapped/hard coded to use platform reset, but
using TPM_RST_L instead of AP_DETECT. Note that this will also
show TPM reset debugging output when TPM_RST_L is asserted.
Change-Id: Ief9e4e5f2585ff925de1595cc8fbd5306c94a806
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/634248
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Previously, some code paths such as CCD permissions change could
result in enabling EC or AP UART RX when the EC or AP is off. This
could result in interrupt storms.
BUG=none
BRANCH=cr50
TEST=manual
// Initial conditions
Assert CCD_MODE_L
Deassert DETECT_SERVO
// Both RX and TX disabled when processor turns off
// and re-enabled when it turns back on
Deassert DETECT_EC
ccd -> EC UART disabled
Assert DETECT_EC
ccd --> EC UART RX+TX
Deassert DETECT_AP
ccd -> AP UART disabled
Assert DETECT_AP
ccd --> AP UART RX+TX
// TX disabled when CCD disabled
Deassert CCD_MODE_L
ccd --> EC UART RX, AP UART RX
Assert DETECT_SERVO
ccd --> EC UART RX, AP UART RX
// Don't enable TX when detecting EC, if servo is connected
Deassert DETECT_EC
ccd -> EC UART disabled
Assert DETECT_EC
ccd --> EC UART RX
// Don't enable TX when detecting CCD, if servo is connected
Assert CCD_MODE_L
ccd --> EC UART RX, AP UART RX
// When servo disconnects, enable TX if CCD is connected
Deassert DETECT_SERVO
ccd --> EC UART RX+TX, AP UART RX+TX
Change-Id: Icb144c23e949afb0384c242965aa729b078b03eb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/642349
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Allow reporting that keyboard backlight doesn't exist even when the code
is compiled in. Useful if there are multiple device models that should
share firmware.
BUG=b:64705535
BRANCH=none
TEST=none
Change-Id: I9c1fc370aedf66ef856a571f73831095d27e3d39
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/633926
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
we need to properly restart the anx3429 after a firmware update.
simply initializing the chip doesn't seem to get it to reload its
firmware - at least not the portion of the chip that implements the
firmware version register. so, we explicitly power down and reset the
chip before reinitializing it to force it to run the new firmware.
the chip also needs a 10ms "off" time so the reset is properly seen by
the chip, so i did a light refactoring of the code paths that reset
the anx3429.
TEST=used 2 different firmware blobs and verified it switches between
them during software sync.
BRANCH=none
BUG=b:35586895
Change-Id: I967898dd906f21bdc5bc4ce9c1dff9f873d198c1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/631976
In order to test certain devices in the test lab using cased closed
debugging (CCD), we need a mechanism to programmatically "press" the
recovery button. Even though this signal is being buffered through the
EC to the AP, and the EC could theoretically set it if needed, we cannot
trust the EC in its RO image since it may speak to the outside world
over USB PD.
Instead, this commit introduces a console command on cr50 that can be
used to force the recovery button state to be pressed. However, it is
gated behind the CCD capabilities defaulting to the IfOpened state.
Additionally, a new vendor command is added to query the trusted state
of the recovery button. The AP should use this command instead of
trusting the GPIO connected to it.
BUG=b:37751915, b:64146626
BRANCH=cr50
TEST=Flash cr50. Press KEY0, verify that reported rec btn follows the
state of the button.
TEST=`recbtnforce enable` causes the button to be reported as pressed.
Physical presses of the button do not alter the reported state.
TEST=`recbtnforce disable` causes the reported state to follow that of
the physical button.
TEST=The `recbtnforce` command is set to the IfOpened capability by
default.
TEST=CCD locking the DUT and attempting to force the recovery button
results in an error of access denied. The physical state is reported.
TEST=From the AP, issue the vendor command to retrieve the button state
and verify that it behaves as expected.
Change-Id: Ib8c2928e75e5f9a1a83c5361664efc3fa0ae2ddb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/635955
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add a function to translate device_state enum into a string, then use
it for printing the ec and RDD state.
Refactor ec_state so that all state transitions go through a
set_state() function, which makes it easier to turn on debugging all
state transitions. That's normally not compiled in because it would
be spammy during debouncing.
BUG=none
BRANCH=cr50
TEST=ccd command prints EC and RDD states
Change-Id: Ie7bc56c7b66beee23d1d1989711c640e5e39ce43
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/642121
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Now that there are separate board config functions, use
!board_detect_ap_with_tpm_rst() to decide whether to configure
DETECT_AP on DIOA3, not board_use_plt_rst().
BUG=none
BRANCH=cr50
TEST=Boot cr50 strapped to use platform reset. See that 'gpioget'
shows DETECT_AP does not respond to changes on the DIOA3 pin.
Boot cr50 strapped not to use platform reset. See that 'gpioget'
shows DETECT_AP responds to changes on DIOA3.
Change-Id: Ieb05015c948b2bbafa744f00a11e6b3da143ca5b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/642120
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
By default the input current on Scarlet is limited to 500mA,
which is defined by ILIM pin.
We need to disable the control from ILIM pin to draw more
current from the source.
BUG=b:64821815
BRANCH=none
TEST=manually monitor the charging current
Change-Id: Ia356a2397b3671c178479a581b44a17215fee83d
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/639918
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
For some boards, the control lines to the charging port controller are
all tied to a power rail. In essence, this leaves the ILIM_SEL as the
only signal able to be controlled, which means that we only support
CDP/SDP.
This commit adds a new CONFIG_* option which describes this.
CONFIG_USB_PORT_POWER_SMART_CDP_SDP_ONLY
Additionally, some cleanup is made to not always assume the number of
smart power ports.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: I080ccd67ffc20ccccf1e6b33a3cf9374a6b70ad6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/634274
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The device state machines aren't quite similar enough to use common
code. Split the EC state machine out, the way we split out BattPrsnt
and CCD_MODE.
BUG=b:35587387
BRANCH=cr50
TEST=manual
Pull CCD_MODE_L high, so Cr50 detects/enables CCD
Pull EC_DETECT high.
reboot -> 'EC RX only', then 'EC on' at 1 second
Pull EC_DETECT low --> See 'EC off' message
ccd --> EC UART disabled
Pull EC_DETECT high --> See 'EC on' message
ccd --> EC UART RX+TX
Pull EC_DETECT low for <1 sec then back high
(don't see EC off/on messages)
ccd --> EC UART RX+TX
Reboot with EC_DETECT still low -> EC off at 1 second
Reboot with EC_DETECT still low and then assert EC_DETECT
within a second -> EC RX only, then EC connect at 1 second.
Change-Id: I71687e651d625cadd656934f4cb2bbadc0b58816
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/619750
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Add some board property functions that describe what behavior we are
checking instead of just using board_use_plt_rst. More devices are
getting deep sleep support. This changes some function names to make the
transition easier.
This change adds board_use_deep_sleep and board_detect_ap_with_tpm_rst.
Right now both of these just call board_use_plt_rst. This will
eventually change with the expansion of deep sleep to new devices.
BUG=none
BRANCH=cr50
TEST=run firmware_Cr50DeepSleepStress with 10 suspend/resume cycles
Change-Id: I8d9ef23f686dea788d26ac4973054ad027fdd3a4
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/633891
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Now that we enable base only on chipset state transition, sysjump
needs to be handled in a special way. On sysjump if chipset is already
in S0, then enable base right away.
BUG=b:64987346
BRANCH=None
TEST=Verified that base is enabled and connected on sysjump. Tablet
mode events work again in evtest.
Change-Id: I917b0ca84d2735a4f2b32ecea3d310eccb7c008c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/631218
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This CL enables the config option CONFIG_USB_PD_TCPC_BOARD_INIT and
modifies the board level tcpc init function to wait up to 2 seconds
to ensure that the battery is out of its disconnected state.
This change was put into Eve to ensure the PD chips are not reset until
the battery is out of disconnect and delay start of the pd_task
(and PD negotiation) until the battery is out of disconnect state.
This is part of a change was initially done on Eve
https://chromium-review.googlesource.com/c/592716.
For Coral the delay of tcpc init relative to the PD task also
addresses an issue where VBUS would be dropped by the external charger
when attempting to boot with no battery connected. When no battery is
connected there is a timing issue between the Analogix TCPC and the EC
related to when the TCPC sends its auto GOODCRC. This results in a
hard reset which causes the drop of VBUS.
BUG=b:64375688
BRANCH=none
TEST=Tested by Bitland using 500 iterations and showed no occurrence
of the hard reset causing VBUS to drop. Prior to this CL, the failure
rate was 1 out 300 attempts.
Change-Id: I28fe3266eb1c0a2940e1bdacee65cf4e642d3483
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627115
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to satisfy factory testing requirements we need to
boot a bare board with just an AC adapter without requiring
a power button.
However we also don't want to always allow booting of the
battery is present but cut-off (which will indicate BP_NO so
we can't use the existing battery_is_present function) or has
critically low level as it may not immediately boot.
To accomplish this add a function that allows the board to
specify a custom "hardware presence" for the battery that is
separate from the battery presence check.
This CL is taking a change done for Eve and pulling into TOT so it can
be used for other projects that have the same
requirements. https://chromium-review.googlesource.com/c/582544
BUG=b:63957122
BRANCH=none
TEST=manual
Change-Id: Ib1dc4f659adbf0eebd3dc8c3c61b39b8fa36cb4a
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627113
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Each GPIO interrupt should only be enabled after its state machine is
ready to accept interrupts. Enabling them all by default may cause
undefined behavior if an interrupt occurs before state machine init.
Also, EC_TX_CR50_RX was enabled, and then explicitly disabled in
board_init() because we didn't want it. Simpler only to enable the
interrupts we do.
BUG=b:35587228
BRANCH=cr50
TEST=boot cr50; manually wiggle platform reset and the detect GPIOs
and see that interrupts are still generated.
Change-Id: If810eb6fee9945f0c6dfe0d4b592bdc5ff4be6e7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/619749
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Use the previously introduced TPM logging framework to log TPM reset
events. The two lowest data field bits are used to communicate the
type of reset passed to tpm_reset_request(),
BRANCH=cr50
BUG=b:63760920
TEST=with the upcoming patches verified that TPM initialization is
logged as expected
Change-Id: Ic0874723ec6df616a8237b036542398b29fe5ccc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/620113
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Some staff boards were accidentally built with both pull-up and
pull-down stuffed, leaving the backlight output always on when
the EC is not driving the pin.
This "fixes" the issue by adding an internal pull-down on the pin,
so that the pin is pulled low whenever the PWM is disabled.
BRANCH=none
BUG=b:64845198
TEST=staff EC console:
pwm 0 -1 => backlight is off
pwm 0 0 => backlight still off
pwm 0 100 => backlight full intensity
TEST=Power consumption with PWM disabled (pwm 0 -1) and always 0
(pwm 0 0) are comparable.
Change-Id: I32549bfc037a6506470408f8e98cae5ae56006e2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/627345
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Instead of always enabling power to base whenever it is connected,
enable/disable power to base depending upon chipset startup/shutdown.
BUG=b:64460667
BRANCH=None
TEST=Verified following:
1. On system startup, base is connected only after chipset startup.
2. On apshutdown, base is disconnected after chipset shutdown.
3. Wake from base still works.
4. Base still works on firmware screen.
Change-Id: I39454701889650964b7c678b275c984772ecd3e7
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/625244
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If current status is the same as requested state, then return early
from base_detect_change without taking any action.
BUG=b:64460667
BRANCH=None
TEST=make -j buildall
Change-Id: I3c403739a2e5c43f31fe77b5633927cf49b974eb
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/625243
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The Coral schematics are being changed to reflect that volume up is
connected to GPIO83 and volume down to GPIO82. The current EC code
implemented this same assignment, but introduced an intermediate
signal name to match with previous schematics which had the opposite
assignment. With the signal names fixed on the schematic, the
intermediate #defines are no longer needed.
BUG=b:64012307
BRANCH=None
TEST=manual testing on Coral proto. Verified that up button presses
cause the volume bar to go up and volume down button presses cause the
volume bar to go down.
Change-Id: Ib04f8416e8f36271972fc650bf1593a4babaeb82
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/625063
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Add Parade PS8743 USB Type-C Redriving Switch for USB Host /
DisplayPort.
BUG=b:64598680
BRANCH=glkrvp
TEST=On glkrvp,
Connect Apple dongle and verify mux setting with i2c read.
1. i2cxfer r 1 0x20 0 -> 0x50 (DP/USB enabled)
2. flip i2cxfer r 1 0x20 0 -> 0x54 (Flip bit enabled)
Connect pluggable and verify the same.
Similar testing was successful on second type-c port.
Change-Id: I96ec380024eb659e071b019dd58b3c640fa1cc03
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/616075
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Currently, we only use the AC detect interrupt for battery cutoff
support on detachable devices, and we use the RDD detect interrupt for
waking Cr50 from deep sleep. However, Eve accidentally detects RDD
when the EC is off, so this is not a reliable signal - particularly if
Cr50 is explicitly driving EC reset.
Enable the AC detect interrupt all the time, and defer sleep for 5
seconds when it transitions. This will have a negligible effect on
overall power (since AC is not normally transitioning) and will allow
the RDD detect code to be simplified.
BUG=b:64799106
BRANCH=cr50
TEST=manually pull DIOR5 up and down; see AC interrupt debug output.
idle d, wait for sleep, then wiggle DIOR5 and see that cr50 wakes.
Change-Id: I7551f25e27a79573bf4527d8c38994634df621ec
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/619319
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
A common failure condition on the i2c bus is when the master
unexpectedly stops clocking the bus while the slave is driving the SDA
line low. In this case the master is not able to issue Stop or Start
sequences, which makes the bus unusable.
Good slave controllers are able to detect this condition and recover
from it by removing the pull down from the SDA line. This patch adds
this capability to the g chip i2c slave controller.
A new timer function is created which samples the SDA line twice a
second. If it detects that SDA is low in two consecutive invocations
and the number of i2cs read interrupts has not advanced, it decides
that the "hosed slave" condition is happening and reinitializes the
i2c driver, which removes the hold from the SDA line.
Even though the state of the SDA line is supposed to be accessible
through the I2CS_READVAL register, it in fact is not, reads always
return zero in the SDA bit. To work around this a GPIO (port 0, bit
14) is being allocated to allow to monitor the state of the line, it
is multiplexed to the same pin the SDA line uses.
When the AP is in low power modes the SDA line is held low, this state
should not trigger i2c reinitializations.
CQ-DEPEND=CL:616300
BRANCH=none
BUG=b:35648537
TEST=connected H1 on the test board to an I2c master capable of
stopping clocking mid byte. Observed that the existing code would
just sit in the "hosed" state indefinitely. The code with the fix
recovers from the condition (drives the SDA line high) 500ms to
1s after the failure condition is created.
Change-Id: Iafc7433bbae9e49975a72ef032a923274f8aab3b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/614391
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
