If VBUS toggles between 'present' and 'not-present', and fusb302 is the
arbiter of VBUS presence, wake the PD task so that it can take the
necessary protocol actions (eg. transition out of HARD_RESET_RECOVER).
BUG=b:69482362
BRANCH=None
TEST=On scarlet, issue EC reset with CableCreation source dock plugged,
verify we don't end up in hard reset loop.
Change-Id: I88d6102a6b5f4bd5151bae117c70f0a3ac0c09e7
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/804660
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On Nasher, sending TCPC_TX_BIST_MODE_2 to register 0x50 on the
PS8751 TCPC does not generate BIST Carrier Mode 2.
BUG=b:68337231
BRANCH=None
TEST=`make -j buildall`
Generated an eye diagram for Nasher on the GRL USB-PD test station
Signed-off-by: Sam Hurst <shurst@chromium.org>
Change-Id: Ia6e5df54a183c989a68d12be3a46896e3daea738
Reviewed-on: https://chromium-review.googlesource.com/741090
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We found a potential risk that voltage might fed back into EC Vcore.
If the CC pin voltage detector is enabled and there is an unexpected
voltage source over 3.3v fed back into EC, this might cause an
exception or unknown reset.
BRANCH=none
BUG=none
TEST=The voltage detector is enabled after vconn is offed.
Change-Id: I78975fa195eef0b96056a39ee3c6d92c3bb6f8c0
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/647673
Reviewed-by: Randall Spangler <rspangler@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
fusb302 determines attach / no-attach (and Rd / Ra) by comparing CC
voltage against an MDAC output (42 mV steps). The previous 'floor'
calculation was particularly bad for 3.0A Rp (2600 / 42 = 61, 61 * 42 =
2562 mV - 21 = 2551 mV actual threshold, ignoring other error sources).
Reduce the chance of error by rounding our thresholds, which also
matches the suggested thresholds in the datasheet.
BUG=chromium:758608
BRANCH=gru
TEST=Attach problematic dingdong, verify we don't enter an attach /
detach loop.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9211782da0fdad8339246e272952ba1930b69851
Reviewed-on: https://chromium-review.googlesource.com/633276
Reviewed-by: Joe Bauman <joe.bauman@fairchildsemi.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 311b3e4e15fd37ea2ab151edb8b8a468e93355fd)
Reviewed-on: https://chromium-review.googlesource.com/638694
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
fetching the chip firmware version toward the end of the chip
anx74xx_tcpm_init() sequence is a good place to do this. we need this
info in any case and this is a safe place to access device registers
and cache the values. subsequent chip firmware queries typically
return the cached value. also, tcpci_tcpm_init() is already
structured this way.
TEST=verified with follow-up CL that firmware update succeeds and new
version is reported
BRANCH=none
BUG=b:35586895
Change-Id: Ic3fd07bbf8a220bfd506d59d8a1f3ea25b14e94c
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/634513
Reviewed-by: Shawn N <shawnn@chromium.org>
TEST="make buildall" succeeds, "make runtests" passes for reef.
returning SUCCESS instead of UNIMPLEMENTED from .release() means the
pd_task() is allowed to reinitialize the TCPC when coming out of
PD_STATE_SUSPENDED or similar scenario.
TEST=verified anx3429 firmware update succeeds, USB port still usable
for charging after update.
BRANCH=none
BUG=b:35586895
Change-Id: I1a624ccf25dfa6468de72f8564f936bc0a35edb1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/596797
Reviewed-by: Shawn N <shawnn@chromium.org>
the ps8xxx family of TCPCs (ps8751, ps8805) have historically used the
generic tcpci_tcpm_drv functions, but we need to override some of
these entry points because the parade parts need to be woken up before
accessing registers.
in most cases, this doesn't matter because we access the chip in quick
succession where we can "safely" assume the chip is awake -- and the
code is structured to implicitly keep the chip awake. the new case we
need to address here is where we need to suspend the pd_task and TCPC
at an arbitrary point in time. the driver's .release method is called
to shut down the chip, and that involves first waking up the chip to
be able to access its regs to mask off interrupts, etc.
BUG=b:35586896
BRANCH=none
TEST=tested from depthcharge - we no longer get errors in the EC
console logs about TCPC "release" failed.
Change-Id: Ic2a90b71050b3f68c697b1cef48d736ed88b3f41
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/616460
Reviewed-by: Shawn N <shawnn@chromium.org>
This commit adds support for the PS8805, another Parade Tech TCPC with
integrated superspeed muxes. This also creates a generic Parade Tech
TCPC driver which supports the PS8xxx series.
The current supported TCPCs are:
- PS8751
- PS8805
BUG=b:63508740
BRANCH=None
TEST=`make -j buildall`
Change-Id: I78383af414996e0e8d6220985d286f95267136f8
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/564799
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Use existed macro instead of creating new one.
BRANCH=none
BUG=none
TEST=plug USB-C power adapter and USB-C to hdmi adapter, both work.
Change-Id: I133142232ac6abfa7f285c289eb03c4d65e84d5f
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/554655
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
similar to the USB_PD_TCPC case, add release/init operations when the
pd_task enters/leaves the PD_STATE_SUSPENDED state. one use case for
PD_SUSPEND is to get exlusive access to the TCPC for things like
firmware update, so the release/init operation is needed to get the
TCPC and driver into a good state.
updated all tcpm_drv style drivers. for backward compatibility, "old"
drivers that may not handle init/release properly simply return
EC_ERROR_UNIMPLEMENTED for tcpm_release(). pd_task() uses this as a
signal that it should not try to re-init() the driver.
TEST=tested in combination with follow-on CLs to do TCPC firmware
update on electro. also built for kevin, eve, sand which are
some of the other boards using these drivers.
"make buildall -j" passes.
BRANCH=none
BUG=b:35586896
Change-Id: I3d2964a79e710428f7a6e7004d68ab424af85be8
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544660
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to ensure we are always meeting the deadlines for the IRQ_HPD
pulse, increase the priority of the processing by moving the rising edge
from the low-priority HOOK task (in a deferred function) to the caller
task (which is the high-priority PD task).
The downside is we are now sleeping in the PD task blocking the
processing of the PD messages during this time.
Changed HPD_DSTREAM_DEBOUNCE_IRQ to 500us instead of 750us. According
to DP spec, the IRQ_HPD pulse width is between 500us and 1000us.
Ensure there is a minimum of 2ms delay in between each IRQ_HPD as specified
by the DP spec, by sleeping before sending the next pulse if needed.
(in practice, this should not wait if we are not too off processing the
messages)
BUG=chromium:711334
BRANCH=glados strago reef oak
TEST=manual, on SKL platform with kernel 3.18 and MST, verify display is
functional on USB-C dock.
Change-Id: Ib2e9dd608c5f1c671cc5a0fd979a5742101375ff
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/508629
Reviewed-by: Todd Broch <tbroch@chromium.org>
The trimmed value of CC parameter setting registers
(port0: ff3760h ~ ff3763h, port1: ff3860h ~ ff3863h)
will be reset to default after a soft reset (system_reset()).
BRANCH=none
BUG=none
TEST=Console command 'reboot' and checking if the value of
cc parameter setting registers are correct (trimmed).
Change-Id: Ibf9c72e8aeef36701d72bcb64529735295295cdf
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/513744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We can get the correct chip info after the change was made.
BRANCH=none
BUG=none
TEST=console message:
[0.013915 TCPC p1 VID:0x48d PID:0x8320 DID:0x1 FWV:0xec]
[0.018054 TCPC p0 VID:0x48d PID:0x8320 DID:0x1 FWV:0xec]
Change-Id: I4eb94967acb351559e745ed1c4e34a4c58f41e14
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/487767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These are options for features can be implemented if they are required.
BRANCH=none
BUG=none
TEST=build 'it83xx_evb' board with pd modules.
Change-Id: I1afb7d9c2d764728a375563a6739544032394c54
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/483319
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before entering standby mode, bit 7 (cable_det) or analog_ctrl_0 is
cleared. This allows a new cable detect event to trigger the EC to
put the ANX4329 into normal mode. However, in some cases such as when
in S3/S5/G3 chipset power states a port will be in sink only mode and
therefore won't attach when a sink only adapter is connected to the
port. This results in the an indefinite toggle of standby<->normal
mode transitions. This constant toggle floods the EC console and more
importantly prevents the ANX4329 from remaining in standby mode and
the power consumption remains at ~9.5 mW instead of ~1.2 mW when no
adapter is connected.
This CL adds logic around clearing the cable_det bit so that it's only
cleared if both CC lines are open or if an Emark cable is
attached. Emark cable is determined from the presence of Ra on one CC
line and no Rd on the other CC line. The special consideration for an
Emark cable is reqiured because when an Emark cable is connected, the
USB PD auto toggle state may require some number of iterations until
the attach event is recognized.
In order to support handle cases where the drp mode is changed via
either the EC console command or host command, added a call to
tcpm_set_drp_toggle whenever the drp state is updated. Since the drp
mode is updated upon chipset resume events, the chipset resume hook in
board.c for anx74xx_cable_det_handler() became redundant and hence it
was removed.
BUG=b:35775019,b:35586188
BRANCH=reef
TEST=Tested the following cases:
- Sink, source adapters in chipset S0. Verified that adapters
connected as expected. Also, used Emark cable to connect to both USB
PD chargers (source) and Pixel phone (sink).
- Run 'lidclose' on EC console then connect Type C -> A adatper
[3490.370125 TCPC p0 reset!]
[3490.389588 TCPC p0 Low Power Mode]
It no longer toggles indefintely and after running 'lidopen' verified
that port 0 is now in SRC_DISCOVERY.
- In S3/G3 connected USB PD charger with regular and Emark typeC
cable. Verified that port 0 is in SNK_READY state.
- use 'pd dualrole sink' and test with Type C -> A adatper. Verified
that tcpc wakes up, but goes into standby mode until entering 'pd
dualrole on'.
- When sink only adapter is connected in S3/G3, measure power level
~1.2 mW as opposed to ~10 mW in S0.
- Repeated similar tests on port 1 (parade tcpc) to verify that
adapters connected as expected.
Change-Id: Ib8de666f72723934186fee7869f9dda01381c7a8
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463991
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: S Wang <swang@analogix.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The cable_det signal is used to signal to the EC that the tcpc has
detected a cable being connected when low power mode is
configured. The driver then needs to take the tcpc out of suspend
state by setting PWR_EN and RESET_N high. Then bit 7 of analog_ctrl_0
needs to be set properly.
The code that is handling this transition was attempting to access the
tcpc via I2C before putting the chip in normal mode when
transitioning from suspend to normal. In addition there are issues
with calling the driver function directly from the hook task (in the
delayed ISR handler) and from the USB PD task.
This CL changes the delay ISR handler to only set the TCPC_RESET
indication so that the call to put the ANX3429 into normal from
standby to normal mode only happens in the USB PD task. The TCPC_RESET
event is only set if cable_det is high, but reset_n (to the ANX3429)
is low which indicates that the ANX3429 is currently in standby mode.
BUG=b:35775019
BRANCH=reef
TEST=Manual
Tested with various adapters in both S0 and S3/G3 chipset
states. Verified that adapters connected as expected. When in S3/G3
connecting a sink only adapter still causes an indefinite toggle, but
all calls into the driver are executed from within the USB PD 0 task
and all ANX3429 I2C accesses work as expected.
Change-Id: I6e4843e43f59afbf5ca3251feb68981b815c1c78
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457103
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
PS8751 does not restore all register contents when resuming
from low power mode. This change makes tcpm call board_init
when it stops auto-toggling so that register contents can be
restored.
BUG=b:35585399
BRACH=none
TEST=On Snappy, the board_init funciton is called every time a device
is plugged in and register contents are restored.
Change-Id: I50c51334f43c02e3c4d8453e1e966bf6eb3ce769
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/454139
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The anx74xx tcpm driver for the usb_mux_set() function is always
connecting the DP aux lines to the SBU signals regardless of whether
the bit flag MUX_DP_ENABLED was set or not. For CCD opertation the sbu
lines are used to establish a USB connection to H1. This means that if
a PD port ever attaches to a sink debug accessory, usb_mux_set would
result in interrupting the USB connection being used for CCD.
In addition, the anx74xx_tcpm_mux_exit() function had a bug where the
value read from ANALOG_CTRL_5 was being masked by 0x09 and then
written to ANALOG_CTRL_2.
Added functions anx74xx_tcpm_mux_enter_safe_mode() and
anx74xx_tcpm_mux_exit_safe_mode() so that writes to the 3 CTRL
registers that are used to configure ALT_DP mode can be easily
bookended.
BUG=b:36007652
BRANCH=reef
TEST=Connected servo_v4 to port 0 of electro, verified that H1 console
access worked. Then initiated a data role swap so that port 0 on
electro was in DFP mode and the H1 console stayed connected.
- Tested with dingdong that could connect to a 4k monitor.
- Tested with USB3 flash drive.
- Tested Anker USBC -> USBA hub
Change-Id: I2d045134fbdd21b6b492bbeabc85ab23aef73b9a
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/451837
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: S Wang <swang@analogix.corp-partner.google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
There were 2 mistakes when setting the data/power roles for automatic
GOOD_CRC:
- the bit numbers for data role and power role were swapped.
- the function can only set and not reset the bits.
Try to simplify this code by:
- removing the duplicated name for register 0x9C (aka AUTO_GOODCRC_1)
- avoiding the multiple read/modify/write by using AUTO_GOODCRC_1 for
the actual settings (and letting the enable bit always on)
and GOOD_CRC_2 for enabling/disabling it, so we can do simple writes.
- answer only on SOP (not SOP' or SOP'').
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=reef
BUG=b:35648282
TEST=On Snappy, connect a given power supply, record the USB PD traces
and see that the GOOD_CRC messages are still correct after the DR_SWAP.
Change-Id: I848b1dcbc0e06806649e64a9664f3fba21bdd448
Reviewed-on: https://chromium-review.googlesource.com/448040
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: S Wang <swang@analogix.corp-partner.google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The function tcpm_select_rp_value() is used to set a given Rp
value. This function was not supported for boards that use the config
option CONFIG_USB_PD_TCPC. This CL adds a weak board_ function which
can be overloaded for boards that have the requirement to set Rp to
different values.
BUG=chrome-os-partner:61878
BRANCH=servo
TEST=run 'make buildall'. On plankton added a console command to trigger
a call to tcpm_select_rp_value(0, 0), verified that it returned
2 (EC_ERROR_NOT_IMPLEMENTED). Then added board_select_rp_value() to
plankton's board.c and verified that it returned 0.
Change-Id: I1cd6f0ed51717736d30575c58025bd9a1c5d6fc4
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446685
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit 18327455c1 ("ANX74xx: add TCPC low power mode for different
DRP state") introduced new code to put ANX74xx in low power mode.
However, this broke existing boards that do not enable
CONFIG_USB_PD_TCPC_LOW_POWER (and therefore do not implement cable
detection interrupt).
BUG=chrome-os-partner:59841, chrome-os-partner:61640
BUG=chrome-os-partner:62964
BRANCH=none
TEST=on poppy, connect USB-A keyboard to ANX port via A-C adapter:
keyboard works
Change-Id: I4b66511b816afee402a7e769aa6d2c323724d071
Reviewed-on: https://chromium-review.googlesource.com/443865
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This change adds an option to pdchipinfo command to force ec to get
the version from the chip instead of the cache (if it's available).
This option will be used after firmware update, which makes the cache
value stale.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=Run ectool as follows:
localhost ~ # /tmp/ectool pdchipinfo 0 on
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # /tmp/ectool pdchipinfo 1 on
EC result 2 (ERROR)
Change-Id: Icefe96d7fc1208b991a4caa13aaf4f04052edba7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441271
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The firmware version formats may vary chip to chip. fw_version field is
changed to a union of a 8 byte string and an 64-bit integer.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1 on Electro
Change-Id: Id51e66c44338a09ed897ee61f54cd6a394400e63
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441270
Added code to put the ANX74xx in low power mode for different DRP state.
1. When nothing attached or system is in S3 or S5 disable the auto
toggling and put ANX74xx system in Analog control mode.
2. Using the CABLE_DET interrupt pin (attach event) enable normal power
mode.
BUG=chrome-os-partner:59841, chrome-os-partner:61640
BRANCH=None
TEST=Manually tested on Reef using below dut-control command
dut-control pp3300_pd_a_mw -r <n>
1. S0, S3, S5 - Nothing connected, ANX in low power mode.
2. In S0 SNK (display/USB dongle, eMark cable) connected & put
system to S3, ANX remains in normal mode.
3. In S0 SNK connected & put system to S5, ANX in low power** mode.
4. In S0 nothing connected, put system to S3 or S5, attach
SNK, ANX in low power** mode.
5. Attach SNK at S3/S5 & boot to S0, ANX in normal mode.
6. SRC (AC adapter) with/without eMark cable are detected in
S0, S3, S5, and continue to charge the system after S-state
transition.
low power**: ANX74xx hardware limitation that Ra/Open (Ex: E-Mark cable
only) detection will trigger CABLE_DET continuously, therefore ANX74xx
will go to normal power mode momentarily and then low power mode in a
loop.
Change-Id: I30f7fd7a85e31987fb77e2cab2fe140d59dd3629
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/415580
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This patch adds a host command to get PD chip info.
For PS8751, tcpci_get_chip_info will fail if the chip is in
low power mode. It can be woken up by reading a random register
first then wait for 10ms.
This code doesn't have the wake-up read to avoid 10ms delay.
Instead, we call this function immediately after the chip is
initialized because it'll gurantee the chip is awake.
Once it's called, the chip info will be stored in cache, which
can be accessed by tcpc_get_chip_info without worrying about
chip states.
localhost ~ # ectool pdchipinfo 0
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # ectool pdchipinfo 1
vendor_id: 0x1da0
product_id: 0x8751
device_id: 0x1
fw_version: 0x37
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1. make buildall
Change-Id: I3f1667d00ce1826936d90882ada1df6ed6b0ea37
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433166
The loss between PS8751 and Type-C connector is large and requires
a larger EQ and low squelch threshold for compensation.
- USB Type-c connector facing receiver equalization setting:
Compensate for channel loss up to 10.9dB
- High Speed Signal Detector threshold adjustment: -25%
BUG=chrome-os-partner:61101
BRANCH=none
TEST=Boot & charge
Change-Id: Ie74e2d0b8ad7206f5e60fb013613c382980c0eac
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433846
Reviewed-by: Vincent Palatin <vpalatin@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>
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>
If a partner port sends a packet at approximately the same time as we
send a packet, we may end up with the initial packet followed by the
GOOD_CRC reply in our HW FIFO. Don't automatically discard the first
packet in the FIFO. Instead, discard the packet only if it's a GOOD_CRC
packet. And, modify our get_message function to automatically discard
GOOD_CRC in search of a meaningful packet.
In addition, due to interrupt latency, we can't rely on receiving one
interrupt per incoming packet. If our Rx FIFO is non-empty, assume that
it contains at least one packet.
BUG=chrome-os-partner:60242
BRANCH=gru
TEST=Manual on kevin, attach Apple dongle with no inputs. Attach zinger,
verify we negotiate to ~20V. Repeat 10x and verify negotiation is
successful each time.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I7e4430fc2b7ed44b1aa4b561d72c8e1e964b245a
Reviewed-on: https://chromium-review.googlesource.com/414927
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 373f5dfd75e8ea5074d26fc6392eafe83de4f905)
Reviewed-on: https://chromium-review.googlesource.com/419186
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@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>
From TCPC spec:
"""
RECEIVE_BYTE_COUNT: Indicates number of bytes in this register
that are not stale. The TCPM should read the first RECEIVE_BYTE_COUNT
bytes in this register. This is the number of bytes in the
RX_BUFFER_DATA_OBJECTS plus three (for the RX_BUF_FRAME_TYPE and
RX_BUF_HEADER).
"""
We were always reading 3 bytes too many. This is an issue if we
receive a packet followed by a hard reset, as the register value
will be set back to 0, but TCPC_REG_RX_HDR may contain a valid
header, leading to corrupted packets being passed down the stack.
Also update usb_pd_tcpc to match the specification.
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: I9ed8f3b500d5733ec7563e31246505e0b8bd48bb
Reviewed-on: https://chromium-review.googlesource.com/417442
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
After sending a hard reset through Control3 SEND_HARD_RESET, packet Tx
will fail until PD_RESET is triggered. Therefore, always do such a reset
when we see an M_HARDSENT interrupt. Previously, it may have been possible
to skip our reset depending on prior Tx packet status, leaving the TCPC
in a wedged state.
BUG=chrome-os-partner:58232
TEST=Manual on kevin, spam 'pd 0 hard' for 10 hours with zinger attached,
verify TCPC is still responsive and negotiating to 20V.
BRANCH=gru.
Change-Id: I42db792a5f51218c58235dc38c2d49795b54986e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/393769
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 811534541c263244d2fe9bdf9465de196e1575da)
Reviewed-on: https://chromium-review.googlesource.com/415486
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@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>
When attaching a dump (not PD protocol) TypeC charger, the incorrect
charger type was being selected and therefore it was not enabling 3A
charging. I tracked this issue down to the anx74xx_tcpm_get_cc()
function returning a incorrect value. The expected value was
TYPEC_CC_VOLT_SNK_3_0, but instead it was returning
TYPEC_CC_VOLT_SNK_DEF.
The reason the incorrect cc type was being returned is because the if,
else if, construct didn't work properly for the 3A case where the
upper 2 bits are set. Modified this routine to use a case statement
and consolidated the checks for both cc1 and cc2 into one helper
function.
BRANCH=none
BUG=chrome-os-partner:58738
TEST=manual
Connected zinger and guppy chargers and verified correct cc type was
being returned. In addition tested hoho/dingdong adapters as well as
suzyq. Tested both cable orientations to verify that cc1 and cc2
returned the correct values.
With guppy connected, now see this output on ec console:
C0 HARD RST TX
C0 st5
C0 st36
C0 st37
C0 HARD RST TX
C0 st5
[1921.980074 AC on]
[1922.008140 charge_request(8688mV, 9280mA)]
C0 st6
[1922.910539 Ramp p0 st5 3000mA 3000mA]
Change-Id: I8b31c7ce366f383dfcc2f6e850b76a83340a02a1
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/406642
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@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>
The check for hard reset complete was missing. Because of this, the
USB PD protocol state machine would get stuck in state 36
PD_STATE_HARD_RESET_SEND waiting for the pd_task to be woken following
the tx_complete. Instead it would always trip the 100 msec timeout.
BRANCH=none
BUG=chrome-os-partner:58738
TEST=manual
Without this CL, connect to a Guppy TypeC charger and observe:
> C0 st3
[101.946607 event set 0x00200000]
C0 st15
C0 st3
C0 st6
C0 st36
[102.466846 New chg p0]
[102.470376 Ramp reset: st1]
[102.470905 CL: p0 s2 i2000 v5000]
[103.543623 AC on]
After adding the fix for checking hard reset done:
> C0 st3
[32.880946 event set 0x00200000]
C0 st15
C0 st3
C0 st6
C0 st36
[33.410038 New chg p0]
C0 st37
[33.415641 Ramp reset: st1]
[33.416160 CL: p0 s2 i2000 v5000]
C0 HARD RST TX
C0 st5
C0 st36
C0 st37
C0 HARD RST TX
C0 st5
[34.489611 AC on]
[34.489965 event set 0x00000008]
[34.520457 event set 0x00400000]
[34.520876 charge_request(8688mV, 4608mA)]
C0 st6
[35.419391 Ramp p0 st2 500mA 0mA]
Change-Id: I6822983002fa387c85f7e55af5fe1e142c7b88e2
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404878
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Existing get_cc function depends on set_cc function which marks a
"pull" variable to indicate if anx74xx is setting Rp or Rd. However,
if DRP auto toggle is used, this "pull" variable is unknown, but
CC_STATUS register can differentiate between SRC and SNK, so this
"pull" variable is actually not needed.
BUG=none
BRANCH=none
TEST=verify Type-C functionality did not change on Reef.
Change-Id: I6cab8d7fcee20ec6e8414b6b2591c5d975d85293
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/396428
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We're using fusb302 rev. >= B now, so let's remove rev. A support.
BUG=chrome-os-partner:57492
BRANCH=none
TEST=Manuel
- plug USBC->DP cable into TV then into kevin
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- plug USBC->DP cable into kevin then into TV
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- unplug USBC->DP cable from TV
Port 0: OPEN INV
- plug USBC->ETHERNET into kevin and verified that network
displayed ethernet
Change-Id: Ia84dc2480c1a8b003ab8dfdcdaa9f82f6d429e4b
Reviewed-on: https://chromium-review.googlesource.com/388925
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
1.ANX3429 have CC Rx buffer, when the partner sent one message,ANX3429
received this message into Rx buffer and triggered an interrupt to
inform (TCPM), at this moment Reef sends a CC message before reading
CC Rx buffer. After Reef sends this CC message successfully, it receives
the message the partner sent. So (TCPM) sees an unexpected message was
received, that`s why sends out hard reset.
Root cause:
ANX3429 use a normal R/W register as a interrupt status register.
Between EC read interrupt status and clear interrupt status, if
ANX3429 change interrupt status, it causes interrupt status is
incorrect on EC side.
Solution:
ANX3429 FW use two normal R/W registers for interrupt status reg,
one is for FW interrupt status,other is for EC control register.
Note:
Since cc messages conflict between TCPM and the Partner,ANX3429
shall discard the TCPM message, (TCPM) sometimes send soft reset
depend on the discarded message type.
2. Sometimes TCPM (Reef) does not response GoodCRC for a received mesg.
Root Cause: Reef send message conflict with ANX3429 send auto GoodCRC.
Solution: This is fixed in the 1.5 ANX 3429 firmware.
BUG=chrome-os-partner:53936
BRANCH=none
TEST=On Reef tested with ANX3429 FW v1.5, did not see HARD RST on
ec log with Zinger.
Change-Id: I81da95433e7a0cc71e7ed121b925afccbcd84b06
Signed-off-by: Swang <swang@analogixsemi.com>
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/381014
Commit-Ready: Kevin K Wong <kevin.k.wong@intel.com>
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Added i2ctest console command to test the reliability of the I2C.
By reading/writing to the known registers this tests provides the
number of successful read and writes.
BUG=chrome-os-partner:57487
TEST=Enabled the i2ctest config on Reef and tested the
i2c read/writes.
BRANCH=none
Change-Id: I9e27ff96f2b85422933bc590d112a083990e2dfb
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/290427
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>
BUG=chrome-os-partner:54332
BRANCH=none
TEST=verify only zinger is detected in sink mode (G3/S5), and both
zinger and hoho is detected in dual role mode (S0).
Change-Id: Ifce0009908acc4b1849723ce807ca1b4c8e26020
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/387260
Reviewed-by: Shawn N <shawnn@chromium.org>
