ish: Trim down the release branchstabilize-wristpin-14469.59.B-ishstabilize-voshyr-14637.B-ishstabilize-quickfix-14695.187.B-ishstabilize-quickfix-14695.124.B-ishstabilize-quickfix-14526.91.B-ishstabilize-14695.85.B-ishstabilize-14695.107.B-ishstabilize-14682.B-ishstabilize-14633.B-ishstabilize-14616.B-ishstabilize-14589.B-ishstabilize-14588.98.B-ishstabilize-14588.14.B-ishstabilize-14588.123.B-ishstabilize-14536.B-ishstabilize-14532.B-ishstabilize-14528.B-ishstabilize-14526.89.B-ishstabilize-14526.84.B-ishstabilize-14526.73.B-ishstabilize-14526.67.B-ishstabilize-14526.57.B-ishstabilize-14498.B-ishstabilize-14496.B-ishstabilize-14477.B-ishstabilize-14469.9.B-ishstabilize-14469.8.B-ishstabilize-14469.58.B-ishstabilize-14469.41.B-ishstabilize-14442.B-ishstabilize-14438.B-ishstabilize-14411.B-ishstabilize-14396.B-ishstabilize-14395.B-ishstabilize-14388.62.B-ishstabilize-14388.61.B-ishstabilize-14388.52.B-ishstabilize-14385.B-ishstabilize-14345.B-ishstabilize-14336.B-ishstabilize-14333.B-ishrelease-R99-14469.B-ishrelease-R98-14388.B-ishrelease-R102-14695.B-ishrelease-R101-14588.B-ishrelease-R100-14526.B-ishfirmware-cherry-14454.B-ishfirmware-brya-14505.B-ishfirmware-brya-14505.71.B-ishfactory-kukui-14374.B-ishfactory-guybrush-14600.B-ishfactory-cherry-14455.B-ishfactory-brya-14517.B-ish

In the interest of making long-term branch maintenance incur as little
technical debt on us as possible, we should not maintain any files on
the branch we are not actually using.

This has the added effect of making it extremely clear when merging CLs
from the main branch when changes have the possibility to affect us.

The follow-on CL adds a convenience script to actually pull updates from
the main branch and generate a CL for the update.

BUG=b:204206272
BRANCH=ish
TEST=make BOARD=arcada_ish && make BOARD=drallion_ish

Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Change-Id: I17e4694c38219b5a0823e0a3e55a28d1348f4b18
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3262038
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Tom Hughes <tomhughes@chromium.org>

1 files changed, 0 insertions, 219 deletions

