On Tue, Jul 31, 2018 at 2:22 AM Adam Thomson
<Adam.Thomson.Opensource@xxxxxxxxxxx> wrote:
>
> On 27 July 2018 17:41, Tim Harvey wrote:
>
> Adding Guenter to the thread.
>
> > Greetings,
> >
> > I have a custom design with a Fairchild FUSB302 Type-C chip driver
> > that I'm testing with Linux 4.17 and a BTI AC-60TC 60W charger. For
> > this design we are using Type-C as a power/charger input only - no
> > USB2/3 is connected. The board consumes approximately 12W typical
> > which doesn't leave enough to charge the battery in a timely fashion
> > unless switching up to a higher voltage via USB-PD.
> >
> > I'm finding that when there is no fusb302 driver enabled the charger
> > puts out 5V@3A as expected but when I enable the fusb302 driver the
> > charger cuts out momentarily when the fusb302 driver comes up on its
> > way to switching up to 20V which causes the board to reboot.
> >
> > Here's my dts config for a 20V@3A 60W capable sink:
> >
> > fusb302@0x24 {
> > compatible = "fcs,fusb302";
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_usbpd>;
> > reg = <0x24>;
> > interrupt-parent = <&gpio4>;
> > interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
> > fcs,max-sink-microvolt = <20000000>;
> > fcs,max-sink-microamp = <3000000>;
> > fcs,max-sink-microwatt = <60000000>;
> > };
> >
> >
> > Here's what I see from the kernel while booting without a battery:
> > [ 6.122858] typec_fusb302 1-0024: 1-0024 supply vbus not found,
> > using dummy regulator
> > ^^^^^ supply cuts out momentarily at this point causing board reboot
> >
> > Here's what I see from /sys/kernel/debug/tcpm when I add a battery on
> > the system with enough charge to keep it powered during the VUSB cut:
> > [ 6.134543] Setting voltage/current limit 0 mV 0 mA
> > [ 6.134960] polarity 0
> > [ 6.135304] Requesting mux mode 0, usb-role 0, orientation 0
> > [ 6.136271] state change INVALID_STATE -> SNK_UNATTACHED
> > [ 6.136334] CC1: 0 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED,
> > polarity 0, disconnected]
> > [ 6.136358] 1-0024: registered
> > [ 6.144183] Setting voltage/current limit 0 mV 0 mA
> > [ 6.144452] polarity 0
> > [ 6.144586] Requesting mux mode 0, usb-role 0, orientation 0
> > [ 6.145592] cc:=0
> > [ 6.164039] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100
> > ms
> > [ 6.176918] VBUS off
> > ^^^^^ this appears to be where the charger first cuts out
>
> The port is being reset here to return the port to a known state as part of
> initialisation. It then seems that the Source/Charger is resetting it's VBUS
> down to 0V for ~1s which is most likely it performing a hard reset.
Is this normal? I'm not clear why a Source/Charger would reset its VBUS.
>
> >
> > [ 6.273374] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100
> > ms]
> > [ 6.273394] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED
> > [ 6.273403] Start DRP toggling
> > [ 6.297315] CC1: 0 -> 0, CC2: 0 -> 5 [state DRP_TOGGLING, polarity
> > 0, connected]
> > [ 6.297327] state change DRP_TOGGLING -> SNK_ATTACH_WAIT
> > [ 6.297529] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 200
> > ms
> > [ 6.409960] VBUS on
> > [ 6.513218] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 200
> > ms]
> > [ 6.513236] state change SNK_DEBOUNCED -> SNK_ATTACHED
> > [ 6.513244] polarity 1
> > [ 6.513251] Requesting mux mode 1, usb-role 2, orientation 2
> > [ 6.515121] state change SNK_ATTACHED -> SNK_STARTUP
> > [ 6.515418] state change SNK_STARTUP -> SNK_DISCOVERY
> > [ 6.515428] Setting voltage/current limit 5000 mV 3000 mA
> > [ 6.515462] vbus=0 charge:=1
> > [ 6.515536] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES
> > [ 6.530767] pending state change SNK_WAIT_CAPABILITIES ->
> > HARD_RESET_SEND @ 240 ms
> > [ 6.567379] PD RX, header: 0x6161 [1]
> > [ 6.567407] PDO 0: type 0, 5000 mV, 3000 mA [E]
> > [ 6.567417] PDO 1: type 0, 9000 mV, 3000 mA []
> > [ 6.567427] PDO 2: type 0, 12000 mV, 3000 mA []
> > [ 6.567436] PDO 3: type 0, 15000 mV, 3000 mA []
> > [ 6.567444] PDO 4: type 0, 18000 mV, 3000 mA []
> > [ 6.567452] PDO 5: type 0, 20000 mV, 3000 mA []
> > [ 6.567459] state change SNK_WAIT_CAPABILITIES ->
> > SNK_NEGOTIATE_CAPABILITIES
> > [ 6.567643] cc=0 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1
> > [ 6.567657] Requesting PDO 5: 20000 mV, 3000 mA
> > [ 6.567665] PD TX, header: 0x1042
> > [ 6.580208] PD TX complete, status: 0
> > [ 6.580539] pending state change SNK_NEGOTIATE_CAPABILITIES ->
> > HARD_RESET_SEND @ 60 ms
> > [ 6.653644] state change SNK_NEGOTIATE_CAPABILITIES ->
> > HARD_RESET_SEND [delayed 60 ms]
> > [ 6.653659] PD TX, type: 0x5
> > [ 6.684725] PD TX complete, status: 0
> > [ 6.684783] state change HARD_RESET_SEND -> HARD_RESET_START
> > [ 6.723530] state change HARD_RESET_START -> SNK_HARD_RESET_SINK_OFF
> > [ 6.723618] vconn:=0
> > [ 6.726797] vbus=0 charge:=0
> > [ 6.727140] Requesting mux mode 1, usb-role 2, orientation 2
> > [ 6.729300] pending state change SNK_HARD_RESET_SINK_OFF ->
> > SNK_HARD_RESET_SINK_ON @ 650 ms
> > [ 6.729333] PD RX, header: 0x363 [1]
> > [ 6.729358] VBUS off
> > ^^^^^ charger cuts out again later on... probably here?
>
> This is is a sink generated hard reset and will have the same effect as before.
> VBUS will be turned off by the source for ~1s and then will be restored.
>
> >
> > [ 6.729365] state change SNK_HARD_RESET_SINK_OFF ->
> > SNK_HARD_RESET_WAIT_VBUS
> > [ 6.729429] pending state change SNK_HARD_RESET_WAIT_VBUS ->
> > SNK_UNATTACHED @ 1275 ms
> > [ 8.083161] state change SNK_HARD_RESET_WAIT_VBUS -> SNK_UNATTACHED
> > [delayed 1275 ms]
> > [ 8.104897] Setting voltage/current limit 0 mV 0 mA
> > [ 8.104947] polarity 0
> > [ 8.104956] Requesting mux mode 0, usb-role 0, orientation 0
> > [ 8.106435] Start DRP toggling
> > [ 8.123195] state change SNK_UNATTACHED -> DRP_TOGGLING
> > [ 8.143793] CC1: 0 -> 0, CC2: 5 -> 5 [state DRP_TOGGLING, polarity
> > 0, connected]
> > [ 8.143807] state change DRP_TOGGLING -> SNK_ATTACH_WAIT
> > [ 8.143862] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 200
> > ms
> > [ 8.353141] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 200
> > ms]
> > [ 8.353159] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms
> > [ 8.843153] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms]
> > [ 8.851177] Setting voltage/current limit 0 mV 0 mA
> > [ 8.851227] polarity 0
> > [ 8.851235] Requesting mux mode 0, usb-role 0, orientation 0
> > [ 8.855374] cc:=0
> > [ 8.862428] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100
> > ms
> > [ 8.963228] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100
> > ms]
> > [ 8.963263] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED
> > [ 8.963279] Start DRP toggling
> > [ 8.971887] state change SNK_UNATTACHED -> DRP_TOGGLING
> > [ 8.995761] CC1: 0 -> 0, CC2: 5 -> 5 [state DRP_TOGGLING, polarity
> > 0, connected]
> > [ 8.995786] state change DRP_TOGGLING -> SNK_ATTACH_WAIT
> > [ 8.995915] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 200
> > ms
> > [ 9.203272] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 200
> > ms]
> > [ 9.203305] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms
> > [ 9.559888] VBUS on
> > [ 9.559906] state change SNK_DEBOUNCED -> SNK_ATTACHED
> > [ 9.560039] polarity 1
> > [ 9.560055] Requesting mux mode 1, usb-role 2, orientation 2
> > [ 9.561580] state change SNK_ATTACHED -> SNK_STARTUP
> > [ 9.561596] state change SNK_STARTUP -> SNK_DISCOVERY
> > [ 9.561611] Setting voltage/current limit 5000 mV 3000 mA
> > [ 9.561696] vbus=0 charge:=1
> > [ 9.562129] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES
> > [ 9.573575] pending state change SNK_WAIT_CAPABILITIES ->
> > HARD_RESET_SEND @ 240 ms
> > [ 9.608966] PD RX, header: 0x6161 [1]
> > [ 9.609017] PDO 0: type 0, 5000 mV, 3000 mA [E]
> > [ 9.609037] PDO 1: type 0, 9000 mV, 3000 mA []
> > [ 9.609055] PDO 2: type 0, 12000 mV, 3000 mA []
> > [ 9.609073] PDO 3: type 0, 15000 mV, 3000 mA []
> > [ 9.609091] PDO 4: type 0, 18000 mV, 3000 mA []
> > [ 9.609108] PDO 5: type 0, 20000 mV, 3000 mA []
> > [ 9.609122] state change SNK_WAIT_CAPABILITIES ->
> > SNK_NEGOTIATE_CAPABILITIES
> > [ 9.609194] cc=0 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1
> > [ 9.609216] Requesting PDO 5: 20000 mV, 3000 mA
> > [ 9.609232] PD TX, header: 0x1042
> > [ 9.620508] PD TX complete, status: 0
> > [ 9.620602] pending state change SNK_NEGOTIATE_CAPABILITIES ->
> > HARD_RESET_SEND @ 60 ms
> > [ 9.623755] PD RX, header: 0x363 [1]
> > [ 9.623778] state change SNK_NEGOTIATE_CAPABILITIES ->
> > SNK_TRANSITION_SINK
> > [ 9.623843] pending state change SNK_TRANSITION_SINK ->
> > HARD_RESET_SEND @ 500 ms
> > [ 9.677452] PD RX, header: 0x566 [1]
> > [ 9.677476] Setting voltage/current limit 20000 mV 3000 mA
> > [ 9.678596] state change SNK_TRANSITION_SINK -> SNK_READY
> >
> > Any idea what's causing the VUSB to momentarily cut out during the
> > transition from 5V to 20V here? I have not yet tested with other
> > chargers and I'm still digging through documents like the USB-PD spec
> > [1] to understand the seemingly complex spec and state machine.
>
> It's standard behaviour for a port to trigger hard reset so it can return both
> ports to a known state. Given the way the that PD standard is written I believe
> the expectation has to be that the Sink will be battery backed as there are a
> few scenarios where we can expect hard reset to occur and that means 0V VBUS.
> One example would be where a source is broadcasting capabilities when a system
> starts, but times out sending capabilities before the system is ready to start
> the PD protocol exchange. At that point there's no choice but to send a hard
> reset to trigger the source to send capabilities again.
>
Adam,
Thanks for the response!
With a dead battery installed there is enough of a charge to keep my
system running by the time the driver goes through this init sequence
but I am surprised a bit by this. I can't imagine its a requirement of
USB-PD to have a battery in the system so I'm wondering if the TCPM
state machine needs some adjustment.
Regarding the scenario where the source comes up broadcasting its
capabilities with a timeout for a hard reset - how much time does this
provide for a device to bring up its software stack to negotiate
power?
Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
