summaryrefslogtreecommitdiff
path: root/common/usb_pd_tcpc.c
Commit message (Collapse)AuthorAgeFilesLines
* usb: add inline helper method for CC linesJett Rink2019-05-021-3/+3
| | | | | | | | | | | | | | | | Expressing logic for CC lines can get very verbose. Add helper inline methods that logical describe the condition we are testing to clean up call sites. BRANCH=none BUG=none TEST=Builds, no functional change. Change-Id: I48c117437bc14f3c55473df7f7c778b55af2706d Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1589906 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Sam Hurst <shurst@google.com>
* chocodile_vpdmcu: Firmware for chocodile mcuSam Hurst2019-04-081-2/+26
| | | | | | | | | | | | | | | | | | Implement Chocodile Charge-Through Vconn Powered firmware for mcu using new Type-C/PD State machine stack. BUG=b:115626873 BRANCH=none TEST=manual Charge-Through was tested on an Atlas running a DRP USB-C/PD state machine with CTUnattached.SNK and CTAttached.SNK states. Signed-off-by: Sam Hurst <shurst@chromium.org> Change-Id: I847f1bcd2fc3ce41e66edd133a10c943d5e8c819 Reviewed-on: https://chromium-review.googlesource.com/1225250 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Stefan Reinauer <reinauer@google.com>
* common/usb_pd_tcpc: Ignore repeat messagesKarthikeyan Ramasubramanian2019-03-281-0/+31
| | | | | | | | | | | | | | | | | | | | | | | Sometimes messages with the same ID are retransmitted at the physical layer. Under such scenario do not handle the repeat messages. BUG=b:129337537 BRANCH=None TEST=make -j buildall; Ensure that the DUT boots to ChromeOS. Ensure that the servo_v4 boots fine. Ensure that the DUT boots fine in normal mode and recovery mode with and without battery. Ensure that the repeat request messages triggered aritificially are dropped without any side-effects. Ensure that the DUT is detected in CCD with pass-through connected after multiple EC reboots, servo_v4 reboots and USB-C unplug/replug procedure. Change-Id: I850cd3536ff5e62c34f9dabcc0f8f53bb196ce4c Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://chromium-review.googlesource.com/1513033 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* pd: Enable USB PD SOP' and SOP'' CommunicationSam Hurst2019-01-071-5/+44
| | | | | | | | | | | | | | | | | | | | | | | | | Currently, the PD stack ignores messages received from SOP' and SOP'' and this prevents the stack from communicating with VCONN Power Devices and Cable Plugs in general. I propose encoding the message address (SOP*) in the message header. The message header is encoded as a 16-bit value but the TCPC drivers use a 32-bit type for the header. The SOP* address will be stored in bits 31 to 28 of the message header and the PD stack can check those bits to determine the address of the message. BUG=b:122109575 BRANCH=none TEST=manual Change-Id: I2b34c16cae186202c9cf0bc5f940e05151e88cbf Signed-off-by: Sam Hurst <shurst@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1390951 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cleanup: rename Rp enum values for clarityJett Rink2018-10-121-3/+3
| | | | | | | | | | | | | | | | | | | | The tcpc_cc_voltage_status enum contains different values for different detected resister values of the port partner. Both Ra and Rd values contained that in the name, but Rp values did not. Update _SNK_ tag to _RP_ tag to make it more clear what resistor is being applied by port partner. Also adding a few more comments in usb_pd_tcpm.h for clarify on the different uses of CC resistor enums. BRANCH=none BUG=none TEST=builds. just a rename change. Change-Id: Id5f7bb502f735bef5937585e2e8bd516ad428a99 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1278103 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* tcpc: Resume suspended ports after an intervalJonathan Brandmeyer2018-10-041-1/+11
| | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PD: Make current USB PD Stack REV 3 compliantSam Hurst2017-10-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the following required features in the USB PD Rev. 3.0 specification. Not_supported control message: Inform a port partner that a particular message is not supported. Battery capabilities extended message: Report battery design capacity and last full charge capacity. Battery status data message: Report battery state of charge Collision avoidance: New scheme to avoid collisions caused when both source and sink want to send messages. Cable communication: Only the VCONN source can communicate with the cable plug. This is NOT implemented because although the drivers have the capability of communicating with a cable plug, the PD stack doesn't currently need to talk to a cable plug. This is okay since the current PD design doesn't source or sink more than 3 amps and all Type-C cables are required to be 3 amp capable. BUG=b:64411727 BRANCH=None TEST=`make -j buildall` Passed relevant PD Rev 2.0 compliance tests Successful PD negotiation with PD Rev 2.0 and 3.0 chargers Tested with low power none PD charger. Modified a Kevin to operate as a PD 3.0 charger and sent all required messages and verified the return messages. Also tested collision avoidance by verifying that a sink only transmits when the source indicates it's okay. Used Twinkie to verify that PD was operating as v3.0. Signed-off-by: Sam Hurst <shurst@chromium.org> Change-Id: Ifd77e92ec4e9106236f9221393d2bfb97263d979 Reviewed-on: https://chromium-review.googlesource.com/603003 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: Don't retry sending of source capsShawn Nematbakhsh2017-10-131-1/+3
| | | | | | | | | | | | | | | | | TCPM will retry sending of source caps on failure and retrying in TCPC will cause us to violate PD_T_SEND_SOURCE_CAP. BUG=None TEST=Attach servo_v4 to twinkie, verify source caps are sent in ~100ms intervals and not in bursts of four. BRANCH=servo_v4 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I3264e5578afbde7b9d2c003b6744974329a253d4 Reviewed-on: https://chromium-review.googlesource.com/719729 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Fix inconsistent task function declarationsStefan Reinauer2017-08-081-1/+1
| | | | | | | | | | | | | | | Tasks are defined inconsistently across the code base. Signed-off-by: Stefan Reinauer <reinauer@google.com> BRANCH=none TEST=make buildall -j, also verify kevin boots to OS BUG=none Change-Id: I19a076395a9a8ee1e457e67a89d80d2f70277c97 Reviewed-on: https://chromium-review.googlesource.com/602739 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* servo_v4: pd: Updated CC_NC and CC_RA macrosScott2017-03-261-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previous boards that implemented tcpc layer on chip didn't support variable Rp values. However, servo_v4 can present any of the 3 possible Rp values and therefore the voltage thresholds that are used to determine a no-connect or Ra attach status need a way to be set based on the Rp value that's current attached to a given CC line. - Added port and cc line selection to both the CC_NC and CC_RA macros and now check if they are already defined before being defined in usb_pd_tcpc.c. - Defined each of these macros in board.h to use a function that's able to select the threshold based on the current Rp configuration. BUG=b:35586526 BRANCH=servo TEST=Tested with servo_v4 against Electro and verified that it connects when a charger is and is not connected to CHG port which exercises the differnt Rp combinations that servo_v4 presents. Change-Id: I1a31e430c0f290486f0fa8a50bdafdddf20d23ca Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/451962 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Add tcpc_select_rp_value to stub tcpm driverScott2017-03-021-0/+10
| | | | | | | | | | | | | | | | | | | | | | 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>
* servo_v4: pd: Added Device Test System supportScott2017-01-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* tcpci_tcpm_get_message: TCPC_REG_RX_BYTE_CNT includes headerNicolas Boichat2016-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix various misspellings in commentsMartin Roth2016-11-151-1/+1
| | | | | | | | | | | | | No functional changes. BUG=none BRANCH=none TEST=make buildall passes Change-Id: Ie852feb8e3951975d99dce5a49c17f5f0e8bc791 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/403417 Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
* cleanup: DECLARE_CONSOLE_COMMAND only needs 4 argsBill Richardson2016-08-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: pd: Define VBUS detection sourceShawn Nematbakhsh2016-06-021-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pd: Fix port enable check for low power idleShawn Nematbakhsh2016-04-251-1/+1
| | | | | | | | | | | | | | BUG=chrome-os-partner:52734 BRANCH=glados TEST=Plug 2 PD chargers on sentry, remove the first, verify that SLEEP_MASK_USB_PD is not briefly cleared. Change-Id: I62309194d8b5a694487282434fc63b5f39301ba3 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/340564 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpm: update code to support multiple tcpm driverKevin K Wong2016-04-171-0/+1
| | | | | | | | | | | 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: add 2 bytes into TX byte count registerAlec Berg2015-12-051-3/+0
| | | | | | | | | | | | | | | Add 2 bytes into the TX byte count register used in TCPC interface. BUG=chrome-os-partner:48256 BRANCH=none TEST=load on glados and attach zinger, make sure PD negotiation successful. Change-Id: Ie57d79f20def861c22f6e2e023545a65825ab3b4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/315879 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cleanup: Fix gcc 5.2.1 compile errorsShawn Nematbakhsh2015-11-111-0/+1
| | | | | | | | | | | | | | | BUG=chromium:552006 BRANCH=None TEST=`make buildall -j` and also verify panic reporting works on glados_pd. Change-Id: Ic9f1ec6b5297389df0d46bb38a67c156901ed956 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/311253 Commit-Ready: Shawn N <shawnn@gmail.com> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: add more power improvements to PD taskAlec Berg2015-10-301-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tcpc: re-initialize tcpc if it reboots while tcpm is runningAlec Berg2015-10-221-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Cleanup usb_pd low power idle sleep maskShawn Nematbakhsh2015-10-061-0/+15
| | | | | | | | | | | | | | | | | | | | | | | Add a new define CONFIG_USB_PD_LOW_POWER_IDLE_WHEN_CONNECTED that indicates the chip should try to go to low power idle even when a PD connection is established -- this is the current behavior only for Zinger. Also, enable and disable the sleep mask bit from tcpc on rx enable / disable. BUG=chrome-os-partner:45010 TEST=Manual on glados / glados_pd. Insert Zinger, verify that glados_pd stays out of low power idle. Remove Zinger, verify that glados_pd resumes going into low power idle. BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ie763ae75f4459f56cad47d77d9c25d76358aa484 Reviewed-on: https://chromium-review.googlesource.com/303490 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* tcpc: don't allow tcpc write command until initializedAlec Berg2015-09-211-0/+5
| | | | | | | | | | | | | | | | | | | | | Don't act on a TCPC write command until we are done initializing. This fixes an issue where if the TCPC reboots while the TCPM (EC in our case) is still functioning, then we can get into a weird state where we are changing the CC termination as we are still initializing, which can cause us to get stuck with a phantom connection (we apply one CC termination, but think we are applying the opposite termination, causing us to 'see' a connected device). BUG=none BRANCH=none TEST=load on glados. make sure dual-role toggling is on on the EC and reboot PD MCU a bunch of times and make sure the EC doesn't detect a phantom connection. Change-Id: I2dffc3c2a1ca70903e17db0e012e994835cb9962 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/300681 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: update to tcpci RC3Alec Berg2015-09-161-16/+23
| | | | | | | | | | | | | | Update TCPCI to match specification version RC3. BUG=none BRANCH=none TEST=tested on glados and samus by plugging in a zinger with both polarities and verifying we make a power contract. Change-Id: I9cd6d8db7b7149995847ec1b071fba1f4d4cd5a3 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/299713 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* oak_pd: tcpm_power_status: Update power status on initRong Chang2015-09-141-19/+28
| | | | | | | | | | | | | | | | | Oak board relies on TCPCI power status. When board init, PD should update it's VBUS status and TCPM needs to get power status after enable TCPC power status mask. BRANCH=none BUG=chrome-os-partner:44952 TEST=manual build and load on oak, disconnect battery. power on system with zinger, and check PD state. Signed-off-by: Rong Chang <rongchang@chromium.org> Change-Id: Ic0d4b50d38ac39ff31b3a257c4b3b5dde0ebda4b Reviewed-on: https://chromium-review.googlesource.com/297871 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* pd: Enable detection of VBUS via the TCPM/TCPCI interfaceScott2015-08-211-0/+51
| | | | | | | | | | | | | | | | | | | | | 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: fix rx buffer overrun bugAlec Berg2015-08-041-2/+6
| | | | | | | | | | | | | | | Fix buffer overrun bug when retrieving a PD message. Bug was introduced in CL:289005 BUG=chrome-os-partner:43482 BRANCH=none TEST=tested on samus. plug and unplug zinger on both ports and make sure PD MCU never crashes. Change-Id: I9d2dec0cab07f389fd935d616ab7443da412d4bd Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/290417 Reviewed-by: Shawn N <shawnn@chromium.org>
* tcpc: add RX message buffer and don't send goodCRC when fullAlec Berg2015-08-011-18/+73
| | | | | | | | | | | | | | | | | | 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: move tcpc initialized bit into error status registerAlec Berg2015-07-241-1/+9
| | | | | | | | | | | | | | | | | | | | Move TCPC initialized bit from alert register into error status register. This is not part of the TCPCI spec, but the existing code creates a bug that if TCPM reboots without TCPC also rebooting, then we will never get the initialized alert from TCPC since it has already happened, so the TCPM will loop indefinitely waiting for TCPC to be ready. This fixes the bug by moving the bit to a status register, which is more appropriate. BUG=none BRANCH=none TEST=load on glados, reboot and make sure TCPM see's that the TCPC is initialized. Change-Id: I8e96b59031e01a4faec8f519727df1fa95f498bc Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/288342 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: use initialization complete alert bit to signal readinessAlec Berg2015-06-301-7/+12
| | | | | | | | | | | | | | | Use the new TCPC initialization complete bit in alert register to signal TCPC readiness instead of checking for USB VID to be set. BUG=none BRANCH=none TEST=load on glados, make sure we can boot without battery. Change-Id: I4b25c973ece0de6dd3f419c5901cff1d8d05ed95 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/282593 Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: update tcpci registers to latest specAlec Berg2015-06-301-10/+5
| | | | | | | | | | | | | | | 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-7/+8
| | | | | | | | | | | | | | | 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: Add support for TCPC Alert and Alert_Mask registersScott2015-06-231-31/+63
| | | | | | | | | | | | | | | | | | | Changed the alert function to hold the ec_int line until all of the alert bits are cleared. Added support for the alert_mask register. In addition, created ec_int_status variable to distinguish which of 3 ec_int sources is driving the pd_mcu_int line. BUG=none BRANCH=tot TEST=Tested Zinger to Glados and Zinger to Samus and verified that it established a power contract in both cases. Did not test Oak, but put exact same changes in board.c as in glados. Change-Id: I372e75b8fd5d66a0c01db18b46100b86fd9ac064 Signed-off-by: Scott Collyer <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/278256 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* tcpc: use vendor ID register to signal TCPC readinessAlec Berg2015-06-171-0/+9
| | | | | | | | | | | | | | | | | | | Add TCPC support for USB VID register and use that register from the TCPM side to know when the TCPC is ready. TCPC is ready when phy layer is initialized and CC ADC channels have been read. BUG=chrome-os-partner:40920, chrome-os-partner:41258 BRANCH=none TEST=load and run glados. verify that glados EC doesn't start sending TCPC commands until it can successfully read TCPC VID. verify that we can boot with zinger and no battery. Change-Id: Iafbab529a16ff904cdb817901baac5e72e3d7220 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/277710 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: initialize CC termination based on default PD roleAlec Berg2015-06-161-0/+2
| | | | | | | | | | | | | | | | | | | Initialize CC termination variable based on the default PD role. BUG=chrome-os-partner:40920 BRANCH=none TEST=load on glados. test by rebooting PD from PD console with nothing plugged into the type-C ports. Without this change, the EC gets stuck in SNK_DISCONNECTED_DEBOUNCE, because the PD defaults to using the wrong termination and so the PD thinks the CC ADC readings represent Ra. At this point you have to reboot EC to get back to normal functionality. With this change, rebooting PD does not wedge the PD protocol state machine. Change-Id: I4eb6d881d8fc995be4d6a99ffa69e484141343f2 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/277666 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* tcpc: Avoid missampling CC line immediately after transmitAlec Berg2015-06-131-16/+19
| | | | | | | | | | | | | | | | | | Change TCPC to not sample CC ADC channels immediately after transmit because we are likely to get a response immediately after transmit and this could cause us to sample while traffic is on the line and cause us to record the wrong voltage. BUG=none BRANCH=smaug TEST=test on glados. put a print when TCPM is notified of CC voltage change. without this CL, we occasionally get a false CC voltage change. with this change, CC status stays consistent. Change-Id: I9199a0ed98632b1f26b2b5b98f34928e4de328bf Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/277296 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: implement TCPC RX Detect register to enable/disable TCPC RXAlec Berg2015-06-031-30/+27
| | | | | | | | | | | | | | | | | | | | | | | Implement the TCPC RX Detect register and use it for the TCPM to enable and disable PD communication. When no type-C connection, disable TCPC RX so that we don't send goodCRC when we are not ready. Once TCPM establishes a type-C connection, enable TCPC RX. BUG=none BRANCH=none TEST=tested on glados and on samus. On glados, without this change, sometimes when you plug in zinger, we get into a hard reset loop because TCPC is sending goodCRC to source cap while TCPM is still debouncing CC and is not ready. With this change, we reliably form PD contract. Also tested enabling and disabling PD comms from the TCPM console with "pd enable 0|1". Change-Id: I8c9e696f2597978436f6ceccfe06ffb021c95ea3 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/274811 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: move non-phy layer config out of usb_pd_config.hAlec Berg2015-05-271-7/+15
| | | | | | | | | | | | | | | | | | | | | Move parts of usb_pd_config.h that are not part of the phy layer out of usb_pd_config.h and into board.h. This cleans up the division between the TCPC and TCPM as only the TCPC needs to use usb_pd_config.h. Also cleans up the use of the CC detection voltage thresholds by creating standard macros to use based on Rp strength for the board. BUG=none BRANCH=none TEST=make -j buildall Change-Id: I946cceb38bea8233095b8a4b287102bb8a3a296d Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270337 Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: add first version of TCPCI I2C interfaceAlec Berg2015-05-221-35/+183
| | | | | | | | | | | | | | | | Add first version of TCPCI (type-C port controller interface), which is an I2C protocol for interfacing with TCPCs. This is roughly tracking version 0.56 of the PD Interface spec. BUG=none BRANCH=none TEST=tested on oak. modified oak EC to be TCPM and oak PD to be TCPC and tested we can negotiate with hoho and zinger. Change-Id: I83644ca83f2d3ce69d5d8356beca20a7ab155a87 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270172
* pd: add config options for including TCPM and TCPC separatelyAlec Berg2015-05-221-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Add config options for various parts of USB PD stack: CONFIG_USB_POWER_DELIVERY: The use of this option has changed slightly. It now represents whether or not to include the USB PD protocol and policy layers of the software stack. CONFIG_USB_PD_TCPC: Compile in type-C port controller module which performs the phy layer of the PD stack. CONFIG_USB_PD_TCPM_STUB and CONFIG_USB_PD_TCPM_TCPCI: If CONFIG_USB_POWER_DELIVERY is defined, then one TCPM needs to be defined to declare which port management module to use to drive the TCPC. BUG=none BRANCH=none TEST=make -j buildall Change-Id: I41aa65a478e36925745cd37a6707f242c0dfbf91 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270171 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: initial split of protocol code to create port controllerAlec Berg2015-05-221-0/+963
Initial split of the USB PD protocol code to create the new port controller (TCPC) and port management (TCPM) blocks. The intention is that the TCPC code will eventually reside on a different MCU, along with the USB PD phy layer. The TCPM will stay with the protocol and policy layers and provide a standard interface to TCPC (over i2c). As a first step, this CL merely splits up the files and directly calls functions to reach across between TCPM and TCPC. BUG=none BRANCH=none TEST=tested on samus using zinger, hoho, another samus, donette, and a third party PD charger. Tested the following: - dual-role toggling - forming a connection as a source and as a sink - power negotiation at different voltages - charging - sourcing power to USB stick - soft reset - hard reset - power swap - data swap - bist mode 2 - zinger remote firmware updates Change-Id: I70bd68a003c81e075310913f10351b792f76d7e0 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266923 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
View Lorry Controller Status