summaryrefslogtreecommitdiff
path: root/docs/usb_power.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/usb_power.md')
-rw-r--r--docs/usb_power.md253
1 files changed, 4 insertions, 249 deletions
diff --git a/docs/usb_power.md b/docs/usb_power.md
index 860e7fe589..cabbe1e264 100644
--- a/docs/usb_power.md
+++ b/docs/usb_power.md
@@ -1,250 +1,5 @@
-# USB Power Considerations
+*** note
+**Warning: This document is old & has moved. Please update any links:**<br>
+https://chromium.googlesource.com/chromiumos/platform/ec/+/HEAD/docs/usb_power.md
+***
-Users want to be able to charge external devices using their Chromebook USB
-ports, e.g. charge a phone from their Chromebook. We want to provide a fast
-charging experience to end-users, so we prefer to offer high power charging when
-possible.
-
-[TOC]
-
-## Summary of Design Requirements
-
-For explanations of calculations see rest of doc.
-
-### Total System Power
-
-Total current needed for external USB devices at 5V:
-
-```
-((Number of Type-C Ports) * (1800mA)) + 1500mA +
-((Number of Type-A Ports) * (900mA)) + 600mA§
-```
-
-§ The additional 600mA can be omitted if BC1.2 is not supported for Type-A
-
-### Daughter Board Considerations
-
-If a daughter board has 1 Type-A (supporting BC 1.2) and 1 Type-C, the max
-potential current load at 5V is `Type-A Vbus (1500mA) + Type-C Vbus (3000mA) +
-Type-C Vconn (300mA) = 4800mA`
-
-* The DB ribbon cables need to be able to carry enough current to supply 24W
- (4.8A * 5V) of power to the DB.
- * This may be on a single or multiple power rails depending on hardware
- design.
-* The ground path on the ribbon cable from the DB also needs to be able to
- carry enough current to match the power rails.
-
-## USB Type-A Ports
-
-For Type-A ports, the [BC 1.2 Specification] adds higher power modes on top of
-the [USB 3.2 Specification]. While BC 1.2 support isn't required, it is
-preferred, as it allows end-users to charge their devices more quickly.
-
-[BC 1.2 Specification] defines multiple modes of operation including, but not
-limited to:
-
-* CDP - Charging Downstream Port
- * Allows USB Data. Provides guaranteed 1.5A @ 5V power.
- * ChromeOS device can act as a CDP.
-* SDP - Standard Downstream Port
- * Allows USB Data. Provides guaranteed current defined by USB
- Specifications
- * For USB3, provides guaranteed current of 0.9A @ 5V.
- * For USB2, provides guaranteed current of 0.5A @ 5V.
- * ChromeOS device can act as a SDP.
-* DCP - Dedicated Charging Port
- * No USB Data. Provides max of 1.5A @ 5V power.
- * ChromeOS device **will not** act as a DCP.
-
-For detection logic of each mode (e.g. on the D+ and D- pins) and nuance of
-power/current power requirements, see full [BC 1.2 Specification].
-
-Without BC 1.2 support, the max power requirements match that of a Standard
-Downstream Port (SDP) as defined by various specification (e.g.
-[USB 3.2 Specification]).
-
-### ChromeOS as Source - Policy for Type-A
-
-If BC 1.2 is supported on a ChromeOS device, then the first Type-A port in use
-will act as a CDP, providing a maximum current of 1.5A while also enabling USB
-data. All other Type-A ports will only be SDP, providing a maximum current of
-900mA.
-
-Note that the CDP Type-A port allocation is dynamic; the first Type-A port to
-draw more than 900mA gets to be the CDP, with a maximum current of 1.5A. Then
-all other Type-A ports get downgraded to the lower, 900mA current limit (i.e.
-SDP) while the first Type-A port maintains a current draw of more than 900mA. In
-practice, this means that the first Type-A device plugged in gets to consume
-1.5A and any Type-A device inserted after that will only get 900mA.
-
-Once the Type-A device drawing 1.5A stops pulling more than 900mA or is
-physically removed, then the extra 600mA (as well as CDP advertisement) becomes
-available to any Type-A port. In practice, Type-A devices only determine current
-limits when they are first inserted, so any Type-A device that is still plugged
-in when the 1.5A device is removed will not notice that it can pull more
-current. This means that the first Type-A device **inserted** after removing the
-original 1.5A device gets access to 1.5A.
-
-The allocation of the one CDP Type-A port is unaffected by user interaction with
-Type-C ports. Once a Type-A port has been claimed as CDP, inserting a Type-C
-device will not revoke the CDP status of the Type-A port.
-
-For example, the below sequence of events illustrates the above Type-A policy if
-BC 1.2 is supported:
-
-1. Insert Type-A phone first
- * Since no other Type-A port is currently supplying more than 900mA, this
- port can supply 1.5A as the CDP.
- * Phone pulls 1.5A; other Type-A ports are now marked as SDPs limiting
- current to 900mA, each.
- * Current state: `phone @ 1.5A`.
-2. Insert Type-A mouse second
- * Mouse is only allowed 900mA since port is SDP.
- * Current state: `phone @ 1.5A` and `mouse @ 900mA`.
-3. Remove phone
- * High-current port status is relinquished. Now first Type-A port to draw
- more than 900mA will claim the one high-current port status (as the
- CDP).
- * Mouse does not realize that more power is available since most Type-A
- devices only determine their current limits upon connection.
- * Current state: `mouse @ 900ma`.
-4. Insert Type-A battery pack
- * Since no other Type-A port is currently supplying more than 900mA, this
- port can supply 1.5A as the CDP.
- * Battery pack pulls 1.5A; other Type-A ports are now marked as SDPs
- limiting current to 900mA, each.
- * Current state: `mouse @ 900ma` and `battery pack @ 1.5A`.
-
-The total current needed for all Type-A ports at 5V is:
-
-```
-if (BC1.2_Supported)
- (# Type-A Ports)*(900mA) + 600mA
-else
- (# Type-A Ports)*(900mA)
-```
-
-## USB Type-C Ports
-
-USB Type-C allows for dynamic negotiation of high power contracts; this is
-accomplished through varying CC resistors and/or USB-C Power Delivery (PD). More
-in-depth information can be found in the [USB Type-C Specification] \(section
-4.5.2.3) and the [USB PD Specification]. CC resistor contracts can range from
-500mA/5V to 3A/5V, while PD contracts can range from 0mA/3.3V to 5A/20V.
-
-### ChromeOS as Source - Policy for Type-C
-
-**Note:** Behavior outlined in this .md file reflects future-planned behavior,
-and is not present in the codebase currently.
-
-ChromeOS devices currently source power to external USB devices at 5V with a
-typical current of 1.5A for each Type-C port. In certain scenarios, a
-Type-C port can source up to 3A @ 5V.
-
-ChromeOS prefers that the first PD-capable Type-C device **that requires 3A**
-should get 3A guaranteed at 5V. Once the maximum supported number of PD-capable
-Type-C device has claimed 3A, then other PD-capable Type-C devices will only be
-offered a maximum of 1.5A.
-
-If there are no PD-capable Type-C devices requiring 3A, then the first non-PD
-device will be given 3A until a PD-capable device **that requires 3A** is
-inserted. Devices will indicate they require 3A in their sink capabilities,
-and this will be used as the trigger to let the EC know to offer that port a
-3A source contract. This policy is laid out in the following flow chart.
-
-![Partner Attach](images/usb_power_on_attach.png "Partner Attach")
-
-When a device that is currently claiming 3A is removed, then the next oldest
-PD-capable device is offered 3A. If no PD-capable devices require 3A,
-then the oldest non-PD capable device is given 3A through a CC resistor change.
-
-![Partner Detach](images/usb_power_on_detach.png "Partner Detach")
-
-Inserting a Type-A device does not affect the power assignment for Type-C ports;
-only Type-C devices affect the power of Type-C ports.
-
-For example, the below sequence of events illustrates the above Type-C policy
-with a board with a maximum number of 1 3A-ports supported:
-
-1. A non-PD capable Type-C keyboard is inserted first
- * Keyboard will be offered 1.5A initially
- * Current state: `keyboard @ 1.5A`.
-2. Partner is established to be non-PD through reaching PE\_SRC\_Disabled.
- * Since there are no other PD-capable devices and this is the first
- device, offer this device 3A via CC resistor change.
- * Current state: `keyboard @ 3A`.
-3. A non-PD capable Type-C mouse is inserted second
- * It will be offered 1.5A since there is already another non-PD device
- claiming 3A.
- * Current state: `keyboard @ 3A` and `mouse @ 1.5A`.
-4. A PD-capable Type-C dock is inserted third
- * Initially negotiate for 1.5A.
- * Since this is a PD device, query its operational current through
- requesting Sink Capabilities.
- * Dock does not want high power from Chromebook; dock continues to receive
- 1.5A.
- * Keyboard gets to maintain higher 3A current supply.
- * Current state: `keyboard @ 3A` and `mouse @ 1.5A` and `dock @ 1.5A`.
-5. A PD-capable Type-C phone is inserted fourth
- * Phone is initially offered 1.5A.
- * Since this is a PD device, query its operational current through
- requesting Sink Capabilities.
- * The phone reports it wants 3A.
- * Since PD devices are preferred for 3A, the non-PD keyboard will be
- downgraded from 3A to 1.5A via a CC resistor change.
- * After tSinkAdj (60 ms), phone is offered 3A through new Source
- Capabilities.
- * Current state: `keyboard @ 1.5A` and `mouse @ 1.5A` and `dock @ 1.5A`
- and `phone @ 3A`.
-6. A PD-capable Type-C tablet is inserted fifth
- * Tablet is initially offered 1.5A.
- * Since this is a PD device, query its operational current through
- requesting Sink Capabilities.
- * Tablet would like 3A, but the board has reached its maximum number of
- supported 3A ports. Note this port's desired current for later.
- * Current state: `keyboard @ 1.5A` and `mouse @ 1.5A` and `dock @ 1.5A`
- and `phone @ 3A` and `tablet @ 1.5A`.
-7. The PD-capable phone is removed
- * The next oldest PD-capable device is offered 3A: the tablet
- * Current state: `keyboard @ 1.5A` and `mouse @ 1.5A` and `dock @ 1.5A`
- and `tablet @ 3A`.
-8. The PD-capable tablet is removed
- * The next oldest PD-capable device requiring 3A is offered 3A. If there
- are no PD-capable devices requiring 3A, then the oldest non-PD capable
- device is given 3A.
- * The dock only requires 1.5A, so keyboard is given 3A via CC resistor
- change.
- * Current state: `keyboard @ 3A` and `mouse @ 1.5A` and `dock @ 1.5A`
-9. The non-PD capable keyboard is removed
- * The next oldest PD-capable device requiring 3A is offered 3A.. If there
- are no PD-capable devices requiring 3A, then the next oldest non-PD capable
- device is given 3A.
- * The dock only requires 1.5A, so mouse is given 3A via CC
- resistor change.
- * Current state: `mouse @ 3A` and `dock @ 1.5A`.
-10. The non-PD capable mouse is removed
- * The dock does not require 3A.
- * Current state: `dock @ 1.5A`.
-
-Note: Not all released Chromebooks implement the above policy due to
-pre-existing hardware design constraints.
-
-Type-C ports also need to provide an additional 300mA @ 5V (1.5W) for Vconn on
-every port. Note: the 1.5W for Vconn may also be supplied at other voltages,
-such as 455mA @ 3.3V instead.
-
-The total current needed for all Type-C ports at 5V is:
-
-```
-((Number of Type-C Ports) * (1500mA + 300mA)) + 1500mA
-```
-
-The total maximum current needed for a single Type-C port at 5V is `(3000mA +
-300mA) = 3.3A`. This max current for a single port is especially relevant for
-sizing the daughter board ribbon cable appropriately.
-
-[BC 1.2 Specification]: <https://www.usb.org/document-library/battery-charging-v12-spec-and-adopters-agreement>
-[USB 3.2 Specification]: <https://www.usb.org/document-library/usb-32-specification-released-september-22-2017-and-ecns>
-[USB PD Specification]: https://www.usb.org/document-library/usb-power-delivery
-[USB Type-C Specification]: https://www.usb.org/document-library/usb-type-cr-cable-and-connector-specification-revision-14-march-29-2019