summaryrefslogtreecommitdiff
path: root/driver/tcpm/stub.c
Commit message (Collapse)AuthorAgeFilesLines
* Update license boilerplate text in source code filesMike Frysinger2022-09-121-1/+1
| | | | | | | | | | | | | | | Normally we don't do this, but enough changes have accumulated that we're doing a tree-wide one-off update of the name & style. BRANCH=none BUG=chromium:1098010 TEST=`repo upload` works Change-Id: Icd3a1723c20595356af83d190b2c6a9078b3013b Signed-off-by: Mike Frysinger <vapier@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3891203 Reviewed-by: Jeremy Bettis <jbettis@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* driver/tcpm/stub.c: Format with clang-formatJack Rosenthal2022-07-011-5/+5
| | | | | | | | | | | BUG=b:236386294 BRANCH=none TEST=none Change-Id: Ia905c799e66a238ced3ad1304a8e65b981a0aa73 Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3730100 Reviewed-by: Jeremy Bettis <jbettis@chromium.org>
* TCPM: Rename enum tcpm_sop_type and its constantsAbe Levkoy2021-08-311-1/+1
| | | | | | | | | | | | | | | As a followup to CL:3104290, give the TCPCI TRANSMIT and RX_BUF_FRAME_TYPE types more consistent names. Most of them can be used for receiving, not just transmitting. Fix lint errors thus revealed. BUG=b:155476419 TEST=make buildall BRANCH=none Signed-off-by: Abe Levkoy <alevkoy@chromium.org> Change-Id: I399ec479eacc18622fc4d3f55f8bdabf4560fcff Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3125995 Reviewed-by: Keith Short <keithshort@chromium.org>
* TCPM: Rename enum tcpm_transmit_typeAbe Levkoy2021-08-181-1/+1
| | | | | | | | | | | | | | | Rename tcpm_transmit_type to tcpm_sop_type to reflect that it can be used for Rx as well. Describe it in comments. This prepares to consolidate enum pd_msg_type into this enum. BUG=b:155476419 TEST=make buildall BRANCH=none Signed-off-by: Abe Levkoy <alevkoy@chromium.org> Change-Id: Ife97d4ad51c48f2e832b94e007954919e236a309 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3104290 Reviewed-by: Keith Short <keithshort@chromium.org>
* Move tcpic.h header into include/driverSimon Glass2021-01-071-1/+1
| | | | | | | | | | | | | | | | | | This header cannot currently be accessed by Zephyr since it is in a driver directory, not an include directory. This header has quite a bit of public stuff in it, so it seems reasonable to consider everything public. Move the header file and update all users. BUG=b:175434113 BRANCH=none TEST=make buildall -j30 build volteer on zephyr Signed-off-by: Simon Glass <sjg@chromium.org> Change-Id: Ibba37f47a06783fafb5095f853f2a68d92b6df87 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2607745
* USB: Remove DTS identification from USB PD polarityBrian J. Nemec2020-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We've added differentiation for DTS polarity and normal device polarity. These values were being passed to the pd[port].polarity fields. This creates problems for the usb_pd_config.h files which operate on the assumption that polarity is a boolean value of 0 or 1. In the case of ternary blocks that follow the format of: 'polarity ? A | B', if polarity is 'POLARITY_CC1_DTS = 2' we are incorrectly identifying it as flipped. Other usages like Servo_v4 which have lookup arrays like: tx_gpio[port][polarity]. In these cases, the DTS polarities point to garbage memory and generate hard-faults. BRANCH=none BUG=b:176154334 TEST=Connect to servo console and run 'cc snkdts' Validate that the servo did not hard-fault, instead loads a valid configuration. Signed-off-by: Brian Nemec <bnemec@chromium.org> Change-Id: If5ed079fee9e91dbf291e1f210762c298948ad1e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2600657 Reviewed-by: Denis Brockus <dbrockus@chromium.org>
* tcpm: Move tcpm.h into an include directorySimon Glass2020-12-221-1/+1
| | | | | | | | | | | | | | | | | | This header file is used from quite a few files, relying on the EC build system to find includes in the driver/tcpm directory. For Zephyr we don't want to add that as an include. It makes more sense for header files to be in an include directory, so move it and fix up the users. BUG=b:175434113 BRANCH=none TEST=build Zephyr and ECOS on volteer Signed-off-by: Simon Glass <sjg@chromium.org> Change-Id: I5851914b1a7d3fdc1ba911c0fbe9046afbaf6f5d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2597985 Reviewed-by: Keith Short <keithshort@chromium.org>
* task_set_event: remove the wait argumentDawid Niedzwiecki2020-12-141-2/+2
| | | | | | | | | | | | | | | | | | | | There is an option in the task_set_event function which force the calling task to wait for an event. However, the option is never used thus remove it. This also will help in the Zephyr migration process. BUG=b:172360521 BRANCH=none TEST=make buildall Signed-off-by: Dawid Niedzwiecki <dn@semihalf.com> Change-Id: Ic152fd3d6862d487bcc0024c48d136556c0b81bc Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2521599 Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Tom Hughes <tomhughes@chromium.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Commit-Queue: Jack Rosenthal <jrosenth@chromium.org>
* driver/tcpm: set PD_EVENT_RX_HARD_RESET event when receive hard resetRuibin Chang2020-07-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | When we receive hard reset, we should do Vbus on-off cycle and should keep cc connection. So I change the event setting from PD_EVENT_TCPC_RESET to PD_EVENT_RX_HARD_RESET for ITE TCPC. Stand alone TCPCs also use hard reset event instead of calling pd_execute_hard_reset(), because waked up pd_task() may have chance setting to other state. BRANCH=None BUG=b:159394180 TEST=On board reef_it8320, and it81202_pdevb: 1.TCPMv1: Rx Hard reset -> done Vbus cycle, and keep cc connection, When we're SRC and SNK. 2.TCPMv2: Rx Hard reset -> done Vbus cycle, and keep cc connection, When we're SRC and SNK. Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw> Change-Id: Ie94757580e8fed4fb33896f9c1e071def49ff03d Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2284504 Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Eric Yilun Lin <yllin@chromium.org>
* tcpci: Only drive one CC line when attachedDenis Brockus2020-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the NCT38XX driver code was more generic TCPCI than specific to the chip. So moved a number of the functions over to be generically handled. In doing this I propagated the idea of tri-state polarity. It is now either NORMAL, FLIPPED, or NONE for unattached. This is needed for the generic handling of correctly setting CC. This required changing the polarity from NONE to the appropriate detected polarity when in auto toggle. tcpci_tcpm_set_cc will now only set a single CC line when attached and both when unattached. BUG=b:146003980, chromium:951681 BRANCH=none TEST=Charging works with both plug orientations with AP on TEST=Device works with both plug orientations with AP on TEST=Charging works with both plug orientations with AP off Change-Id: Ie4b5cc998902a346a4f4a2c1480204b3a81017dd Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1967932 Commit-Queue: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* tcpci: change connect to auto discharge disconnectDenis Brockus2019-12-121-0/+4
| | | | | | | | | | | | | | | | | | | It was originally thought the connect/disconnect would be a good generic way to set/clear auto_discharge_disconnect but it was not working reliably. Although the points that we are calling to perform this enable/disable are close to the connect/disconnect, there is more fine tuning required to make this work. BUG=b:144126745,chromium:951683 BRANCH=none TEST=attach/disconnect charger with and without AP running TEST=attach/disconnect device with AP running Change-Id: Ib1418771aec6d0a52895972e4db6881b072c0c3d Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1960514 Reviewed-by: Edward Hill <ecgh@chromium.org>
* usb: convert cc1 from int to enumJett Rink2019-08-091-1/+2
| | | | | | | | | | | | | | Refactor code to use proper type for cc1 and cc2 lines. BRANCH=none BUG=none TEST=builds. No functional change. Change-Id: Id292db8480920e2b191bac9d9ecc2685f61e4ea9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1744654 Tested-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Denis Brockus <dbrockus@chromium.org> Commit-Queue: Jett Rink <jettrink@chromium.org>
* tcpc: Resume suspended ports after an intervalJonathan Brandmeyer2018-10-041-0/+5
| | | | | | | | | | | | | | | | | | | | | When it appears that the TCPC queue handling logic may be stuck in an infinite loop, the EC will break the loop by disabling the port in order to avoid task starvation. However, nothing attempts to resume the port, and it therefore remains disabled until the next EC reset. Wake back up after a reasonable interval in order to automatically retry. On port suspend, completely drain the TCPM message queue. BUG=chromium:891713 TEST=On Careena hardware, with analogix TCPC firmware v1.5 and an electronically marked cable that sends SOP' messages, verify that the EC auto-retries every second. After removing the offending cable, and PD power supply will work. BRANCH=grunt Change-Id: I563b763501333eb36ee1f76e6f484ebb3245c82a Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1258571 Reviewed-by: Jett Rink <jettrink@chromium.org>
* tcpm: add TCPC RX circular buffer in ECJett Rink2018-09-071-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The alert line for TCPC will stay asserted as long as there are RX messages for the TCPM (i.e. EC) to pull from the TCPC. We should clear all of the RX messages we know about during a single alert handling session. This CL can stand on its own, but it is a part of a CL stack that will tighten the critical section of time between received messages from the TCPC and sending follow up message out through the TCPC. See go/usb-pd-slow-response-time for more details. BRANCH=none BUG=b:112088135,b:112344286,b:111909282,b:112848644,b:113124761 BUG=b:113057273,b:112825261 TEST=Reduces reset issue in most cases for phaser, bobba. Does not seem to adversely affect state machine negotiation. Full CL stack consistently sends a REQUEST at 18ms after a SRC_CAP GoodCRC, which is well below the 24 ms threshold we need to be under for USB PD spec compliance. Also testing pd_suspend scenario manually and EC was responsive after port 1 suspend because of "bad behavior" Change-Id: I1654b46400e9881f2927a5f6d6ace589edd182de Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1185727
* cleanup: remove tcpc* extern function declarationsJett Rink2018-08-311-16/+1
| | | | | | | | | | | | | | We do not want to use extern when possible, so move the function declaration section in the tcpm stub c files to an appropriate header file. BRANCH=none BUG=none TEST=zinger compiler (along with everything else) Change-Id: If867661840d138e0c912669e401469a152fa3d9b Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1194083 Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
* pd: Add tcpc_select_rp_value to stub tcpm driverScott2017-03-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* pd: select dynamically Rp valueVincent Palatin2016-08-251-0/+5
| | | | | | | | | | | | | | | | | | | | | 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>
* tcpm: update code to support multiple tcpm driverKevin K Wong2016-04-171-13/+4
| | | | | | | | | | | BUG=chromium:593822 BRANCH=none TEST=make buildall Change-Id: Ic30c1b890da7639aa80a53040ecc5bebfb4be2e8 Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com> Reviewed-on: https://chromium-review.googlesource.com/336030 Reviewed-by: Shawn N <shawnn@chromium.org>
* tcpc: re-initialize tcpc if it reboots while tcpm is runningAlec Berg2015-10-221-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pd: Enable detection of VBUS via the TCPM/TCPCI interfaceScott2015-08-211-0/+6
| | | | | | | | | | | | | | | | | | | | | Modified TCPC layer to utilize the Power_Status and Power_Status_Mask registers. VBUS status is stored in Power_Status and when a change is detected, it's communicated to the TCPM via the ALERT# line. BUG=chrome-os-partner:43440 BRANCH=none TEST=Tested the feature on Glados and Oak connecting to both Ziger and Samus. Verfied that VBUS status is communicated via the TCPCI and that PD contracts are established without using the VBUS_WAKE GPIO lines on Glados and Oak. Change-Id: Ie5aa32eecc887f3cb00880a285f1e710b7064384 Signed-off-by: Scott Collyer <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/289931 Reviewed-by: Rong Chang <rongchang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Rong Chang <rongchang@chromium.org> Tested-by: Rong Chang <rongchang@chromium.org>
* tcpc: add RX message buffer and don't send goodCRC when fullAlec Berg2015-08-011-7/+15
| | | | | | | | | | | | | | | | | | Add RX message buffer to the TCPC (currently two deep). If the buffer is full and message is received, don't send goodCRC. BUG=chrome-os-partner:43482 BRANCH=none TEST=tested on glados. saw that with back to back PD packets, we send goodCRC to both packets and process them in order, taking about 7ms per packet. also tested buffer size of 1 and verified that with back to back PD packets, we don't send goodCRC to second packet. Change-Id: I7f44b3c3a186ae61be8ca03017deec6e6b6c6f9f Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/289005 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: update tcpci registers to latest specAlec Berg2015-06-301-1/+3
| | | | | | | | | | | | | | | Update TCPCI registers to version 0.62 of PD Interface specification. BUG=none BRANCH=none TEST=test on glados and samus Change-Id: I57338b385123371e90f3b79b84e652af15be1bf1 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/282067 Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: refactor tcpm and move alert function to tcpm driverAlec Berg2015-06-301-8/+56
| | | | | | | | | | | | | | | Refactor the tcpm/tcpc split such that the tcpm driver implements the alert functionality since it may be unique for different tcpc chips. BUG=chrome-os-partner:41842 BRANCH=none TEST=make -j buildall. run on samus and glados. Change-Id: I23f2d7f8627d5337b8d001a09bf27622be24fe33 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/281631 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: create driver/tcpm/ to hold TCPM driversAlec Berg2015-06-241-0/+88
Create driver/tcpm/ folder to hold TCPM drivers. Currently the two drivers are a stub driver which is used when TCPM and TCPC are on the same MCU and can make direct calls between the two and the TCPCI driver which implements the standard TCPCI protocol. BUG=chrome-os-partner:41842 BRANCH=none TEST=make -j buildall Change-Id: Ie4d9b36eb33155254f8b87b83861f98a7a80693a Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/281630 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
View Lorry Controller Status