https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/698088
https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/684302

The 2 CLs above are a way of dumping e-marker content by using Twinkie, not the feature per se:
- they are on the Twinkie firmware branch
- they support a specific hardware (with SW TCPC) not all variants
- they don't do the negotiation, just dump the e-marker chip descriptors. would need to do it at the right time in the process before (re-)sending the power request

re-adding my other remarks:
For this actual use-case, the following needs to be done :
1. most of our TCPC already have SOP' support
2. need to add something to send SOP' VDM 
(the crude version is : https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/684302/4/common/usb_pd_protocol.c)
3. insert those new states maybe after PD_STATE_SNK_DISCOVERY and before PD_STATE_SNK_REQUESTED
4. update pd_build_request to take into account the new detected current limit (if any)

only 3. really requires a bit of work and thinking

A bikeshedding on the title: we do support e-marked cable (as there is not much to do) we aren't taking advantage of them.

> 3. insert those new states maybe after PD_STATE_SNK_DISCOVERY and before 
> PD_STATE_SNK_REQUESTED

6.4.4.2 Structured VDM says "Structured VDMs shall only be used when an Explicit Contract is in place with the following exception:
Prior to establishing an Explicit Contract a Source may issue Discover Identity Messages, to a Cable Plug using SOP’ Packets, as an Initiator."

So, the spec doesn't seem to allow the sink to talk to the cable plug before an explicit contract is made.

Reading the spec, it seems discover identity has to be used as follows:

1. Before an explicit contract, only the source sends discover identity.
2. After an explicit contract, only the DFP sends discover identity.

So, as a source, cros tcpm is supposed to do:
1. Accept a 3A contract (even if a 5A contract is offered)
2. Swap data role to become DFP
3. Send discover identity to SOP' (and set B1 of Receive_Detect register)
4. If the cable is 5A capable, do PD re-negotiation

Update to #8:
1. Accept the highest contract (5A if it's available) but limit the input current to 3A.
2. Swap data role to DFP (and Vconn)
3. Send discover identity to SOP' (and set B1 of Receive_Detect register)
4. If the cable is 5A capable, raise the limit to MAX(5A, system_max).

> 1. Accept the highest contract (5A if it's available) but limit the input current to 3A.

Something is unclear to me here, you are the sink so you are actually 'sending a request' rather then 'accepting a contract' ?

you can also always send a 5A request but with the 'cap mismatch' bit set.

Else, ok the process in #9 seems the way to go.

Rephrased step 1:

1. Request the highest contract (5A if it's available) but limit the input current to 3A internally.
2. Swap data role to DFP (and Vconn).
3. Send discover identity to SOP' (and set B1 of Receive_Detect register)
4. If the cable is 5A capable, raise the limit to MAX(5A, system_max).

Also, we need to decide what to do if data role swap fails (step2). For example, the Apple 87W charger doesn't support data role swap.

Sinks don't need to detect 5A cables.  Sources are required to check the cable (or have a known-good captive cable) before offering 5A.  If cros-ec receives a >3A advertisement, we can assume the cable is 5A capable.

In particular, the proposed solution of swapping and checking eMarkers won't work in the captive cable case -- a case where the >3A captive-cable brick doesn't need an eMarker and will always offer >3A.

So while supporting eMarker detection would be nice, it's not actually required (or desired) for this use case.

Note that the reason we limit to 3A in all of our code so far is because most of the power circuitry was designed with 3A in mind.  Since Fizz is designed to handle 5A, you can just raise the max accepted current for that board, but do not increase the limit for other designs.

I'll leave it open. E-marked cable support will be needed when we develop 5A capable chargers.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This should probably get rolled up into shurst's new stack