• B
    usb: typec: tcpm: Introduce vsafe0v for vbus · 28b43d3d
    Badhri Jagan Sridharan 提交于
    TCPM at present lacks the notion of VSAFE0V. There
    are three vbus threshold levels that are critical to track:
    a. vSafe5V         - VBUS “5 volts” as defined by the USB
                         PD specification.
    b. vSinkDisconnect - Threshold used for transition from
                         Attached.SNK to Unattached.SNK.
    c. vSafe0V         - VBUS “0 volts” as defined by the USB
                         PD specification.
    
    Tracking vSafe0V is crucial for entry into Try.SNK and
    Attached.SRC and turning vbus back on by the source in
    response to hard reset.
    
    >From "4.5.2.2.8.2 Exiting from AttachWait.SRC State" section
    in the Type-C spec:
    
    "The port shall transition to Attached.SRC when VBUS is at
    vSafe0V and the SRC.Rd state is detected on exactly one of
    the CC1 or CC2 pins for at least tCCDebounce."
    
    "A DRP that strongly prefers the Sink role may optionally
    transition to Try.SNK instead of Attached.SRC when VBUS
    is at vSafe0V and the SRC.Rd state is detected on exactly
    one of the CC1 or CC2 pins for at least tCCDebounce."
    
    >From "7.1.5 Response to Hard Resets" section in the PD spec:
    
    "After establishing the vSafe0V voltage condition on VBUS,
    the Source Shall wait tSrcRecover before re-applying VCONN
    and restoring VBUS to vSafe5V."
    
    vbus_present in the TCPM code tracks vSafe5V(vbus_present is true)
    and vSinkDisconnect(vbus_present is false).
    
    This change adds is_vbus_vsafe0v callback which when set makes
    TCPM query for vSafe0V voltage level when needed.
    
    Since not all TCPC controllers might have the capability
    to report vSafe0V, TCPM assumes that vSafe0V is same as
    vSinkDisconnect when is_vbus_vsafe0v callback is not set.
    This allows TCPM to continue to support controllers which don't
    have the support for reporting vSafe0V.
    
    Introducing vSafe0V helps fix the failure reported at
    "Step 15. CVS verifies PUT remains in AttachWait.SRC for 500ms"
    of "TD 4.7.2 Try. SNK DRP Connect DRP Test" of
    "Universal Serial Bus Type-C (USB Type-C) Functional Test
    Specification Chapters 4 and 5". Here the compliance tester
    intentionally maintains vbus at greater than vSafe0V and expects
    the Product under test to stay in AttachWait.SRC till vbus drops
    to vSafe0V.
    Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
    Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
    Link: https://lore.kernel.org/r/20201202040840.663578-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    28b43d3d
tcpm.h 5.8 KB