On ANX port connecting hoho and issuing hard reset
never recovered. From TCPCI spec R1.0.4.7.2 "TCPM
writes to the RECEIVE_DETECT register to enable PD
message passing". This was missing when the port sent
HARD RESET when it acts as SRC.
BRANCH=none
BUG=chrome-os-partner:61377
TEST= On Electro, on anx port, connect hoho and issuing
pd 0 hard successfully recovers from hard rst
Change-Id: Ia2cfcaf52b88fbc24ee702c6a089389400eb42d1
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/433387
Commit-Ready: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
- Modified src attach state to enable vbus when debug accessory is
detected.
- servo_v4 has two pd ports, but each port requires a different default
power role. Port 0 can only ever be a SNK, but port 1 which acts is
intended to be a DTS port should default to a SRC so it can be be a
source debug accessory. It may also act as a sink debug accessory, but
is not intended to toggle automatically but will swap roles if
necessary via pd role swap messaging.
- Add hook for ccd enable/disable for DTS mode
BUG=chrome-os-partner:61878
BRANCH=servo
TEST=Manual Verfied that can still build servo_v4 project. All changes
in this CL are contingent on config option CONFIG_USB_PD_DTS being enabled.
Change-Id: Iab968b6fbdfc8f2d155c4f8618921b32f313b9ec
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428308
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In Sink mode, on the receipt of a GotoMin message,
reduce the current consumption to some minimum level.
BUG=chrome-os-partner:33688
TEST=Manual testing
Used a Kevin, with test routine, to test GotoMin feature
on another Kevin unit.
Test routine:
if (!strcasecmp(argv[2], "gm")) {
ccprintf("send goto min\n");
send_control(port, PD_CTRL_GOTO_MIN);
send_control(port, PD_CTRL_PS_RDY);
}
Kevin with GotoMin feature:
# ectool usbpdpower 0
Port 0: SNK DRP PD 4277mV / 3000mA, max 5000mV / 3000mA / 15000mW
Port 1: Disconnected
After Test routine is executed:
# ectool usbpdpower 0
Port 0: SNK DRP PD 4906mV / 500mA, max 5000mV / 500mA / 2500mW
Port 1: Disconnected
BRANCH=none
Change-Id: Iaac6e19706ceb10ccaff4d602d63fc086c808c8f
Reviewed-on: https://chromium-review.googlesource.com/425728
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Servo_v4 requires the ability to have a different default state per
port. In previous devices, the assumption was that each supported port
had the same default usb pd state and power role. This CL moves the
by the default power role which in turn is derived from
CONFIG_USB_PD_DUAL_ROLE. In addiiton to moving the location, it now
uses 'port' as argument so it can be port specific if required.
PD_DEFAULT_STATE was a board.h specific config, but in practice each
instance used to date was set to PD_STATE_SNK_DISCONNECTED if
CONFIG_USB_PD_DUAL_ROLE was defined and set to
PD_STATE_SRC_DISCONNECTED otherwise.
BUG=chrome-os-partner:61878
BRANCH=servo
TEST=Manual run 'make -j buildall' to verify that all instances of
PD_DEFAULT_STATE were removed.
Change-Id: Iaf40718668732f525485ed7942ee7fc246d3f75d
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/431787
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
VDO_CMD_GET_LOG is sent for each port from a host command handler, so we
must ensure that it returns quickly to prevent host timeout.
BUG=chrome-os-partner:61910
BRANCH=gru
TEST=Manual on kevin, attach hoho and verify 'cros-ec-spi' timeout
errors are not seen every 60s. Also verify that zinger pdlogs are
correctly retrieved.
Change-Id: Ie0466a8b614ec6bfe5874cde9d700e80a15d298e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428164
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Auto-role toggle on the anx74xx does not function correctly with
e-marked cables and cannot be used.
Also check for TCPC support for auto-toggle at runtime, to allow
auto-toggle supported TCPC to be used alongside an unsupported part.
(from CL:420405)
BUG=chrome-os-partner:60890
BRANCH=reef
TEST=Manual on reef, boot to S0:
`pd 0 state`: Toggling between SRC_DISCONNECTED / SNK_DISCONNECTED
`pd 1 state`: DRP_AUTO_TOGGLE
Also verify port 0 can become sink + source correctly in S0.
Change-Id: Iafdedf31773feef23923cefe1f4fb02fcffda120
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420866
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This is useful with Apple's HDMI adapter, as the code that sends
the discovery message will also swap vconn as required.
BRANCH=none
BUG=chromium:644663
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
display works.
Change-Id: I21d47c69e2c7153a5d808dedcb1abe360ce3f5c0
Reviewed-on: https://chromium-review.googlesource.com/415698
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
During discovery, if adapter requests vconn power in the AMA flags,
make sure that we provide vconn.
This, for example, is necessary for the Apple HDMI adapter to work
on boot, when connected in S5. In that case, adapter does request
vconn swap, but we reject that as the system is off, and, therefore
5V supply is off. On boot, we send another discovery request, which
will detect this case and swap the power.
BRANCH=none
BUG=chromium:644663
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
type "pd 0 vdm ident" in console, display works.
Change-Id: I55b6658c2bc0574b8427ae086f61daf03730a725
Reviewed-on: https://chromium-review.googlesource.com/415697
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rename the variable to actually tell us what it does (it sends a
Discover Identity command), instead of littering the code with
comments explaining why we set DATA_SWAPPED when the data roles
have not really been swapped.
BRANCH=none
BUG=chromium:644663
TEST=make buildall -j
Change-Id: Idbad38e48a55d6518ef82b32a4d96fee65264aae
Reviewed-on: https://chromium-review.googlesource.com/415696
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We currently rely on *head == 0 as error condition, which is
fragile and inconsistent across TCPCs implementations.
Instead, let's return a proper return value on all implementations.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: If7235e0491e9f80fdd50ce2605477ee518f8e1aa
Reviewed-on: https://chromium-review.googlesource.com/417443
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Upon requesting a PD power contract at a new voltage, keep the input
current limit at 500mA until PD_RDY is received.
BUG=b:30744563,chrome-os-partner:59311,chrome-os-partner:44340
BRANCH=ryu, gru, glados
TEST=Manual on kevin, set ilim to 5V through `chglim` console command,
attach zinger. Set ilim to 20V through `chglim`, verify that ilim goes
from 3A to 500mA to 3A.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I452f183cfb958780e336a9f99dc6398356de17a0
Reviewed-on: https://chromium-review.googlesource.com/399918
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When a WAIT is received in response to a request, wait SinkRequestTime
before resending the request.
BUG=chrome-os-partner:34984
TEST=make -j buildall
BRANCH=none
Change-Id: I5c8429c4a7b9cf06609996f924b8d9d535ab6b5f
Reviewed-on: https://chromium-review.googlesource.com/414533
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:55158,chrome-os-partner:55889,chrome-os-partner:55890
BRANCH=none
TEST=on reef use ina (pp3300_pd_a_mw) to check tcpc power consumption
Change-Id: I5a2904f4e549b7da22242848bb3b1887331ecadd
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/399882
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:54668
BRANCH=none
TEST=Verified SNK is detected in S0 (toggle on), S3 (toggle off),
and S5 (force sink). SRC is detect in S0 only, stays detected when
entered S3, but unplug/plug while in S3 will not re-detect until
system back in S0. When go to S5, SRC will get disconnected until
back in S0, and hotplug SRC in S5 will not get detected. Checked
power role swap with another chromebook in the above scenario also.
Change-Id: I2a487fca5cb04c45524aa3efde84fcd10ff0579e
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/396918
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Shifted pd_task debug level by 1 so that debug level 1 will
enable printing the pd state name.
Added a CONFIG flag to remove ability to change debug_level
during runtime and debug print level will be fixed.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I545813bafa8084355cedc2d8334c3aec5a2b6739
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/339935
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Don't call into tcpm_*() functions from HOOKs since these functions may
manipulate common sets of TCPC registers.
BUG=chrome-os-partner:57691
BRANCH=gru
TEST=On kevin, boot to S0, verify 5V is sourced to legacy peripheral.
Drop to G3, verify role is back to sink and charging is functional. Back
to S0, verify 5V is sourced.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9ade9de068589dce6995cda6b106217aa85aa793
Reviewed-on: https://chromium-review.googlesource.com/394809
(cherry picked from commit 18e9e3870722d57efd232bd7f0a0300003b46ad6)
Reviewed-on: https://chromium-review.googlesource.com/396137
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a policy to handle the case where the device can source the
`CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT` over one of its type-C port if
there is no sink connected on the other ones.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:56110
TEST=manual: on Kevin, plug and unplug various devices on the 2 ports,
while measuring the type-C pull-up with Twinkie.
Change-Id: Id5961f04d0a1b1073f5ab340068efd9079918209
Reviewed-on: https://chromium-review.googlesource.com/373818
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If a TCPC fails to initialize then the PD task probably won't
function as expected when put in its default state and the console
will likely get spammed with errors. Fall back to the suspended
state instead.
BUG=none
BRANCH=none
TEST=booted on Reef EVT without TCPC1 connected, console is
no longer spammed with errors.
Change-Id: I94577c065e53bc6076c507b50c5bec22dbd8bdce
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376182
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add API to switch the Rp pull-up value on CC dynamically at runtime.
This is a preparatory work for boards having a more complex maximum
source current policy (eg 2 ports sharing a common pool of power).
For fusb302, update the voltage thresholds for open/Rd/Ra as they depend
on the Rp (was missing from the previous change).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:56110
TEST=make buildall
Change-Id: Id3c24a31a16217075a398ec21ef58ee07187a882
Reviewed-on: https://chromium-review.googlesource.com/373501
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
when TCPC takes a longer time to update its CC status upon
connection, a legacy C-to-A charger or certain Type-C charger
that presents 5V VBUS by default, TCPM could be mistaken the
charger as a debug accessory.
BUG=chrome-os-partner:55980
BRANCH=none
TEST=Manually tested on Reef. PD, Type-C, BC1.2, non-BC1.2,
DP, HDMI are working on both C-ports.
Change-Id: Ic3b0ecd3d14109239d8c0ff0064476595b7f93a0
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/367950
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Support Rp/Rp debug accessories in the USB PD state machine
including detecting the polarity and the available type-C current.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:52592
TEST=manual, plug a Suzy-Q reworked with Rp3A0/Rp1A5 resistors
on a Kevin, and see the PD state machine is going to
PD_STATE_SNK_ACCESSORY (and leaving it on unplug).
Re-verify a few existing accessories (Rd/Rd SuzyQ, legacy RpUSB cable,
Rp3A0 power supply).
Change-Id: Icef6c90027105d7c633f2785210ab9dae74fc33c
Reviewed-on: https://chromium-review.googlesource.com/368700
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When the case close debug (CCD) feature is provided by an external chip
(e.g security chip or TCPC), we still need to be able to detect debug
accessory with Rd/Rd (by setting Rp/Rp when VBUS is detected without
seeing Rp).
Add a CONFIG_CASE_CLOSED_DEBUG_EXTERNAL configuration parameter for this
case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:55410
TEST=manual:on Kevin, enable CONFIG_CASE_CLOSED_DEBUG_EXTERNAL,
plug a SuzyQ (with Rd/Rd) and verify that the device in debug mode
when transitioning to S5.
Change-Id: Ie04a000a7b0eb670e3808f7bca1180298dfcd9db
Reviewed-on: https://chromium-review.googlesource.com/363400
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When we jump from RO to RW, tcpc_vbus declared in tcpci.c
is initialized to 0. So even if we had VBUS present before,
PD_FLAGS_VBUS_NEVER_LOW is not set and soft reset cannot be used
later when source cap is timeout. This causes power loss and reboot
when we boot up system without battery.
Set PD_FLAGS_VBUS_NEVER_LOW after tcpm_init() so we can refresh
tcpc_vbus from TCPC first.
BUG=chrome-os-partner:53496
BRANCH=none
TEST=test on elm.
Remove battery and boot up successfully only with AC.
Use "sysjump rw" command and ec won't reboot by pd hard reset.
Change-Id: Id4737f076a9572cb540310f9fdce062198257967
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/352833
Reviewed-by: Rong Chang <rongchang@chromium.org>
If i2c communication with the TCPC is failing after 300ms+ then it's
likely going to fail forever, so return an error to allow the PD task to
continue initialization.
BUG=chrome-os-partner:53815
BRANCH=None
TEST=Manual on reef. Disconnect TCPC, attach charger to other port, and
verify charge manager correctly sets current limit based on detection.
Change-Id: I2c12320971a77504292f75393791e609e34897b4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/352501
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In TCPCI specifiction R1.0 4.7.2, the last step of transmitting
hard reset message is enable PD message passing by writing to
RECEIVE_MESSAGE register.
BRANCH=none
BUG=chrome-os-partner:52815
TEST=manual
build and load on reference board with anx7688 port controller.
connect zinger to port 0, and use ec uart console to send hard
reset message:
pd 0 hard
check PD communication
Signed-off-by: Rong Chang <rongchang@chromium.org>
Change-Id: I52968b603f0227d7d9a112b0216cd5fd6362a0b2
Reviewed-on: https://chromium-review.googlesource.com/348142
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This commands makes it possible to control the PD chip (or
the interaction between EC and PD), from the AP.
- PD_SUSPEND: Suspends the PD chip: EC needs to stop talking
to PD chip. Useful at beginning of PD FW update.
- PD_RESUME: Resumes the PD chip: EC can start talking to PD
chip again. Useful at end of PD FW update.
- PD_RESET: Resets the PD chip (called at the end of the update).
- PD_CONTROL_DISABLE: Prevents further calls to this command
(for security reason, we do not want the AP to be able to
call the other subcommands after the update has been performed).
BRANCH=none
BUG=chrome-os-partner:52433
TEST=ectool pdcontrol {suspend,resume,reset,disable}
Change-Id: I7a955dd27b65086c21d195a6504aa7392eb0406d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342584
Reviewed-by: Randall Spangler <rspangler@google.com>
Also, make sure that pd_set_suspend can work asynchronously,
but looping until the status is read back as SUSPENDED.
BRANCH=none
BUG=chrome-os-partner:52433
TEST=On elm:
ectool pdcontrol reset
sleep 0.1
ectool pdcontrol suspend
i2cset -f -y 2 0x28 0x05 0x10
=> No I2C communication with ANX7688
Change-Id: Iad7b500f1af554e2bc4f64f90ee0a492f903749a
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347730
Previously CONFIG_USB_PD_TCPM_VBUS had two uses which were independent:
- When operating as a TCPC, it indicated that the VBUS level should be
tracked (through GPIO inputs) and sent to the external TCPM when
appropriate.
- When operating as a TCPM, it indicated that the VBUS level should be
obtained by querying the TCPC.
These two independent uses have been split into
CONFIG_USB_PD_TCPC_TRACK_VBUS and CONFIG_USB_PD_VBUS_DETECT_TCPC, which
sould be more clear.
In addition, CONFIG_USB_PD_VBUS_DETECT_* CONFIGs have been added for
other means of VBUS detection.
BUG=chromium:616580
BRANCH=None
TEST=Verify kevin continues to boot + charge.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I936821481d6577e17e3e9c61ff97c037574d6923
Reviewed-on: https://chromium-review.googlesource.com/348950
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously calls to hook_call_deferred were passed the function to call,
which was then looked up in the .rodata.deferred section with a linear
search. This linear search can be replaced with a subtract by passing
the pointer to the deferred_data object created when DECLARE_DEFERRED
was invoked.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
CQ-DEPEND=CL:*255812
TEST=make buildall -j
Change-Id: I951dd1541302875b102dd086154cf05591694440
Reviewed-on: https://chromium-review.googlesource.com/334315
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In case of boot after battery is cut-off without this
change the battery is assumed to be present even though it
is not initialized and ready to provide power in try source
enable function. With this assumption charger is disconnected
momentarily which causes reboot.
Also make sure that try source enable is updated after battery
is ready by notifying hook call HOOK_BATTERY_SOC_CHANGE.
BUG=chrome-os-partner:51753
BRANCH=firmware-glados-7820.B
TEST=Enter battery cutoff command from EC console to enter into ship
mode and plug-in AC, verified no reboots happen.
Change-Id: I6f7656125717f85851f5ad4e37dfd953a52799c6
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/335913
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 10040ac6284efe88b74193bdbb0c05ec92b563b4)
Reviewed-on: https://chromium-review.googlesource.com/336697
Commit-Ready: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
The scheme to disable PD communication in locked RO needs to be
implemented on other platforms, so move it to common code, behind
CONFIG_USB_PD_COMM_LOCKED.
BUG=chrome-os-partner:52157
BRANCH=glados
TEST=Manual on chell. Lock system and boot to recovery, then verify PD
communication is functional. Enable CONFIG_USB_PD_COMM_LOCKED and verify
PD communication isn't functional under the same test conditions.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8d1f24c0b60cf1c54e329af003b7083ee55ffc40
Reviewed-on: https://chromium-review.googlesource.com/338064
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
If we have already completed negotiation as a sink and
pd_send_request_msg() fails, issue a soft reset so we don't remain
indefinitely at our previously negotiated voltage.
BUG=chrome-os-partner:50346
BRANCH=glados
TEST=Manual on chell. Attach zinger to port 1, then attach zinger to
port 2. Verify that port 1 negotiated to 20V. Detach port 1 and verify
port 2 successfully negotiates to 20V and begins charging.
Change-Id: I4f8ff9a1e3ef49858f6ae5c3ccb5b5d4d847e2d1
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/332642
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When forcing a sink role (eg. on transition from S3->S5), make sure
we're not sourcing VBUS. Otherwise, if a power source is attached, we
will fail to charge from it, due to the inability to sink and source
VBUS simultaneously.
BUG=chrome-os-partner:49544 chrome-os-partner:50343
TEST=Boot chell, attach USB-C peripheral, then power down chell. Remove
USB-C peripheral, attach zinger, and verify PD negotiation + charging
succeeds.
BRANCH=glados
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fb9b0eb26e61daa93a167d6a3e9aaf4e4eeed39
Reviewed-on: https://chromium-review.googlesource.com/327727
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Divagar Mohandass <divagar.mohandass@intel.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Resetting our state to default without also resetting the power role may
lead to a state / role mismatch.
BUG=chrome-os-partner:49563
TEST=Verify kunimitsu correctly detects charger at either polarity on
sysjump.
BRANCH=glados
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I239df9793773429e9b84a847e55d6753577fab32
Reviewed-on: https://chromium-review.googlesource.com/325385
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If we're still in DISCONNECTED or DISCONNECTED_DEBOUNCE state, don't check
CC lines to detect a disconnect since CC polarity has not yet been
established.
BUG=chrome-os-partner:48220
BRANCH=None
TEST=Verify PD contact can be negotiated on Snoball with either polarity.
Change-Id: Iacde14446c0ff5d2170936b650f56668038f613e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315780
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Always initialize TCPC when TCPM boots. This guarantees
that our TCPM driver is synced up with the TCPC reg values.
BUG=chrome-os-partner:47608
BRANCH=none
TEST=test on glados. reboot EC and PD MCUs independently
with and without external power.
Change-Id: I2d989e8a85ba8a72fe1a8edaef8da9c51651d240
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312951
Reviewed-by: Shawn N <shawnn@chromium.org>
Fix bug with the new VBUS_NEVER_LOW flag in which if a BC1.2 charger
is attached on boot, we will not set the charger as a dedicated
charger and therefore not charge from it, until the charger is
disconnected and reconnected. This happens because in SNK_DISCOVERY
we will send soft reset first, and then when the charger doesn't
respond, we send hard reset. But, registering the charger as a
dedicated charger previously only happened when we send hard reset
directly after SNK_DISCOVERY state.
BUG=none
BRANCH=none
TEST=tested on glados. sysjump with bc1.2 charger plugged in and make
sure we charge from it.
Change-Id: Ida89304092a2186bcb2aa885917d706231490288
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311364
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Added more improvements to power consumption when using
CONFIG_USB_PD_LOW_POWER. On the TCPC, when this option is
defined, then decrease the PD task wake interval when
we are presenting Rd, we don't have a connection, AND we
haven't dual-role toggled recently. This shouldn't affect
connection time because we will get an interrupt when VBUS
is detected.
Note: we can't use the low power task wake interval when
we are connected because we need to monitor CC line for
Rp change and we can't do this when we are presenting Rp
because we need to quickly detect loss of Rd.
BUG=chrome-os-partner:45010
BRANCH=none
TEST=tested on glados. verified we connect to a charger in
S0 and S5. and verified that in S5, we spend >99% of our
time in deepsleep (as measured by idlestats console command).
note, that when testing EC and PD must both define
CONFIG_USB_PD_LOW_POWER to get maximum power improvements.
Change-Id: I661110cc7021f6d17937688787ea4f5f4b82973d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309310
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On boot, if VBUS is present, then when PD protocol gets to
SNK_DISCOVERY state, if it times out waiting for source cap,
then send attempt to send a soft reset first instead of
directly sending a hard reset. This allows us to not lose
VBUS in the case that we were in a stable contract as a sink
before this boot (for example a sysjump or EC reboot).
BUG=chrome-os-partner:44085, chrome-os-partner:44952
BRANCH=none
TEST=test on glados and samus. test by sysjumping between
RO and RW with zinger plugged in and no battery, and verify
that we don't lose power. also test rebooting with a battery
and verify we don't lose power. also tested with a third
party PD charger.
Change-Id: Ib7ce46d8b9843db66805ba3237d8919d611324e0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308201
Reviewed-by: Rong Chang <rongchang@chromium.org>
On TCPC startup, set an alert to notify TCPM that we have been
reset. When TCPM gets this notification, it should re-send
initial TCPC parameters. If we were in a stable contract as
a sink, make sure we don't reset connection. If not, then
reset PD protocol state machine to the default state.
This fixes a bug where if the TCPC reboots while the TCPM is
still running, then the TCPC would not get re-initialized and
therefore no PD communication would not work. This also fixes
it such that if we are in a stable contract as a sink and the
TCPC reboots, then we don't lose power.
BUG=chrome-os-partner:46676
BRANCH=none
TEST=tested on glados. reboot PD MCU with and without a charger
plugged in and verify that PD communication works after the
reboot. verify that with a charger, we don't lose power.
also tested with a hoho plugged in during reboot.
Change-Id: I84fec4577b0daf5891bd8461d3f3d925014a5ecf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307187
Reviewed-by: Shawn N <shawnn@chromium.org>
Remove duplicate code for checking request message, but keep
a board specific check of the request message for custom checks
needed on zinger and plankton.
BUG=chrome-os-partner:42490
BRANCH=none
TEST=make -j buildall. run on samus and connect a hoho, make
sure we successfully negotiate a contract.
Change-Id: I7398953a158d340e3e113f5a816b55445a857711
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305374
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When a PD charger is found, we typically update charge manager
voltage / current limits to what we want to request, set a 500mA ceiling,
and then wait for negoiation to complete. If it completes as expected,
we simply remove the 500mA ceiling.
When we're already negotiated with a port and we receive a new power
request, we may switch to a different voltage / current limit. If we do
so, charge manager won't get updated with the existing design because we
don't get new source cap information. Therefore, update charge manager
whenever we receive PD_CTRL_PS_RDY as a sink. Typically, the update will
have no effect because we'll be writing identical values. In the new
power request case though it will serve to inform charge manager of the
new mode.
BUG=chrome-os-partner:45932
TEST=Manual on ryu. Insert zinger, run `pd 0 dev 5` followed by `bq` to
verify 3A limit is set as expected.
BRANCH=ryu
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8cc3ac0a3eb603cdeb45ea437906303abcaedac0
Reviewed-on: https://chromium-review.googlesource.com/302844
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add more flags to EC_CMD_USB_PD_CONTROL including whether
the port partner is PD capable, and if the port partner has
any of the following flags set in its capabilities: dual-role
power, dual-role data, USB comms capable, and externally
powered.
BUG=none
BRANCH=smaug
TEST=tested on samus using 'ectool --dev=1 usbpd 0'. Tested
with zinger, guppy, another samus, and other third party
devices to verify the flags are set as advertised in src/snk
capabilities packet
Change-Id: I4d78d1880073fdacce57516111ac6cab37b93f27
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/300953
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
