Samus, and Skylake generation systems : VIA VL100 charge-through hubs send WAIT commands, which are ignored by PD MCU during [20V/15V/14.5V/9V] -> 5V transition |
|||
Issue description
<b>Chrome Version: <From about:version: Google Chrome x.x.x.x></b>
<b>Chrome OS Version: <From about:version: Platform x.x.x.x></b>
Chrome OS Platform: Samus, Chell, others.
<b>Network info: <network, encryption type, router model (if known)></b>
Please specify Cr-* of the system to which this bug/feature applies (add
the label below).
Steps To Reproduce:
Here's the steps to reproduce the corner case. I'm assuming the test system is a Chromebook Pixel 2015, but it should work from any Chromebook that has two USB Type-C ports.
1. Attach the usbc-hub3p to a PD charger (let's say for simplicity, the Apple 29W charger).
2. Attach usbc-hub3p + Apple 29W charger to Twinkie.
3. Enable twinkie PD tracing (tw trace 1)
4. Attach the usbc-hub3p + Apple 29W charger + Twinkie to Pixel's right USB-C port.
5. Check that Pixel is charging. Check Twinkie console to see that Pixel is drawing approximately 14500 mV at 1650mA. (the hub takes some off the top of the current limit)
6. Attach Google 60W charger to left USB-C port.
7. Watch Twinkie console trace. See that twinkie captures that Pixel requests 5V PDO (PDO #1).
78258.102264 SNK/2 [1462]REQUEST{1} 1400c832
78258.103553 SRC/2 [0541]GOODCRC
78258.104739 SRC/6 [0d4c]WAIT
[78258.106543 PD TMOUT RX 81/81]
RXERR0 Preamble
78258.107727 TMOUT
78258.110899 SRC/7 [0f46]PSRDY
78258.112054 SNK/7 [0e61]GOODCRC
8. Check tw vbus.
tw vbus
VBUS = 14751 mV ; -2 mA
After step 6, the Pixel sees that two chargers are attached to the system and it picks the one that offers higher power (the 60W charger). For the charger that it is no longer using as a source, it requests to lower the voltage to 5V.
By step 8, it's clear that the hub didn't comply with the request to go down to the 5V PDO. It's still operating at 14.5V.
Expected Result:
Actual Result:
How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)
What is the impact to the user, and is there a workaround? If so, what is
it?
Please provide any additional information below. Attach a screen shot or
log if possible.
,
Oct 7 2016
The failure analysis from VIA concludes this is because they put in a workaround for fast-swap cases where power is disconnected on the hub side. The Chromebook systems issue a transition to 5V and then a PR_SWAP too close to one another. The VIA firmware on the VL100 always issues a Wait when transitioning to a 5V PDO from a higher one, which apparently our firmware ignores; we don't resend the request to Request PDO 1 again, even though we never got an Accept and PSRDY :
> 738.594014 SNK/1 [1262]REQUEST{1} 1400c832
738.594976 SRC/1 [0341]GOODCRC
738.595994 SRC/4 [094c]WAIT
738.596818 SNK/4 [0861]GOODCRC
Instead, Samus's firmware just silently assumes the switch to 5V PDO occurred successfully, as ectool --dev 1 usbpdpower says the following :
Port 0: SNK Charger PD 20286mV / 3000mA, max 20000mV / 3000mA / 60000mW
Port 1: SNK (not charging) Charger PD 5000mV / 1650mA, max 14800mV / 1650mA / 24420mW
Port 1 is not at 5V though. Twinkie says it's at 14.8V still :
> tw vbus
VBUS = 14806 mV ; -2 mA
,
Oct 7 2016
> The VIA firmware on the VL100 always issues a Wait when transitioning to a 5V PDO from a higher one, > which apparently our firmware ignores We are not ignoring the WAIT, we are treating it the same as a REJECT (as done in https://chromium-review.googlesource.com/#/c/230522/ ), on a WAIT, we will transition to PD_STATE_SNK_READY without the explicit contract bit set. on an ACCEPT, we will transition to PD_STATE_SNK_TRANSITION with PD_FLAGS_EXPLICIT_CONTRACT set. > we don't resend the request to Request PDO 1 again, even though we never got an Accept and PSRDY Yes, We are not retrying to get the same PDO, but VIA cannot really use the other side to implement the state machine they don't want to do ... (the spec wording is "The Sink is allowed to repeat the Request Message ...") We have never tested a Wait on a down transition though, maybe something is incorrect in our state since we had an explicit contract before, we are deciding we no longer have one but what this is implying is unclear.
,
Oct 7 2016
I'll get some ec logs today from a system exhibiting this. Thanks Vincent.
,
Oct 14 2016
Vincent : Here's the EC log from Chell. Plugable VL100 based hub (with upstream Apple 29W charger) is on c1. Zinger attached to c0 later on. On zinger attach, C1 should have gotten a request to go back down to 5V.
,
Mar 31 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by bleung@chromium.org
, Oct 7 2016