On 01 August 2018 19:38, Tim Harvey wrote:
> 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?
If a capabilities broadcast timeout is supported by a source, I believe the
minimum timeout would be ~5 seconds. The Source will not hard reset in that
scenario, but will just stop broadcasting source capabilities, so the sink needs
to trigger a hard reset to restart broadcasting from the source
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