diff --git a/docs/usb-c.md b/docs/usb-c.md
deleted file mode 100644
index 1e009f82b2..0000000000
--- a/docs/usb-c.md
+++ /dev/null
@@ -1,219 +0,0 @@
-# EC Implementation of USB-C Power Delivery and Alternate Modes
-
-USB-C PD requires a complex state machine as USB-C PD can operate in many
-different modes. This includes but isn't limited to:
-
-*   Negotiated power contracts. Either side of the cable can source or sink
-    power up to 100W (if supported by device).
-*   Reversed cable mode. This requires a mux to switch the signals before
-    getting to the SoC (or AP).
-*   Debug accessory mode, e.g. [Case Closed Debugging (CCD)]
-*   Multiple uses for the 4 differential pair signals including
-    *   USB SuperSpeed mode (up to 4 lanes for USB data)
-    *   DisplayPort Alternate Mode (up to 4 lanes for DisplayPort data)
-    *   Dock Mode (2 lanes for USB data, and 2 lanes for DisplayPort)
-    *   Audio Accessory mode. (1 lane is used for L and R analog audio signal)
-
-For a more complete list of USB-C Power Delivery features, see the
-[USB-C PD spec][USB PD Spec Id].
-
-This document covers various touch points to consider for USB-C PD and Alternate
-Modes in the EC codebase.
-
-[TOC]
-
-## Glossary
-
-*   PD {#pd}
-    *   Power Delivery. Protocol over USB-C connector that allows up to 100W of
-        power. Not supported on USB-A or USB-B connectors. A good overview of
-        USB PD is found in the [Introduction to USB Power Delivery] application
-        note.
-*   TCPC {#tcpc}
-    *   Type-C Port Controller. Typically a separate IC connected through I2C,
-        sometimes embedded within the EC as a hardware sub module. The TCPC
-        interprets physical layer signals on CC lines and Vbus, and sends that
-        information to the TCPM to decide what action to take. In older designs,
-        there was a separate EC (running this codebase) that acted as the TCPC
-        that communicated with the main EC (also running this codebase), which
-        acted as the TCPM. More info in the official
-        [TCPC spec][USB TCPM Spec Id].
-*   TCPM {#tcpm}
-    *   Type-C Port Manager. Manages the state of the USB-C connection. Makes
-        decisions about what state to transition to. This is the code running on
-        the EC itself.
-*   PE {#pe}
-    *   Policy Engine. According to the [TypeC spec][USB TC Spec Id], the policy
-        engine is the state machine that decides how the USB-C connection
-        progresses through different states and which USB-C PD features are
-        available, such as Try.SRC
-*   TC {#tc}
-    *   Type-C physical layer.
-*   PPC {#ppc}
-    *   Power Path Controller. An optional, separate IC that isolates various
-        USB-C signals from each other and the rest of the board. This IC should
-        prevent shorts and over current/voltage scenarios for Vbus. Some PPCs
-        will protect signals other than Vbus as well.
-*   SSMUX {#ssmux}
-    *   SuperSpeed Mux. This is typically the same IC as the TCPC; it enables
-        the mirrored orientation of the USB-C cable to go to the correct pins on
-        SoC. Also, allows the SuperSpeed signal to be used for different
-        purposes, such as USB data or DisplayPort.
-*   SVDM {#svdm}
-    *   Structured Vendor Defined Messages are a class of [USB PD](#pd) messages
-        to enable non-power related communication between port partners. SVDMs
-        are used to negotiate and set the display port mode on a USB-C
-        connection.
-*   DRP {#drp}
-    *   Dual Role Power Port. A USB-C port that can act as either a power Source
-        or power Sink.
-*   UFP {#ufp}
-    *   Upstream Facing Port. The USB data role that is typical for a peripheral
-        (e.g. HID keyboard).
-*   DFP {#dfp}
-
-    *   Downstream Facing Port. The USB Data role that is typical for a host
-        machine (e.g. device running ChromeOS).
-
-*   E-Mark {#emark}
-
-    *   Electronically marked cable. A USB-C cable that contains an embedded
-        chip in the cable, used to identify the capabilities of the cable.
-
-*   VCONN {#vconn}
-
-    *   Connector Voltage. A dedicated power supply rail for [E-Mark](#emark)
-        cables and other accessory functions (such as display dongles, and
-        docks). VCONN re-uses one of the CC1/CC2 signals to provide 5 volt, 1
-        watt, of power.
-
-## Different PD stacks
-
-Right now platform/ec has two different implementations of USB-C PD stack.
-
-1.  The older implementation is mainly contained within
-    [`usb_pd_protocol.c`](../common/usb_pd_protocol.c) and
-    [`usb_pd_policy.c`](../common/usb_pd_policy.c)
-2.  The newer implementation is found under [`common/usbc`](../common/usbc) and
-    is broken up into multiple different files and state machines
-    *   Policy engine state machine files, `usb_pe_*_sm.c`.
-    *   Protocol engine state machine file, `usb_prl_*_sm.c`.
-    *   State machine framework file, `usb_sm.c`.
-    *   Type-C physical layer state machine files, `usb_tc_*_sm.c`.
-    *   USB-C PD Task file, `usbc_task.c`.
-
-The older implementation supports firmware for device types other than
-Chromebooks. For example, the older stack supports the Zinger, which is the
-USB-C charging device that shipped with Samus, the Google Chromebook Pixel 2.
-The Zinger implements the charger only side of the USB PD protocol.
-
-To use the newer USB-C PD stack implementation, see
-[TCPMv2 Overview](usb-tcpmv2.md).
-
-## Implementation Considerations
-
-In both older and newer implementations, the following details apply:
-
-*   For each USB-C port, there must be two tasks: `PD_C#` and `PD_INT_C#`, where
-    `#` is the port number starting from `0`.
-    *   The `PD_C#` task runs the state machine (old or new) for the port and
-        communicates with the TCPC, MUX, and PPC. This task needs a large task
-        stack.
-    *   The `PD_INT_C#` tasks run at a higher priority than the state machine
-        task, and its sole job is to receive interrupts from the TCPC as quickly
-        as possible then send appropriate messages to other tasks (including
-        `PD_C#`). This task shouldn't need much stack space, but the i2c
-        recovery code requires a decent amount of stack space so it ends up
-        needing a fair amount too.
-*   Saving PD state between EC jumps
-    *   PD communication is disabled in locked RO images (normal state for
-        customer devices). When the jump from RO to RW happens relatively
-        quickly (e.g. there is not a long memory training step), then there
-        aren't many problems when RW takes over and negotiates higher PD
-        contracts.
-    *   To support factory use cases that don't have a battery (and are
-        therefore unlocked), PD communication is enabled in unlocked RO. This
-        allows systems without software sync enabled to get a higher power
-        contract than 15W in RO.
-    *   We save and restore PD state between RO -> RW and RW -> RO jump to allow
-        us to maintain a higher negotiated power through the full jump and
-        re-initialization process. For example, for each port we save the power
-        role, data role, and Vconn sourcing state in battery-backed or
-        non-volatile RAM. This allows the firmware image that is initializing to
-        restore an existing SNK contract (Chromebook as SNK) without cutting
-        power. We don't cut the power from the external supplier because we
-        issue a SoftReset (leaves Vbus intact) instead of a HardReset (drops
-        Vbus) in this contract resume case.
-    *   Both use cases where we actually are able to restore the PD contract
-        require an unlocked RO (e.g. factory) otherwise RO cannot communicate
-        via PD and will drop the higher PD contract (by applying Rp/Rp on the CC
-        lines temporarily)
-        *   The RO->RW use case is for an unlocked (e.g. factory) device that
-            negotiated power and we want to keep that contract after we jump to
-            RW in the normal software sync boot process. This is especially
-            useful when there is no battery and Vbus is our only power source.
-        *   The RW->RO use case happens when we are performing auxiliary FW
-            upgrades during software sync and BIOS instructs the EC to jump back
-            to RO. We'll also try to maintain contracts over an EC reset when
-            unlocked.
-
-## Configuration
-
-There are many `CONFIG_*` options and driver structs that are needed in the
-board.h and board.c implementation.
-
-### TCPC Config
-
-The `tcpc_config` array of `tcpc_config_t` structs defined in `board.c` (or
-baseboard equivalent) should be defined for every board. The index in the
-`tcpc_config` array corresponds to the USB-C port number. This struct should
-point to the specific TCPC driver that corresponds to the TCPC that is being
-used on that port. The i2c port and address for the TCPC are also specified
-here.
-
-### SSMUX Config
-
-The `usb_muxes` array of `usb_mux` structs defined in `board.c` (or baseboard
-equivalent) should be defined for every board. Normally the standard
-`tcpci_tcpm_usb_mux_driver` driver works, especially if TCPC and MUX are the
-same IC.
-
-If the signal strength for the high-speed data lines needs to be tuned for a
-specific hardware layout, the `board_init` field on the `usb_mux` is called
-every time the mux is woken up from a low power state and should be used for
-setting custom board tuning parameters.
-
-### PPC Config
-
-Some boards have an additional IC that sits between the physical USB-C connector
-and the rest of the board. The PPC IC gates whether the Vbus line is an input or
-output signal, based on i2c settings or gpio pins. A PPC also typically provides
-over voltage and over current protection on multiple USB-C pins.
-
-The `ppc_chips` array of `ppc_config_t` structs defined in `board.c` (or
-baseboard equivalent) sets the appropriate driver and i2c port/address for the
-PPC IC.
-
-### Useful Config Options
-
-Many USB-C policies and features are gated by various `CONFIG_*` options that
-should be defined in `board.h` (or baseboard equivalent).
-
-Most USB-C options will start with `CONFIG_USB_PD_` or `CONFIG_USBC_`. For their
-full descriptions see [config.h][config header link]
-
-## Interactions with other tasks
-
-TODO(https://crbug.com/974302): mention `USB_CHG_P#` and `CHARGER`
-
-## Upgrading FW for TCPCs
-
-TODO(https://crbug.com/974302): Mention how this works even though it is in
-depthcharge. Probing now. Need new driver in depthcharge
-
-[Case Closed Debugging (CCD)]: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md
-[Introduction to USB Power Delivery]: https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en575003
-[USB PD Spec Id]: https://www.usb.org/document-library/usb-power-delivery
-[USB TC Spec Id]: https://www.usb.org/document-library/usb-type-cr-cable-and-connector-specification-revision-20-august-2019
-[USB TCPM Spec Id]: https://www.usb.org/document-library/usb-type-ctm-port-controller-interface-specification
-[config header link]: ../include/config.h