New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 611128 link

Starred by 1 user
Status: WontFix
Owner:
groeck@chromium.org
Closed: Jul 2016
Cc:
█ vpalatin@chromium.org
bleung@chromium.org
█ williscalkins@chromium.org
█ sha...@chromium.org
adurbin@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

USB PD: Implement Error Recovery

Project Member Reported by groeck@chromium.org, May 11 2016 
Implement USB PD error recovery in EC and USB PD Controller.

What steps will reproduce the problem?
(1) Connect Apple USB-C VGA Multiport Adapter to Chell or similar system
(2) Connect power to the Adapter's USB-C port
(3) Reboot Chell

What is the expected output?

USB PD protocol should reconnect with one partner in host mode and one partner in device mode.

What do you see instead?

Both partners are connected in host mode.

Technical details:

After reboot, the EC does not receive a "Source Capabilities" message from the Apple adapter. It sends a "Soft reset" command to the adapter. The adapter replies with "Accept", with the data role set to UFP. Even after a hard reset, its data role is still "UFP".

Per USB PD specification, chapter 6.2.1.6, the port should transition to error recovery state if this occurs. Handling this state is currently not implemented in the EC nor in the Type-C port controller code. Per USB type-C specification, 4.5.2.2.2, the Error recovery action is to disable vconn/vbus and set both cc pin terminations to open.

While support for ErrorRecovery is optional, the specification mandates that the port shall be disabled in the observed situation.

Practical impact is that alternate mode support is not negotiated or exchanged, and is thus not enabled until the adapter is disconnected and reconnected.

Comment 1 by bleung@chromium.org, May 12 2016

Cc: williscalkins@chromium.org
Hi Guenter,

What stage of Chell are you using? DVT1 Chells had an issue with Vbus discharge that may cause this condition : https://code.google.com/p/chrome-os-partner/issues/detail?id=51281

Vincent, Willis and Shawn will be able to provide you with a system has been reworked with the fix that we put into DVT2 and later.

Comment 2 by groeck@chromium.org, May 12 2016 

It says DVT SKU 1 on the backplane, so I guess it is affected. I'll try to get an updated system. I don't know if it has been reworked (or how to find out).

Either case, I think it would make sense to implement error recovery, to avoid similar situations in the future. My test code works pretty well.

Comment 3 by groeck@chromium.org, May 25 2016 

Updated unit has same problem with different timing.

The problem may not be seen as easily with the protocol running in EC since the EC does not reboot when the main CPU reboots. I'll play with it and check if I can reproduce it on an EC managed port.

Comment 4 by groeck@chromium.org, May 25 2016 

Tested with protocol running on EC. Problem is not seen when Linux reboots. However, the PD protocol does not recover after an EC reboot. As far as I can see the EC is stuck in 'SRC_SEND_CAPABILITIES' state, and the PD link resets itself repeatedly.

Comment 5 by groeck@chromium.org, Jul 14 2016

Status: WontFix (was: Assigned)
Error recovery requires the ability to disable resistors on CC pins, which isn't supported on our HW (or at least not on all of our HW).
►

Sign in to add a comment