| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The syv682x needs to have FDSG (force discharge mode) disabled in
order to allow charging.
BRANCH=none
BUG=b:148487130,b:148467221
TEST=verified PD charging works with USB3 daughterboard
(crrev.com/c/2013656 needed to enable USB3 board).
Change-Id: Ifff20576accf88822228b7bd7b9eeb6b6cff6a6b
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2037097
Reviewed-by: Keith Short <keithshort@chromium.org>
Reviewed-by: Abe Levkoy <alevkoy@chromium.org>
Commit-Queue: Keith Short <keithshort@chromium.org>
Tested-by: Keith Short <keithshort@chromium.org>
Tested-by: Eric Herrmann <eherrmann@chromium.org>
(cherry picked from commit dd5b97c3e86d71919ec1287e19e740e86081fdde)
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2291468
Tested-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were reading CONTROL_1_REG instead of STATUS_REG to check the
VSAFE_0V status. This corrects the register being accessed.
BRANCH=none
BUG=none
TEST=volteer boots without a battery
Change-Id: I06d0fbc0b9313b809ed43be13138241beca395a5
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1999619
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Scott Collyer <scollyer@chromium.org>
(cherry picked from commit d9d96d1b01cb66fbfdc50fe705eaa2cc2579b442)
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2291467
Tested-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When sn5s330 PPC detects CC overvoltage, recover via hard reset and don't
enable PP2 sink FET directly. Also clean up the interrupt unmasking in
sn5s330_init().
BUG=b:144892533
BRANCH=grunt
TEST=Do ESD test to trigger CC1/CC2 OVP, device recovers to sink
Change-Id: I662bf164b55508be4d5cc1b3ad639c9613bd1935
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1949264
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1949267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If PPC have CC OVP protection, check VBUS_GOOD.
If VBUS_GOOD is ok, release CC OVP.
BUG=b:141587322
BRANCH=Master
TEST=Manual
Do ESD test to trigger CC1/CC2 OVP.
Using EC console command PPC_DUMP to check ppc regiset is correct.
Change-Id: I3b817cc1dcec4c14ed4e2098b7ad7582b938f613
Signed-off-by: Michael5 Chen <michael5_chen@pegatroncorp.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1826098
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1933787
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
Tested-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extentions were added to make the compiler perform most
of the verification that the conversion was being done correctly
to remove 8bit addressing as the standard I2C/SPI address type.
Now that the compiler has verified the code, the extra
extentions are being removed
BUG=chromium:971296
BRANCH=none
TEST=make buildall -j
TEST=verify sensor functionality on arcada_ish
Change-Id: I36894f8bb9daefb5b31b5e91577708f6f9af2a4f
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704792
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1767528
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
Tested-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opt for 7bit slave addresses in EC code. If 8bit is
expected by a driver, make it local and show this in
the naming.
Use __7b, __7bf and __8b as name extensions for i2c/spi
addresses used in the EC codebase. __7b indicates a
7bit address by itself. __7bf indicates a 7bit address
with optional flags attached. __8b indicates a 8bit
address by itself.
Allow space for 10bit addresses, even though this is
not currently being used by any of our attached
devices.
These extensions are for verification purposes only and
will be removed in the last pass of this ticket. I want
to make sure the variable names reflect the type to help
eliminate future 7/8/7-flags confusion.
BUG=chromium:971296
BRANCH=none
TEST=make buildall -j
Change-Id: I2fc3d1b52ce76184492b2aaff3060f486ca45f45
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1699893
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1767525
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
Tested-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TI SN5S330 has VCONN overcurrent protection and will automatically
latch off VCONN if a port overcurrents it. Keeping VCONN latched off is
allowed per the USB Type-C spec. This commit simply logs a message on
the EC console such that it will be easier to tell when it happens.
BUG=none
BRANCH=firmware-nocturne-10984.B
TEST=flash nocturne, plug in a Type-C adapter which overcurrents VCONN,
verify that a console message indicating the overcurrent event is shown.
Change-Id: I22da6e8d43ac7739dc213d5a1f049b98d7ee829d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1328321
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1330162
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1603127
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SN5S330 has FETs for the SBU lines which need to be controlled by
the TCPM. This commit adds a function to control the SBU FETs and
enables them when configuring the USB mux.
This commit also fixes a bug with the external VBUS current limit
setting by setting it appropriately to a min of ~3A.
BUG=b:114340064
BRANCH=firmware-nocturne-10984.B
TEST=Flash nocturne; plug in hoho; verify that external display is
shown. Bounce thru S5, verify that external display still works.
TEST=Repeat above with superspeed hub instead.
Change-Id: I931f7a47d4eb28e8d9e3cb188601ce0889a44f8d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1244382
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1530125
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1603125
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Type-C Power Path Controllers provide overcurrent protection. This
commit adds support into the USB PD task for overcurrent events while we
are in source role. The USB PD 3.0 spec recommends that ports issue a
hard reset when an overcurrent condition occurs on a port.
Additionally, we'll allow a source port to overcurrent 3 times before
latching off VBUS from the port entirely. The source path will be
re-enabled after ~1s after each overcurrent event.
BUG=b:69935262,b:114680657
BRANCH=None
TEST=Boot to ChromeOS in grabbiter. No overcurrent events reported when
the sink is drawing <= 3.20 A. Overcurrent events are reported when the
sink is drawing > 3.25 A. After 3 reports, the port is latched off and
power delivery is stopped. The port is re-enabled only after the sink is
disconnected. Also when the sink is drawing current at 3.24 A, there is
one report of overcurrent. The port gets disabled in response to that
event. But the port is re-enabled after 1 second since overcurrent event
is reported only once. After the port is re-enabled, the sink is able to
draw the set current. When the overcurrent event is reported, I can see in
the kernel logs that the overcurrent condition is detected by the kernel.
EC Logs:
[3391.984462 C1: PPC detected Vbus overcurrent!]
[3391.984953 C1: overcurrent!]
[3392.044935 C1: PPC detected Vbus overcurrent!]
[3392.045425 C1: overcurrent!]
[3392.061404 C1: PPC detected Vbus overcurrent!]
[3392.061894 C1: overcurrent!]
[3392.062142 C1: OC event limit reached! Source path disabled until
physical disconnect.]
[3392.077226 C1: PPC detected Vbus overcurrent!]
[3392.077532 C1: overcurrent!]
[3392.077891 C1: OC event limit reached! Source path disabled until
physical disconnect.]
[3392.092660 C1: PPC detected Vbus overcurrent!]
[3392.092966 C1: overcurrent!]
[3392.093213 C1: OC event limit reached! Source path disabled until
physical disconnect.]
Kernel Logs:
[ 3356.560456] usb usb2-port1: over-current condition
[ 3356.768434] usb usb2-port2: over-current condition
[ 3356.976446] usb usb2-port4: over-current condition
[ 3357.184441] usb usb2-port5: over-current condition
[ 3357.392445] usb usb2-port6: over-current condition
Change-Id: Ib070f261e98264cd88725ebce7d10e0798267e3b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1286300
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/807633
Commit-Ready: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/1460079
Reviewed-by: Edward Hill <ecgh@chromium.org>
Tested-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SN5S330 PPC will pull its /INT pin low until all interrupts are
cleared. Since the interrupt pin is treated as edge-sensitive, its
handler needs to provide level-checking before exiting. Otherwise, if
not all interrupts are cleared before the handler exits, the EC won't
see another edge to call the handler again.
Boards which share the PPC interrupt pin with other sources may choose
to implement their own callback, if they are able to determine which
chip was the source of the interrupt.
BUG=b:118846062
BRANCH=None
TEST=performed several power swaps and unplugs on a pair of Careenas,
verifying that in instances where the handler had to loop around we
correctly cleared the interrupts and the "ectool usbpdpower" output was
normal
Change-Id: Iccbe40976a746d109d67b9a91f8fbd81898f9b3f
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327123
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/1335679
Reviewed-by: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default deglitch time is short enough to trip the current limit with
some commercially available USB-C -> HDMI adapters. Increase the
deglitch timeout to improve compatibility with those adapters.
BUG=b:113777138, b:113365815
BRANCH=none
TEST=Insert 7 different USB-C to HDMI adapters, including both
single-function and multifunction devices, and observe that a Careena
clamshell will extend the screen to include the attached monitor on both
USB-C ports 0 and 1. Brands tested include SIIG, StarTech, Amazon
basics, iogear, Apple, and an unlabeled device.
Change-Id: I403e4a65e90c85bdaa8078230751d611d04c9c67
Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1225354
Reviewed-by: Jett Rink <jettrink@chromium.org>
(cherry picked from commit 6b72a548f7a0999a43259426432132295635624b)
Reviewed-on: https://chromium-review.googlesource.com/1227270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a low power mode method for PPCs behind a new config.
Implement the low power method for SN5S330 based off of TI AE
recommendation.
BRANCH=none
BUG=b:111520593,b:111006203
TEST=CL stack produce lower power during bip hibernate
Change-Id: Icd22f88a8f65c2cd5ab1c95b0750b1eb61e91923
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1166183
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL doesn't change any functionality, but renames the driver from
3483 to 348x. The motivation for this is that we need to support the
NX20P3481 PPC as well. Those chips use the same registers, but the
3481 adds FRS support and sink/source control is done via I2C writes
instead of gpio controls.
Because the chips are slighlty different the config option
CONFIG_USBC_PPC_NX20P3483 needs to remain.
BUG=b:111281797
BRANCH=none
TEST=make -j buildall
Change-Id: Ie1085140eb2ef23c0b6e1a79a6f2d7f823326c6d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1176382
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reading, toggling bits, and then writing is common in this file, so add
helper methods that clean up it up.
BRANCH=none
BUG=none
TEST=PPC operation is unaffected on bip.
Change-Id: I97bac3750cc6afff5799fdfa03b05a74bd5334ef
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1166182
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We figured out that having the EC drive the EN_SNK input of a PPC will
lead to brownout or lockout conditions since the EC will float the GPIO
when the EC reset. When the PPC input floats, the power path to the rest
of the board is cut.
If you mix this scenario with a PPC that hard-codes the over voltage
protect of vbus at 6.8V in dead battery mode, you can lock the
previously negotiated 20V Vbus out of the system until you physically
remove the USBC connection and reinsert it.
BRANCH=none
BUG=b:78896495,b:78021059,b:111545725
TEST=removing unused code. everything still works.
Change-Id: Ie9d51af766bc08e7d9b46b4610c0f84d3d0961f8
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1067712
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This solves as few problems:
- We do not need to perform "expensive" i2c communication when we need
to determine the state of Vbus that we previously set.
-- This allows the is_sourcing_vbus call to be performed in an interrupt
context (see crrev.com/c/969701/7/board/cheza/board.c#85).
- This prevents the problem of the is_sourcing_vbus from being called
before init after a sysjump thus potentially preventing power on
(see b:80203727).
- This also papers over an issue where the TCPC stops sourcing Vbus
without our consent, because the logic work correctly if vbus is in the
same state we last set it to (see b:111404471)
This caching paradigm is apply to tcpc vbus level and other ppc is vbus
being sourced (See CL:1086115)
BRANCH=none
BUG=b:111404471
TEST=Vbus on phaser's C1 discharges correctly
Change-Id: I9c19c3d177a4a4e49be4372e8b01d84fcf2a0c4b
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1141111
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems that several charge through hubs have inrush currents that
exceed 350mA when VCONN is applied. This in turn causes the SN5S330 to
latch off VCONN due to the overcurrent condition. This commit simply
sets the VCONN current limit to the 600mA (min) setting.
BUG=b:110370179
BRANCH=None
TEST=Flash nocturne; Use a variety of charge through hubs, verify that
VCONN is not latched off.
Change-Id: I7a0e5d1aa7c42d22b43a596520790debee47163b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1105309
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sn5s330_init() will turn off the PP1 (source) FET, but
sn5s330_is_sourcing_vbus() can be called before PPC init: by
usb_charger_init() and pd_power_supply_reset() from pd_task().
Keep track of the PP1 (source) FET state locally, and use this for
sn5s330_is_sourcing_vbus(), instead of reading the state from the PPC chip
over I2C every time.
This solves the problem of sn5s330_is_sourcing_vbus() being called before
sn5s330_init(), and also avoids other problems caused by
sn5s330_is_sourcing_vbus() doing I2C communication:
crrev.com/c/969701/7/board/cheza/board.c#85
BUG=b:80203727
BRANCH=none
TEST=Reboot Grunt EC while one USB-C port is VBUS source.
Change-Id: Ie0fdd3d672bc747fcdbb746586149e194165fdac
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1086115
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to disable under voltage protection because it prevents us from
enabling the sink path when there is not Vbus on the connector side. We
need to enable the sink path before we hibernate otherwise there is no
power power to get to the charger which will then assert ACOK. Without
this we won't wake up with the ACOK wake when USB power is inserted.
BRANCH=none
BUG=b:79948623
TEST=bip wakes with USB power insertion
Change-Id: Idf16a92dacde63cf943ef68b0258b320d11de44c
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1070867
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bip also need to enable the sink path when going into hibernate
BRANCH=none
BUG=b:79948623
TEST=on bip, verfied that AC_OK, LID_OPEN, and POWER_BTN all wake the EC
up.
Change-Id: I2c1168f856cc45635b5c76f7ca409007fcf141cc
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065203
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed data was getting dropped from my console output on
bip. Adding the cflush fixes it.
BRANCH=none
BUG=none
TEST=ppc_dump 0 on bip works
Change-Id: Ib71cb37c4c8728a7ab958905d3b2627b8c163faa
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1070626
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL adds the port number to the error messages for the TI sn5330
PPC driver. It also adds 'ppc' so that its clear where the messages
are coming from.
BRANCH=none
BUG=b:79640678
TEST=Tested on Bip MLB and verfied that PPC EC console log errors
display the port number.
Change-Id: I7988e5e4008c005bb1ef9a78331d4a2597fdcb62
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1060105
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to increase our current limit so we don't trip when we are right
at 3.0A.
BRANCH=none
BUG=b:79482290
TEST=yorp can now source 3A
Change-Id: If90af7e6eeaf90d3bd0ac67462e94523d2348a0a
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1053238
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the board is not powered until VBUS is connected, then that port
will trigger dead battery mode in the PPC. This mode must be exited by
the host (EC) writing to the control register. Until dead battery mode
is exited, VBUS OVLO is fixed at 6.8V. Therefore the regular setting
of this value must be done after exiting dead battery mode.
This CL also changes the check for dead battery mode to use the mode
value in the device status register. The bit in the control register
does not reflect the status, but rather, if dead battery mode exit has
been written by the host. The current check will result in the dead
battery mode section being executed for both ports after every power
up. However, only the port that has VBUS active would succeed because
the HV_SNK mode can't be enabled unless VBUS is present.
Lastly, this CL changes the verification check for the
sink/source_enable functions to rely on the mode in the device status
register instead of the switch state. The reason for this is that the
switch state requires ~15 msec delay before it gets updated following
SNK_EN to the nx20p3484 being set high. However, the mode reports the
correct state without reqiuring a msleep.
BUG=b:77561535
BRANCH=NONE
TEST=Tested both port 0 and 1 and verified that Yorp can power up
without a battery. In addition verified that
nx20p3483_vbus_sink_enable returns EC_SUCCESS for both enable/disable
cases.
Change-Id: I2c993b592cd30e34a39d1c1b7e3c54be9f505844
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1005621
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ANX7447 has a sink/source control lines which can be connected to
a PPC. The NX20P3483 PPC requires this control to set it's sink/source
switch control. The ANX7447 contols these lines via the tcpci COMMAND
register. This CL adds new tcpm_set functions to set either SNK or SRC
control via the COMMAND register.
BUG=b:77583452
BRANCH=NONE
TEST=Tested on port 0 of Yorp with an external charger. Prior to this
CL the PPC would remain in standby state because both snk/src control
remained low. With these changes, verifed that snk_ctrl is driven high
and vbus_sink_enable() function no longer returns an error.
Change-Id: Icbea0d3edb63ad19f3d2c76636208497b6939a72
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/996239
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=none
BUG=b:77561535
TEST=yorp P1 can still boot without battery
Change-Id: Ifa327e2989ac3dfe260b570edbc23add4910e09f
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/998410
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we don't enable the SNK mode before leaving dead battery mode
(which does keep the inflow path open), then we will brown out
our only source of power.
BRANCH=none
BUG=b:77561535
TEST=yorp can boot into ec without battery
Change-Id: I095e3cb1ed466fd6497bbc9e7b6851fc92005c75
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/999024
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NX20P3483 is a USB PD and Type C high voltage sink/source combo
switch. This CL adds support for this PPC variant. Unlike the TI
SN5S330, the NX20P3483 does not support VCONN and does not need to be
informed of CC polarity by the TCPM. To account for these differences,
2 new PPC config options are added and the driver for the TI SN5S330
was modified to include these new options.
The SNK/SRC switch mode for the NX20P3483 is controlled by 2 GPIO
signals which may be connected the EC or directly to the TCPC. To
handle both cases, the ppc_chips structure was modified with a flags,
snk_gpio, and src_gpio elements.
BUG=b:74206647
BRANCH=none
TEST=make -j buildall and verified there are no build errors.
Change-Id: Ic4415ab7571b80e7661ea673434eaf4cf1f1fd2d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/966926
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn off vSafe0V interrupts. They were not being handled or
cleared causing the interrupt line to be stuck low after
unplugging a USB device.
Also don't use read-modify-write for INT_STATUS_REG4 since
this would clear the dead battery mode bit before it has
been checked.
BUG=b:73076662
BRANCH=none
TEST=unplug USB device, see USB_C1_SWCTL_INT_ODL=1
TEST=USB2 mouse can be connected multiple times, PPC VBUS
detection works, BC1.2 chip turns on and off correctly
(USB_C1_BC12_VBUS_ON_L).
Change-Id: I96980ee330dd6e5f98e447e5e87f11dd60768a5d
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/909549
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:72292985
BRANCH=None
TEST=Flash meowth; Verify with twinkie that Vconn is provided for a sink
that requires it.
Change-Id: I8168d2e4c46e04810dcf5c2898b2c337424eefec
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/888224
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=none
BUG=none
TEST=none
Change-Id: I0e7f21bd56a796d2261ffafa26f603924ac0d66d
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/896395
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the sn5s330 PPC is being used to detect VBUS presence
(CONFIG_USB_PD_VBUS_DETECT_PPC), then enable interrupts and call
usb_charger_vbus_change when VBUS_GOOD changes.
BUG=b:72007153,b:72007492
BRANCH=none
TEST=Connect 3A and 1A USB-A chargers to each of Grunt's USB-C ports,
check that BC1.2 detection is working:
With 1A:
> chgsup
port=0/1, type=7, cur=500mA, vtg=5000mV, lsm=1
With 3A:
> chgsup
port=0/1, type=7, cur=2400mA, vtg=5000mV, lsm=1
TEST=Boot Grunt to OS, then connect USB2 mouse or USB3 flash drive to each
of Grunt's USB-C ports. Devices do not work due to b:71772180, but gpioget
shows EC is setting USB_C0/1_BC12_VBUS_ON_L correctly.
Change-Id: Iffc352105a321997adb364b9fbb8bafef248c224
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/887938
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Boards with a PPC will use the PPC to discharge the VBUS line instead
of the TCPC or GPIO discharge path.
BRANCH=none
BUG=b:72179253
TEST=Fall time after device removal on grunt within spec now
Change-Id: I822923a1cedb32a20efc3610cce4437ade3387f0
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/886563
Reviewed-by: Edward Hill <ecgh@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PPC needs to update its Vbus source current limits whenever our
policy changes on the PD ports. This commit simply adds and API to do
so.
BUG=None
BRANCH=None
TEST=With some extra code to enable 3A out, flash zoombini; Plug in a PD
device to a port, verify that it gets 5V @ 3A. Plug in a second device,
verify that we re-send new source caps of 5V @ 1.5A.
TEST=Repeat above for meowth.
Change-Id: Ifa4bc8b7df87f7730f2bcded842906d43171394b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/818335
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, the only events that are unmasked by default are overcurrent
conditions on PP1. This commit adds a simple interrupt handler and
introduces a board specific callback when the overcurrent status changes
on a port. This way, a board can take whatever action it desires with
the notification.
BUG=b:69139844
BRANCH=None
TEST=Flash zoombini with SN5S330 stuffed. Verify that board boots okay.
TEST=With some extra code to setup the interrupt handler, attempt to
exceed the current limit set, verify that interrupt handler is called.
Reduce the current pulled to under the current limit, verify that the
condition is no longer present.
CQ-DEPEND=CL:797937
Change-Id: Id3321c5703f9608da895be0ed5841f2fb76e734e
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/797936
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SN5S330 has support for detecting when Vbus is present on a port.
This commit simply adds an API to query the PPC.
BUG=None
BRANCH=None
TEST=`make -j buildall`.
TEST=Flash a board with the SN5S330, with some extra code, verify that
Vbus can be detected with this API.
Change-Id: I45bf7ff24bcdc447efe12932f51f8094108e29d5
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/791502
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default sourcing current limit can be set by the following config
option:
CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT
However, the way that this macro was being used was incorrect for the
SN5S330 driver. Since, enum values are not known at compile time, the
check needs to happen during runtime. This commit makes this change.
BUG=None
BRANCH=None
TEST=Enable CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT on a board that uses
the SN5S330, verify that there are no build errors.
Change-Id: I04a1fa1e2e42c2f4ba49f1769857a8796b2f0a6f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/791501
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a driver framework for power path controllers.
It provides some common PPC APIs as well as allowing a board to use
multiple different PPCs drivers/parts. This should make it easier to
add PPC drivers in the future.
BUG=None
BRANCH=None
TEST=`make -j buildall`
TEST=Flash zoombini; verify PPC works as expected.
TEST=Flash meowth; verify PPC works as expected.
Change-Id: Icfb99f384610590b431456cfd28d4aff18442cb2
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/807630
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It'll be easier to add support for new PPCs if we make a generic API.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: I9aac1750eb4c163eb2b94aa8975c797f86d0a25a
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/791499
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It will be useful to determine if a FET is enabled or not. For example,
to determine if we are sourcing power to a downstream device. This
commit simply adds an API to check if a FET is enabled or not.
BUG=None
BRANCH=None
TEST=`make -j buildall`
Change-Id: I1f8198342cf225ce9a10d218607bcfbe6aef618c
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/791498
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the SN5S330 is powered initially, there will be certain events set
that will assert its interrupt line. As part of the initialization for
this part, we should clear all the pending interrupts and setup the
masks for the events that we care about.
This commit clears all interrupts at init time and masks all interrupts
except for overcurrent condition for PP1.
BUG=b:69139844
BRANCH=None
TEST=Flash zoombini; With nothing plugged in, verify that the interrupt
line is deasserted at boot.
TEST=Repeat the above test with a charger plugged in.
Change-Id: I7acc030184b76d6c38a729cb64658f71e376c819
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/783510
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
This commit adds a basic driver for the TI SN5S330. This driver just
sets up the IC and provides an API to turn on or off the PP2 FET.
BUG=b:67663166, b:67663124
BRANCH=None
TEST=Enable code for zoombini; Flash a board which has the SN5S330
stuffed; Verify that we're able to perform PD negotiation and negotiate
all the way up to 20V.
TEST=Boot only on AC. sysjump to RW, verify that board does not
brownout.
Change-Id: I9c147ee8465eed878843cf902db301d62e8f627e
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/722104
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
|