summaryrefslogtreecommitdiff
path: root/include/usbc_ppc.h
Commit message (Collapse)AuthorAgeFilesLines
* fix ChromiumOS authors and whitespace warningsMary Ruthven2022-09-131-1/+1
| | | | | | | | | | | BUG=none TEST=none Change-Id: I61b0b0106a43f723ec3bc805eb190aef00bbd05b Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3894391 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
* ppc: cleanup ppcDenis Brockus2019-10-061-0/+5
| | | | | | | | | | | | | | Allow limited PPC chips to default to EC_ERROR_UNIMPLEMENTED for functions in the driver that are not needed. BUG=b:138599218 BRANCH=none TEST=make buildall -j Change-Id: I5242ef285eb277c06d516ab09f7a74f76d7d34b2 Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1829405 Reviewed-by: Edward Hill <ecgh@chromium.org>
* Remove __7b, __8b and __7bfDenis Brockus2019-07-201-1/+1
| | | | | | | | | | | | | | | | | | | The extentions were added to make the compiler perform most of the verification that the conversion was being done correctly to remove 8bit addressing as the standard I2C/SPI address type. Now that the compiler has verified the code, the extra extentions are being removed BUG=chromium:971296 BRANCH=none TEST=make buildall -j TEST=verify sensor functionality on arcada_ish Change-Id: I36894f8bb9daefb5b31b5e91577708f6f9af2a4f Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704792 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* Use 7bit I2C/SPI slave addresses in ECDenis Brockus2019-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Opt for 7bit slave addresses in EC code. If 8bit is expected by a driver, make it local and show this in the naming. Use __7b, __7bf and __8b as name extensions for i2c/spi addresses used in the EC codebase. __7b indicates a 7bit address by itself. __7bf indicates a 7bit address with optional flags attached. __8b indicates a 8bit address by itself. Allow space for 10bit addresses, even though this is not currently being used by any of our attached devices. These extensions are for verification purposes only and will be removed in the last pass of this ticket. I want to make sure the variable names reflect the type to help eliminate future 7/8/7-flags confusion. BUG=chromium:971296 BRANCH=none TEST=make buildall -j Change-Id: I2fc3d1b52ce76184492b2aaff3060f486ca45f45 Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1699893 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* sn5s330: Add support for SBU FET control.Aseda Aboagye2019-03-261-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | The SN5S330 has FETs for the SBU lines which need to be controlled by the TCPM. This commit adds a function to control the SBU FETs and enables them when configuring the USB mux. This commit also fixes a bug with the external VBUS current limit setting by setting it appropriately to a min of ~3A. BUG=b:114340064 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne; plug in hoho; verify that external display is shown. Bounce thru S5, verify that external display still works. TEST=Repeat above with superspeed hub instead. Change-Id: I931f7a47d4eb28e8d9e3cb188601ce0889a44f8d Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1244382 Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1530125 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* USB PD: PPC: Add overcurrent handling.Aseda Aboagye2019-01-171-13/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Type-C Power Path Controllers provide overcurrent protection. This commit adds support into the USB PD task for overcurrent events while we are in source role. The USB PD 3.0 spec recommends that ports issue a hard reset when an overcurrent condition occurs on a port. Additionally, we'll allow a source port to overcurrent 3 times before latching off VBUS from the port entirely. The source path will be re-enabled after ~1s after each overcurrent event. BUG=b:69935262,b:114680657 BRANCH=None TEST=Boot to ChromeOS in grabbiter. No overcurrent events reported when the sink is drawing <= 3.20 A. Overcurrent events are reported when the sink is drawing > 3.25 A. After 3 reports, the port is latched off and power delivery is stopped. The port is re-enabled only after the sink is disconnected. Also when the sink is drawing current at 3.24 A, there is one report of overcurrent. The port gets disabled in response to that event. But the port is re-enabled after 1 second since overcurrent event is reported only once. After the port is re-enabled, the sink is able to draw the set current. When the overcurrent event is reported, I can see in the kernel logs that the overcurrent condition is detected by the kernel. EC Logs: [3391.984462 C1: PPC detected Vbus overcurrent!] [3391.984953 C1: overcurrent!] [3392.044935 C1: PPC detected Vbus overcurrent!] [3392.045425 C1: overcurrent!] [3392.061404 C1: PPC detected Vbus overcurrent!] [3392.061894 C1: overcurrent!] [3392.062142 C1: OC event limit reached! Source path disabled until physical disconnect.] [3392.077226 C1: PPC detected Vbus overcurrent!] [3392.077532 C1: overcurrent!] [3392.077891 C1: OC event limit reached! Source path disabled until physical disconnect.] [3392.092660 C1: PPC detected Vbus overcurrent!] [3392.092966 C1: overcurrent!] [3392.093213 C1: OC event limit reached! Source path disabled until physical disconnect.] Kernel Logs: [ 3356.560456] usb usb2-port1: over-current condition [ 3356.768434] usb usb2-port2: over-current condition [ 3356.976446] usb usb2-port4: over-current condition [ 3357.184441] usb usb2-port5: over-current condition [ 3357.392445] usb usb2-port6: over-current condition Change-Id: Ib070f261e98264cd88725ebce7d10e0798267e3b Signed-off-by: Aseda Aboagye <aaboagye@google.com> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1286300 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/807633 Commit-Ready: Karthikeyan Ramasubramanian <kramasub@chromium.org> Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* SN5S330: treat interrupts as level-sensitiveDiana Z2018-11-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The SN5S330 PPC will pull its /INT pin low until all interrupts are cleared. Since the interrupt pin is treated as edge-sensitive, its handler needs to provide level-checking before exiting. Otherwise, if not all interrupts are cleared before the handler exits, the EC won't see another edge to call the handler again. Boards which share the PPC interrupt pin with other sources may choose to implement their own callback, if they are able to determine which chip was the source of the interrupt. BUG=b:118846062 BRANCH=None TEST=performed several power swaps and unplugs on a pair of Careenas, verifying that in instances where the handler had to loop around we correctly cleared the interrupts and the "ectool usbpdpower" output was normal Change-Id: Iccbe40976a746d109d67b9a91f8fbd81898f9b3f Signed-off-by: Diana Z <dzigterman@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1327123 Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* sn5s330: add low power modeJett Rink2018-08-231-0/+19
| | | | | | | | | | | | | | | | Add a low power mode method for PPCs behind a new config. Implement the low power method for SN5S330 based off of TI AE recommendation. BRANCH=none BUG=b:111520593,b:111006203 TEST=CL stack produce lower power during bip hibernate Change-Id: Icd22f88a8f65c2cd5ab1c95b0750b1eb61e91923 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1166183 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* ppc: remove EC ability to drive PPC GPIOJett Rink2018-07-201-9/+0
| | | | | | | | | | | | | | | | | | | | | | We figured out that having the EC drive the EN_SNK input of a PPC will lead to brownout or lockout conditions since the EC will float the GPIO when the EC reset. When the PPC input floats, the power path to the rest of the board is cut. If you mix this scenario with a PPC that hard-codes the over voltage protect of vbus at 6.8V in dead battery mode, you can lock the previously negotiated 20V Vbus out of the system until you physically remove the USBC connection and reinsert it. BRANCH=none BUG=b:78896495,b:78021059,b:111545725 TEST=removing unused code. everything still works. Change-Id: Ie9d51af766bc08e7d9b46b4610c0f84d3d0961f8 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1067712 Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* ppc: making driver non-constJett Rink2018-05-241-2/+2
| | | | | | | | | | | | | | | We need to update the driver based on the runtime board id, so we need to remove the const attribute. BRANCH=none BUG=b:78896495,b:78021059 TEST=build all -j Change-Id: I5f751c33cf4ec68a38aeb8644170df4987c87d7b Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1068030 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* ppc: Add driver for NX20P3483Scott Collyer2018-03-201-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | The NX20P3483 is a USB PD and Type C high voltage sink/source combo switch. This CL adds support for this PPC variant. Unlike the TI SN5S330, the NX20P3483 does not support VCONN and does not need to be informed of CC polarity by the TCPM. To account for these differences, 2 new PPC config options are added and the driver for the TI SN5S330 was modified to include these new options. The SNK/SRC switch mode for the NX20P3483 is controlled by 2 GPIO signals which may be connected the EC or directly to the TCPC. To handle both cases, the ppc_chips structure was modified with a flags, snk_gpio, and src_gpio elements. BUG=b:74206647 BRANCH=none TEST=make -j buildall and verified there are no build errors. Change-Id: Ic4415ab7571b80e7661ea673434eaf4cf1f1fd2d Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/966926 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* ppc: Add Vconn and CC polarity settings.Aseda Aboagye2018-02-011-0/+34
| | | | | | | | | | | | | | | BUG=b:72292985 BRANCH=None TEST=Flash meowth; Verify with twinkie that Vconn is provided for a sink that requires it. Change-Id: I8168d2e4c46e04810dcf5c2898b2c337424eefec Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/888224 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* sn5s330: Enable VBUS interruptsEdward Hill2018-01-311-14/+4
| | | | | | | | | | | | | | | | | | | | | | | | | If the sn5s330 PPC is being used to detect VBUS presence (CONFIG_USB_PD_VBUS_DETECT_PPC), then enable interrupts and call usb_charger_vbus_change when VBUS_GOOD changes. BUG=b:72007153,b:72007492 BRANCH=none TEST=Connect 3A and 1A USB-A chargers to each of Grunt's USB-C ports, check that BC1.2 detection is working: With 1A: > chgsup port=0/1, type=7, cur=500mA, vtg=5000mV, lsm=1 With 3A: > chgsup port=0/1, type=7, cur=2400mA, vtg=5000mV, lsm=1 TEST=Boot Grunt to OS, then connect USB2 mouse or USB3 flash drive to each of Grunt's USB-C ports. Devices do not work due to b:71772180, but gpioget shows EC is setting USB_C0/1_BC12_VBUS_ON_L correctly. Change-Id: Iffc352105a321997adb364b9fbb8bafef248c224 Signed-off-by: Edward Hill <ecgh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/887938 Reviewed-by: Jett Rink <jettrink@chromium.org>
* usb pd: Adding PPC vbus discharge pathJett Rink2018-01-311-0/+18
| | | | | | | | | | | | | | Boards with a PPC will use the PPC to discharge the VBUS line instead of the TCPC or GPIO discharge path. BRANCH=none BUG=b:72179253 TEST=Fall time after device removal on grunt within spec now Change-Id: I822923a1cedb32a20efc3610cce4437ade3387f0 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/886563 Reviewed-by: Edward Hill <ecgh@chromium.org>
* usbc: Moving PPC init after setting TCPC resistors.Jett Rink2018-01-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | We don't want the PPC to connect the CC lines from the TCPC to the USB connector until the TCPC resistors are set in a valid state (SINK initially). If we connect the CC lines (happens in the ppc_init) before setting the resistor values, some TCPC will be toggling the CC line between Rp/Rd since it doesn't detect a cable yet. In the dead battery charging case, connecting the toggling CC lines to the charger can rail the CC lines to 3.3 V signaling to the charger to disconnect Vbus, thus browning out the board. BRANCH=none BUG=b:71865251 TEST=Grunt powers on via usbc p0 with and without USB hub. Change-Id: I8e78aa2af42075398fab89a2dccef5e7df27b260 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/882305 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org>
* ppc: Add API to set Vbus source ILIM.Aseda Aboagye2017-12-131-0/+19
| | | | | | | | | | | | | | | | | | | | The PPC needs to update its Vbus source current limits whenever our policy changes on the PD ports. This commit simply adds and API to do so. BUG=None BRANCH=None TEST=With some extra code to enable 3A out, flash zoombini; Plug in a PD device to a port, verify that it gets 5V @ 3A. Plug in a second device, verify that we re-send new source caps of 5V @ 1.5A. TEST=Repeat above for meowth. Change-Id: Ifa4bc8b7df87f7730f2bcded842906d43171394b Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/818335 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* ppc: sn5s330: Add interrupt handler.Aseda Aboagye2017-12-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Right now, the only events that are unmasked by default are overcurrent conditions on PP1. This commit adds a simple interrupt handler and introduces a board specific callback when the overcurrent status changes on a port. This way, a board can take whatever action it desires with the notification. BUG=b:69139844 BRANCH=None TEST=Flash zoombini with SN5S330 stuffed. Verify that board boots okay. TEST=With some extra code to setup the interrupt handler, attempt to exceed the current limit set, verify that interrupt handler is called. Reduce the current pulled to under the current limit, verify that the condition is no longer present. CQ-DEPEND=CL:797937 Change-Id: Id3321c5703f9608da895be0ed5841f2fb76e734e Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/797936 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* sn5s330: Add support for Vbus detection.Aseda Aboagye2017-12-061-0/+28
| | | | | | | | | | | | | | | | | | | The SN5S330 has support for detecting when Vbus is present on a port. This commit simply adds an API to query the PPC. BUG=None BRANCH=None TEST=`make -j buildall`. TEST=Flash a board with the SN5S330, with some extra code, verify that Vbus can be detected with this API. Change-Id: I45bf7ff24bcdc447efe12932f51f8094108e29d5 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/791502 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* ppc: Create generic PPC driver framework.Aseda Aboagye2017-12-061-6/+64
| | | | | | | | | | | | | | | | | | | | | This commit introduces a driver framework for power path controllers. It provides some common PPC APIs as well as allowing a board to use multiple different PPCs drivers/parts. This should make it easier to add PPC drivers in the future. BUG=None BRANCH=None TEST=`make -j buildall` TEST=Flash zoombini; verify PPC works as expected. TEST=Flash meowth; verify PPC works as expected. Change-Id: Icfb99f384610590b431456cfd28d4aff18442cb2 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/807630 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* ppc: Add common APIs.Aseda Aboagye2017-12-051-0/+40
It'll be easier to add support for new PPCs if we make a generic API. BUG=None BRANCH=None TEST=make -j buildall Change-Id: I9aac1750eb4c163eb2b94aa8975c797f86d0a25a Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/791499 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
View Lorry Controller Status